OpenID4VCI metadata parameter jwks

openid / federation-wallet

Defines how to perform trust establishment for Wallet ecosystems with OpenID Federation

4 stars 3 forks source link

OpenID4VCI metadata parameter jwks #13

Open peppelinux opened 3 months ago

peppelinux commented 3 months ago

Each entity within wallet ecosystems may need to sign requests, responses, and more stringently, credentials, assertions, attestations, etc. Currently, OpenID4VCI does not include public keys for signature verification within the metadata, which ideally should be available in other types of metadata (e.g., SD-JWT VC). This omission creates confusion among implementers and in particular a gap for implementers that needs to issue other credential data formats, not sd-jwt vc.

This evidence can be partially found in the conversation started within the issue below: https://github.com/openid/OpenID4VCI/issues/324

other issues will be found if existing and tracked within this thread.

jogu commented 3 months ago

I think it's important to separate out the different key uses.

https://github.com/openid/OpenID4VCI/issues/324 is about encryption keys, which are often ephemeral and hence would NOT be put into metadata.

https://github.com/openid/OpenID4VCI/issues/62 is actually the most relevant one for verifying credential signatures, at least for mdoc, but there is definitely no consensus that this is a good idea.

selfissued commented 3 months ago

I agree with the need to know whether a key is used for signing or encryption. Both https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata and https://openid.net/specs/openid-connect-registration-1_0.html#ClientMetadata include this language in their jwks_uri parameter definitions:

When both signing and encryption keys are made available, a use (public key use) parameter value is REQUIRED for all keys in the referenced JWK Set to indicate each key's intended usage.

We should probably do the same.

jogu commented 3 months ago

Yes, I agree - but that doesn't change the fundamental issue that many people want signing keys to be pretty static and encryption keys to be per-wallet-instance and short lived (and as far as I can see, putting short lived per-instance keys into the federation metadata is a complete non-starter practically - if I've missed something that means having 1000s of wallets updating an entity statement during 60 seconds is a concept that will actually work well please do correct me!).

peppelinux commented 2 months ago

@jogu I have misunderstood your comment for sure, I try to put the following schema:

wallet instance cryptographic public keys should be ephemeral, the VCI that wants to encrypt something will use one of those of the wallet instance and for the scope of a single protocol exchange
openid4vci metadata cryptographic public keys should be in the metadata

wallet instance that needs confidentiality with the vci uses vci's public crypto keys to encrypt stuffs for the vci. May I ask what about the use cases of having them ephemerals?