[Openid-specs-risc] openid/sharedsignals: Comment created on issue 140

[github at oidf.org]

openid/sharedsignals event

Issue Comment created on issue 140
Issue Title: Proposal to add jwks.json to Receiver
https://github.com/openid/sharedsignals/issues/140

Comment: In a traditional way like the [OpenID Connect Dynamic Client Registration 1.0](https://openid.net/specs/openid-connect-registration-1_0.html) specification (OIDC DynReg), an entity that receives encrypted data does either (1) register its public key in advance to the entity that encrypts data (e.g. through the `jwks` client metadata in the case of OIDC DynReg) or (2) make its public key publicly available and convey the location of the key to the entity that encrypts data (e.g. through the `jwks_uri` client metadata in the case of OIDC DynReg). A new flexible way adopted by the [OpenID for Verifiable Credential Issuance](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html) specification (OID4VCI) is to include a public key for encryption in a request at runtime through a dedicated parameter. In the case of OID4VCI, the parameter is `credential_response_encryption`. The value of the parameter is a JSON object that contains the following properties. | property | description | |:--|:--| | `jwk` | A public key in the JWK ([RFC 7517](https://www.rfc-editor.org/rfc/rfc7517.html)) format. | | `alg` | A JWE ([RFC 7516](https://www.rfc-editor.org/rfc/rfc7516.html)) `alg` algorithm. | | `enc` | A JWE ([RFC 7516](https://www.rfc-editor.org/rfc/rfc7516.html)) `enc` algorithm. | This new approach may be worth considering.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20240209/b4ae0f26/attachment.html>