Merging credential_response_encryption parameters into a single object #136
Conversation
paulbastian
requested review from
peppelinux,
tlodderstedt,
Sakurann and
awoie
|
On the Credential request parameters, the logic between the presence of On the Issuer metadata.... I don't think there is a need to group there, but we could either
|
| @@ -872,7 +873,7 @@ Credential Response can be immediate or deferred. The Credential Issuer MAY be a | |||
|
|
|||
| In other cases, the Credential Issuer MAY NOT be able to immediately issue a requested Credential and would want to send a `transaction_id` parameter to the Client to be used later to receive a Credential when it is ready. The HTTP status code MUST be 202 (section 10.2.3 of [@!RFC2616]). | |||
|
|
|||
| If the Client requested encrypted responses, the Credential Issuer MUST encode the information in the Credential Reponse as a JWT with `credential_response_encryption_alg` and `credential_response_encryption_enc`. The JWT MUST be encrypted using the public key specified by `credential_encryption_jwk` in the Credential Request. If the Credential Response is encrypted, the media type of the response MUST bet set to `application/jwt`. If encryption was negotiated in the Credential Request and the Credential Response is not encrypted, the Client SHOULD reject the Credential Response. | |||
| If the Client requested encrypted responses, the Credential Issuer MUST encode the information in the Credential Response as a JWT with `alg`, `enc` and using the public key specified by `jwk` from the `credential_response_encryption` object in the Credential Request. If the Credential Response is encrypted, the media type of the response MUST bet set to `application/jwt`. If encryption was negotiated in the Credential Request and the Credential Response is not encrypted, the Client SHOULD reject the Credential Response. | |||
There was a problem hiding this comment.
Does this mean that the the response is an encrypted json and not a Netsted JWT, signed and then encrypted?
I would give more clarification, as OIDC with the userinfo response (or id token) made:
If the UserInfo Response is signed and/or encrypted, then the Claims are returned in a JWT and the content-type MUST be application/jwt. The response MAY be encrypted without also being signed. If both signing and encryption are requested, the response MUST be signed then encrypted, with the result being a Nested JWT, as defined in [JWT].
There was a problem hiding this comment.
I think this is about encryption only, this is how I read it
There was a problem hiding this comment.
@peppelinux i think here we are trying to talk about the case when response is only encrypted and not signed. and that probably can be made clearer.
Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com>
We cannot make all three keys REQUIRED since encryption is OPTIONAL. If we group them, then we can make the group key OPTIONAL and then we probably don't have to say anything about the sub-keys (jwk, enc, alg) anymore. |
I think I also tend to favor grouping for Issuer metadata. |
Let's do that in a separate PR. |
Co-authored-by: Tobias Looker <tplooker@gmail.com>
Co-authored-by: Oliver Terbu <43441584+awoie@users.noreply.github.com>
Co-authored-by: Joseph Heenan <joseph@heenan.me.uk>
Closes #113
alg, as there is a default value forenc?I was unsure about the intention of the Issuer Metadata. Issuer could offer
credential_response_encryption_alg_values_supportedfor offering the optionality to the wallet but setrequire_credential_response_encryptionto false?The current Issuer metadata:
credential_response_encryption_alg_values_supported: OPTIONAL. Array containing a list of the JWE [@!RFC7516] encryption algorithms (algvalues) [@!RFC7518] supported by the Credential and/or Batch Credential Endpoint to encode the Credential or Batch Credential Response in a JWT [@!RFC7519].credential_response_encryption_enc_values_supported: OPTIONAL. Array containing a list of the JWE [@!RFC7516] encryption algorithms (encvalues) [@!RFC7518] supported by the Credential and/or Batch Credential Endpoint to encode the Credential or Batch Credential Response in a JWT [@!RFC7519].*: OPTIONAL. Boolean value specifying whether the Credential Issuer requires additional encryption on top of TLS for the Credential Response and expects encryption parameters to be present in the Credential Request and/or Batch Credential Request, with
trueindicating support. When the value istrue,credential_response_encryption_alg_values_supportedparameter MUST also be provided. If omitted, the default value isfalse.