The Value of Having JWKS in the Credential Issuer Matadata

[peppelinux]

As promised during the previous DCP WG call, here I create the issue to introduce the value of having the parameters jwks within the openid4vci metadata, as proposed also in the federation wallet draft, here: peppelinux/federation-wallet#13 (comment)

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.

[jogu]

Thanks Giuseppe! For clarify this issue is titled 'issuer metadata' so I will only address that aspect:

Credential issuers do not make signed responses, nor can they receive signed requests. They don't generate assertions or attestations, at least as far as I remember in the VCI specification.

The only thing I can see they have do that might require a jwks is sign credentials. SD-JWT VC already has a different solution proposed here https://github.com/oauth-wg/oauth-sd-jwt-vc/blob/main/draft-ietf-oauth-sd-jwt-vc.md?plain=1#L381 - namely /.well-known/jwt-vc-issuer - note that this location is specific to sd-jwt-vc's. An earlier version of the spec proposed a more generic .well-known/jwt-issuer which the OAuth WG was very unhappy with as it could result in keys for very different purposes ending up in the same jwks, and I believe the same concern may apply to a jwks entry in credential issuer metadata - i.e. keys should be stored in more specific locations that clearly separate what they are to be used for.

There is a competing proposal here for mdoc: #62 (which hasn't progressed as there are unanswered questions on the issue).

[peppelinux]

I would argue that it would be more consistent to include public cryptographic material within the openid4vci metadata for the following reasons:

1. It would generally be advantageous to make openid4vci independent of other metadata resources for credential issuance purposes.
2. It would ensure that the issuance of any credentials is consistent in their configuration within the openid4vci metadata.
3. It would prevent the dispersion or fragmentation of configurations related to individual credentials across multiple .well-known resources.
4. It would consolidate the role of VCI in a context where the distribution of a single metadata is possible and adequate. This way, if a trusted third party needs to distribute the VCI metadata, they can use a single signed artifact containing all necessary information. Currently, we already have a distinction between the authorization server and openid4vci, requiring two different metadata (mitigated with OpenID Federation Entity Configuration). Continuing to encourage this fragmentation would be concerning for implementers.
5. It would make openid4vci self-consistent and generalist for any type of credential that might be introduced in the future, so that a new credential data format does not necessarily require a new .well-known for key distribution.

To avoid introducing breaking changes, I propose resolving this issue by introducing the jwks and jwks_uri parameters within the openid4vci metadata as OPTIONAL, containing all public keys controlled by openid4vci.

[alenhorvat]

I agree with @jogu that purpose of the keys must be well or at least better defined. Note that proposal #62 mentioned above falls in the same category.

JWK RFC (https://datatracker.ietf.org/doc/html/rfc7517#section-4.2) supports public key metadata, such as:

• use
• key_ops
• x5c/x5u+x5t

So in theory, jwks/jwks_uri could host public keys used for different purposes and also keys for the IACA since an x509 certificate can embedded with/referenced with a JWK.

However, for this to work, it should be well defined how to publish the keys and how to use the different properties correctly.
IMO, key_use is currently too limited, and (if this is the path to take) to be extended similar to how x509 v3 allows to extend the key usage.

Note that signature formats define how to resolve the public keys needed to verify a signature (e.g., via x5c, x5u (not used), trust_chain of OIDFed, jwk/kid header params, etc).
Each mechanism defines how the public key is bound to the issuer (x509 -> explicit, OIDC/OAuth via URL matching, OIDFed via signed metadata, ...)
Hence, in all signed VCs that are using established signature frameworks, it is already defined how to resolve the signing keys.

Open question: when a wallet receives a VC from an issuer using OID4VCI, how to link the URL of the issuer and the public key used to sign the VC? For this purpose, there should be a link between the VC signing keys and the issuer URL.

Note that this does not solve the problem of distributing the root keys/certificates. Those need to be
a) delivered out of band (e.g., TLS root directory)
b) fetched via a trusted resource (e.g., EUTL, OIDC/OAuth, ...) where trusted resources (URLs) are delivered out of band

[TakahikoKawasaki]

The jwks and jwks_uri parameters in the credential issuer metadata (/.well-known/openid-credential-issuer) can coexist with the jwks and jwks_uri parameters in the JWT VC issuer metadata (/.well-known/jwt-vc-issuer).

The former could serve as the default or fallback location for retrieving keys, while the latter could be used for keys specific to (SD-)JWT-based VCs.

It could be said that the former serves as a key distribution mechanism from the issuer's perspective, while the latter serves as one from the verifiable credential's perspective, despite the latter's path, /.well-known/jwt-vc-issuer, containing issuer.

It is clear that the former approach is highly compatible with OpenID Federation, which is based on trust between federation entities. In OpenID Federation, a credential issuer is considered a type of federation entity.

Looking back, the reason the discussions around the latter approach became so contentious and confusing is that, despite being a key distribution mechanism specific to the verifiable credential format, the well-known path contained the term "issuer", as in /.well-known/jwt-issuer or /.well-known/jwt-vc-issuer. Had it used a different name, such as /.well-known/verifiable-credential/sd-jwt-vc, it likely wouldn’t have caused such confusion.

