Introduce shouldEncrypt in PutRequestOptions for clients to not encrypt self key/shared key data

murali-shris commented 2 months ago

Is your feature request related to a problem? Please describe.

Currently isEncrypted in metadata is set to false even though data is encrypted.
Client don't have control if they choose not to encrypt data for self key/shared key

Describe the solution you'd like

Introduce a flag shouldEncrypt in PutRequestOptions which will be true by default
New client can still see old data which can be encrypted with isEncrypted=false. Handle this scenario while decrypting

Describe alternatives you've considered

No response

Additional context

No response

murali-shris commented 2 months ago

@gkc For self key /shared key, data will be encrypted but metadata.isEncrypted = false. Once we merge the changes for this feature, there are two scenario while decrypting i) new data - data will be encrypted. metadata.isEncrypted = true ii) old data - data will be encrypted. metadata.isEncrypted = false

I have implemented the below approach for backward compatibility in GetResponseTransformer i) if key is public, do not call decryption service ii) if metadata.isEncrypted=true, call decryption service iii) if metadata is not set or metadata.isEncrypted=false, try decrypting the data(may be old data). if decryption passes, then return decrypted value. If decryption fails, then return actual value.

https://github.com/atsign-foundation/at_client_sdk/pull/1398/files#diff-4565ef50d8f9949de083fc75b9212acc31ae9463627cac423497f138664565d3 Another implementation which I had i mind (but yet to implement). If decryption passes for scenario iii) update metadata.isEncrypted = true in metadata. So old keys with isEncrypted=false, will eventually be migrated.

Please let me know your thoughts

gkc commented 2 months ago

Discussed on call

atsign-foundation / at_client_sdk