clarify encryption keys use field#752
Conversation
|
@QZHelen could i ask for your review as well? Couldn't select you for reviewers (probably because you didn't joint the gh org?). |
fkj
left a comment
fkj
left a comment
There was a problem hiding this comment.
The requirement that the Wallet MUST NOT select a key with the wrong use is new normative text, and surprisingly RFC 7517 does not contain any normative text saying what to actually do with a use parameter (e.g. that you MUST or SHOULD use a use=enc key only for encryption).
So this is technically a breaking change. However, I think any implementation that ignores use will never actually work anyway. So in this case I think we can make an exception. But this should be discussed in the WG. One option is to weaken the MUST NOT to a SHOULD NOT.
|
Looks good to me, many thanks for the work to clarify this! |
| : OPTIONAL. A JSON object containing the Verifier metadata values. It MUST be UTF-8 encoded. The following metadata parameters MAY be used: | ||
|
|
||
| * `jwks`: OPTIONAL. A JSON Web Key Set, as defined in [@!RFC7591], that contains one or more public keys, such as those used by the Wallet as an input to a key agreement that may be used for encryption of the Authorization Response (see (#response_encryption)), or where the Wallet will require the public key of the Verifier to generate a Verifiable Presentation. This allows the Verifier to pass ephemeral keys specific to this Authorization Request. Public keys included in this parameter MUST NOT be used to verify the signature of signed Authorization Requests. Each JWK in the set MUST have a `kid` (Key ID) parameter that uniquely identifies the key within the context of the request. | ||
| * `jwks`: OPTIONAL. A JSON Web Key Set, as defined in [@!RFC7591], that contains one or more public keys, such as those used by the Wallet as an input to a key agreement that may be used for encryption of the Authorization Response (see (#response_encryption)), or where the Wallet will require the public key of the Verifier to generate a Verifiable Presentation. This allows the Verifier to pass ephemeral keys specific to this Authorization Request. JWKs in this set that do not contain a `use` parameter are intended to be used for encryption of the Authorization Response. If the Verifier includes keys intended for different purposes, it SHOULD set the `use` parameter in each key of the set to avoid ambiguity about which key to use for which purpose. Public keys included in this parameter MUST NOT be used to verify the signature of signed Authorization Requests. Each JWK in the set MUST have a `kid` (Key ID) parameter that uniquely identifies the key within the context of the request. |
There was a problem hiding this comment.
Is this a breaking change?
There was a problem hiding this comment.
My opinion is that "enc" actually fits well for the Credential Response encryption, while ECDH+MAC-based cryptographic holder binding should actually use sig value or register a new value for the use parameter. I believe the current language is a breaking change which we wanted to avoid.
That is pretty much what the PR says? It just adds a simplification that if |
Co-authored-by: Christian Bormann <chris.bormann@gmx.de>
5 participants
Closes #642