As a developer who has actually implemented OpenID Federation and understands its complexity, I support including jwks and jwks_uri in the credential issuer metadata. I believe the OID4VCI specification should allow ecosystems to use jwks and jwks_uri within the credential issuer metadata at their discretion.

[jogu]

I think I remain concerned that 'jwks' is a very generic name and it looks too much like it would be a sensible place to publish keys if the issuer in the future does need to sign something other than a credential, and we seem to have agreement that mixing keys for different uses in one location is a bad idea.

I think we always need more details on the proposal - for example:

1. I'm not clear what is being proposed for sd-jwt vc - is that out of scope of jwks, do the keys need to be published in both places, or is it proposed to remove the sd-jwt-vc-issuer? (the latter not being something this WG can decide on, but it would still be useful to know the intent)
2. what exactly does the JWK for mdl, mdoc, w3c vc, and sd-jwt vc look like? We should at least have examples to go in the spec, but I'm not clear what normative text we might need.
3. I think for at least mdoc we need a description of how the verifier would get the credential issuer entity id from the credential (the wallet obviously knows where it got from the credential from, but once we're one step further down the chain at the verifier I'm struggling to see how it works)

[peppelinux]

@jogu my reaction to your concern is that, according to the agreed-upon best practice of specializing cryptographic keys for specific purposes, nothing prevents us from using the parameter jwks in each credential configuration instead of having it at the top level.

In OIDC Core we didn't have specialized keys for AT (if JWT), ID Token, UserInfo (with or without nested JWT) and so on, but the granularity obtained within the openid credential issuer metadata allows this advancement, therefore I tend to support this to remove any kind of blocking concern.

1. I'd suggest to work on a self-consistent and general purpose standard: openid4vci. Other specification might work without any conflict with openid4vci. Using openid4vci and having all the credential configurations within the openid credential issuer it makes sense to have also the jwks for the signature validation.

2. JWK supports at least X.509, there might be space also for DID, using namespaces within the kid parameter. At the end a cryptographic key is a sequence of bytes, while x.509, jwk, base16 or whatever are only different representations of that sequence, with, sometimes, additional metadata. For the scope of signature validation we only need the cryptographic key.

3. It would be CN and or SAN URL for that

[selfissued]

Replying to @alenhorvat's comment:

purpose of the keys must be well or at least better defined

A standard clause when using JWK Sets (in this case, quoted from OpenID Connect Discovery) is:

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.

Defined usages are signing and encryption.

We should include JWK Sets and qualify them as above.

[alenhorvat]

Thank you @selfissued. I fully agree with this and this part is clear. I also support having jwks/jwks_uri in the credential metadata.

What I had in mind, but didn't express well, is what @TakahikoKawasaki explained - confusion that appears due to /.well-known/jwt-issuer or /.well-known/jwt-vc-issuer;

If someone reads the specs, they will end up with

• authorization server keys (used to sign ID Tokens, userinfo)
• credential issuer keys (used to sign credentials)
• vc-format specific mechanism for key resolution (used to sign credentials)

I guess federation server (if running along with an AS) is using same keys to sign entity statements and ID tokens, but probably the 2 keys could be different? - Please correct me here.

However, we have 2 or 3 keys used for different "signing purpose" (not the best term)

• ID tokens/userinfo signing keys -> run next to the Authorization Server
• VC signing keys -> can be in an HSM/certified/... -> whatever is required by the framework
• Entity statement signing keys?

So would it make sense to clarify that:

OIDC configuration -> jwks/jwks_uri -> id token/userinfo signing keys
VCI configuration -> jwks/jwks_uri -> VC signing keys
Entity configuration -> jwks/jwks_uri -> entity statement signing keys?

None of these should be affected by the VC format discovery, etc.

[selfissued]

Exactly @alenhorvat:

So would it make sense to clarify that:
OIDC configuration -> jwks/jwks_uri -> id token/userinfo signing keys
VCI configuration -> jwks/jwks_uri -> VC signing keys
Entity configuration -> jwks/jwks_uri -> entity statement signing keys?

OpenID Federation employs this kind of key segregation. The JWK Sets for:

• Entity Statements
• OPs
• RPs

are all distinct. Likewise, they JWK Sets for the different Wallet entity types would all be distinct in the same way.

[peppelinux]

I guess federation server (if running along with an AS) is using same keys to sign entity statements and ID tokens, but probably the 2 keys could be different? - Please correct me here.

@alenhorvat OpenID Federation uses different keys for different purposes, such as those related to trust evaluation at the top level of the Entity Statement, which are distinct from the keys contained in each metadata type within the same Entity Statement.

[jogu]

As a clarifying question, if the VCI issuer and the authorization server use the same issuer url - i.e the authorization_server parameter in the Credential Issuer Metadata is omitted, how does that work in federation? Can you have two entity statements with the same url but different entity types?

[peppelinux]

@jogu

A single Entity Configuration or Subordinate Statements (technically both Entity Statements) can include the authz server along with the vci metadata (any other at the same time like openid_credential_verifier, openid_relying_party and so on).

an example is here:

https://italia.github.io/eudi-wallet-it-docs/versione-corrente/en/pid-eaa-entity-configuration.html

Can you have two entity statements with the same url but different entity types?

No. The same url correspond to the same entity. Different entities might use different webpaths, like https://entity.example.org/as and https://entity.example.org/vci representing two different entities within the same domain.