Add encryption details parameter

[martijnharing]

Resolves #347

[c2bo]

We would need to add IANA registration requests for both parameters in their respective registries I assume?

[awoie]

We would need to add IANA registration requests for both parameters in their respective registries I assume?

This needs registration in two IANA registries:

• encryption_details_supported_parameter -> E.4. OAuth Authorization Server Metadata Registry
• encryption_details -> if I read the PR correctly, then this has to go into JSON Web Signature and Encryption Header Parameters

I suggest adding the corresponding registrations to the IANA section.

[awoie]

@martijnharing Generally fine with this PR but just had a question/suggestion above.

[c2bo]

Would it make sense to define a "profile" name for the current/default behaviour?

[martijnharing]

The following two statements allow for a gap in implementations that lead to broken flows, right?

the Verifier MUST verify that one of the referenced profiles is included in the response

AND

the selected profile MAY be included in the JWE protected header using the encryption_details header

Why would the latter be a MAY/SHOULD, if it would break the verifier?

How about: "The selected profile MUST be included in the JWE protected header using the encryption_details header unless the profile defines differently."

[awoie]

The following two statements allow for a gap in implementations that lead to broken flows, right?

the Verifier MUST verify that one of the referenced profiles is included in the response

AND

the selected profile MAY be included in the JWE protected header using the encryption_details header

Why would the latter be a MAY/SHOULD, if it would break the verifier?

How about: "The selected profile MUST be included in the JWE protected header using the encryption_details header unless the profile defines differently."

That works for me

[bc-pi]

As others have noted, precedent and consistency would require that these new things have IANA registration requests for both in their respective registries. Writing those IANA requests and taking them to the designated experts and IANA might underscore the rather tenuous nature of the problem and solution here.

As others have noted, precedent and consistency would require that these new things have IANA registration requests for both in their respective registries. Writing those IANA requests and taking them to the designated experts and IANA might underscore the rather tenuous nature of the problem and solution here.

Sorry for the double double comment. Undoubtedly user error on my part. The same user that can't seem to find how to delete a comment. Sorry.

[Sakurann]

suggestion:

• define apu and apv values for ECDH-ES JWE in OpenID4VP 1.0
  • the benefit of this approach is much simpler and less optionality than encryption_details_supported parameter
  • wallet MUST set apu and apv values as defined in the spec; verifier MUST validate those
  • apu and apv values are: apu - do not define it; apv is hash of a base64url encoded array of the following [ "nonce", "origin/client_id", "jwkthumbprint", "response_uri"] (with white spaces clearly defined.............)
• later on, when JOSE-HPKE is available for JWE, define the content of the necessary parameter for that in OpenID4VP 1.1
  • ideally, they would not deviate from apu/apv for ECDH-ES

[Sakurann]

WG discussion:

• we cannot define apu apv values in the profiles of openid4vp spec because then we need a parameter in openid4vp that indicates encryption parameter, which adds somewhat unnecessary complexity/optionality + less encryption profiles the better.
• apu - do not define it; apv - base64urlencoded hash string of following string: nonceorigin OR client_idjwkthumbprintresponse_uri in that order
  • JWE already says apv and apu is base64url-encoded string, so need to make sure it's not double encoded
• noting concerns of @bc-pi regarding the value of doing this + error proneness of multiple value as apv

[Sakurann]

WG discussion about defining apu/apv values for ECDH-ES JWE..

• on one hand...
  • adds marginal security benefit (majority agrees with @selfissued and @bc-pi disagreeing)
  • would not be the most complex part of the OpenID4VP implementation and can be implemented using existing JOSE libraries
  • there is implementation experience of similar mechanisms in 18013-7 annex B
• on the other hand...
  • there are strong concerns that adding this mechanism last minute would result in it being underspecified leading to interoperability problems
  • if very much needed, extension mechanism to define apu/apv values could be added in 1.1 (verifiers that support only that extension will potentially reject responses from wallets that do not support it)
  • wg seems to agree to define the content of a detached payload for JOSE-HPKE in OpenID4VP 1.1 or HAIP

wg agreed to discuss and tackle #347 during wglc/review period and as an outcome this PR and PR #628 will be closed for the above reasons since there is no wg rough consensus to proceed with either of them.