Partial response encryption

[martijnharing]

As part of the discussion of https://github.com/openid/OpenID4VCI/issues/339 we discussed whether there is a need partial response encryption and to have a separate discussion item for that to give reasons for having partial response encryption.

Conceptually partial response encryption is important when there are different components involved in provisioning that don't all have access to the key used for encryption, but they need access to part of the response to provide functionality. Examples of such situations are:

• Within the mobile device there are areas on the mobile device that not all have access to the key used for response encryption, but they may need access to part of the response.
• The mobile device has secure areas outside of the mobile device that contains the key used for response encryption, but components on the mobile device need access to part of the response.
• Issuance is mediated by a wallet server, where the wallet server needs access to part of the response but doesn't have access to the key used for response encryption.

[c2bo]

I've been wondering since this was brought up: Do you think there will some form of generally applicable rule that fits all of those use-cases which part would be encrypted by which party or would that need to be fully dynamic and the wallet and whatever system in-between need to figure that part out?

Fully dynamic sounds a lot more complex and probably also more prone to errors?

[Sakurann]

i think @GarethCOliver also put some thoughts in this issue thread https://github.com/openid/OpenID4VCI/issues/339#issuecomment-2877238722

[Sakurann]

WG discussion:

• clarification: only applies to credential response
• what needs to be non-encrypted is outside credentials parameter; ie what does not need ot be encrypted is not credentials parameter (@martijnharing please confirm)
• overall concern that this adds a lot of complexity..
  • isn't this wallet/use-case specific
  • probably can't standardize which parameters to encrypt and which don't
• any specific technical solutions?
  • please think of some
• most likely can be 1.1

[tlodderstedt]

I don't feel we have enough information to properly design a solution.

I'm concerned this feature will make the spec much more complex and I don't fully understand the benefit yet. I think we need to understand the use cases, especially what data shall not be encrypted.

[tplooker]

Conceptually I understand the desire here but agree with @tlodderstedt it feels a bit premature to design a solution unless we have some clear usecases we can model the feature against.

[Sakurann]

I think we can add this feature in a non-breaking manner in 1.1 if needed?

[jogu]

Moved to 1.1 as per above comments. Please continue to discuss and add the details of the use cases / requirements.