<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">

</head>

<body>

openid/sharedsignals event <br>

<br>

Issue Comment created on issue 140 <br>

Issue Title: Proposal to add jwks.json to Receiver <br>

https://github.com/openid/sharedsignals/issues/140 <br>

<br>

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.

</body>

</html>