...

1. Should not ideally we move out the common SSL configurations in the EncryptionOption and may be define a parent class like CommonEncryptionOption?
   1. Response: Ideally yes. While it is little weird to have conflicting configuration options in the EncryptionOption (i.e. file based keystore/truststore paths and pluggable sslcontext factory which mostly intended toward not using file based artifacts), practically we could still live with little imperfection. However we will be open to discuss if the community members feel it is best to have a parent class to move out 'common' ssl configurations between file based and pluggable sslcontext factory.
   2. Above stated reason results into the current design of the interface which requires EncryptionOptions to be passed to most of it's methods because the implementation needs to know the "common SSL configurations".
2. Should we move to model of having Map<String,String> type as passing all the SSL configuration options to any implementation of the ISslContextFactory including the Default one?
   1. Yes we could do that but for that we would have to "copy" all the common SSL configurations to the Map<String,String> while creating the instance of the ISslContextFactory's implementation including the Default one. This would also help make the imperfection of not adding CommonEncryptionOption suggested in the 1st question.
   2. Again, we would need community's input on the preference.

Our current preference

Having a parent class like CommonEncryptionOptions and moving the common SSL configurations to that would be better. This is because- it allows us keep the names/types for those configuration keys coming from the YAML configuration compared to opaque Map<String,String>. However, opaque Map<String,String> will be still used as mentioned in the ISslContextFactory implementation's constructor for the implementation specific configs.

Compatibility, Deprecation, and Migration Plan

...