-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The Value of Having JWKS in the Credential Issuer Matadata #385
Comments
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 There is a competing proposal here for mdoc: #62 (which hasn't progressed as there are unanswered questions on the issue). |
I would argue that it would be more consistent to include public cryptographic material within the openid4vci metadata for the following reasons:
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. |
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:
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. 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). 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 |
The 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, 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 As a developer who has actually implemented OpenID Federation and understands its complexity, I support including |
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:
|
@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.
|
Replying to @alenhorvat's comment:
A standard clause when using JWK Sets (in this case, quoted from OpenID Connect Discovery) is:
Defined usages are signing and encryption. We should include JWK Sets and qualify them as above. |
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
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)
So would it make sense to clarify that: OIDC configuration -> jwks/jwks_uri -> id token/userinfo signing keys None of these should be affected by the VC format discovery, etc. |
Exactly @alenhorvat:
OpenID Federation employs this kind of key segregation. The JWK Sets for:
are all distinct. Likewise, they JWK Sets for the different Wallet entity types would all be distinct in the same way. |
@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. |
As a clarifying question, if the VCI issuer and the authorization server use the same issuer url - i.e the |
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
No. The same url correspond to the same entity. Different entities might use different webpaths, like |
Talking to @peppelinux about above part that this is defining a mechanism that overlaps with 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 (and similar things for other credential formats). Adding jwks to VCI metadata potentially creates 3 places the keys could found from (from /.well-known/jwt-vc-issuer, from the VCI issuer metadata, or from the federation entity id's VCI issuer metadata). If we instead add a federation entity type for sd-jwt-vc-issuer, we're only creating one more place for a total of 2 (from /.well-known/jwt-vc-issuer, or from the federation entity id's sd jwt vc issuer's metadata), which seems like a better proposal. This also keeps the flexibility that SD JWT VC can be used with federation without OID4VCI - or at least removes the need for the verifier to be aware of whether the wallet obtained the credential using OID4VCI or not, which seems useful. |
@alenhorvat IMO, the VC signing keys are affected by the VC format a little bit. For ISO mdocs, the key to verify the issuer signature of the mdoc is included in the mdoc itself ( Furthermore, I fully agree that the keys exposed by an AS have a different purpose than the keys exposed by an issuer. I think it is useful to list cryptographic credential verification material in the issuer metadata. But I believe this cannot be limited to JWKS, it has to support at least X.509 as well. IMO, it might even make sense to have credential configuration-specific cryptographic credential verification material for the reason provided above although there might be other architectural options to support this without having it per credential configuration. I propose to add a new parameter
|
I agree. What you're describing is usually called "signature profile" (e.g., JAdES is a JWS profile that has 4 signature types) and is bound to the signature format (and not the payload format, if the credentials are designed well). Maybe it's a good opportunity to define better elements we're discussing about and set down the terminology the WG would agree upon. |
Just for clarify, x.509 certificates can be published in a JWK/JWKS: https://datatracker.ietf.org/doc/html/rfc7517#section-4.7 |
@jogu, yes, but is anyone doing it this way? |
@jogu are you in general supportive of including this in the issuer metadata, and just want to minimize possible encoding options, i.e., X.509 vs JWK? It is just a cleaner approach to define a dedicated issuer metadata for cryptographic credential verification material.
|
I think there are still two fundamental questions:
|
.well-known for SD-JWT VC is SD-JWT VC-specific and even within SD-JWT VC it is a choice an issuer needs to make which also comes with certain tradeoffs compared to other options. It creates some redundancy for SD-JWT VC issuers that chose to use .well-known but it would allow other credential formats and profiles to have access to such a mechanism. IMO, the level of confusion is manageable since these SD-JWT VC issuers can choose to not support this cryptographic credential verification material in their issuer metadata if it becomes an optional metadata.
IMO, it can be the right place. Credential profiles can define a dedicated entry point for OID4VCI well-known to fetch this information, so it becomes available to verifiers as well. |
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.
The text was updated successfully, but these errors were encountered: