Clarification about use of key attestations in JWT proofs

[vafeini]

Need some clarification about the usage of key attestations in JWT proof type.

Spec mentions the following text in section jwt Proof Type

The Credential Issuer SHOULD issue a Credential for each cryptographic public key specified in the attested_keys claim within the key_attestation parameter.

I am bit confuzed on what is the intention behind this. My understanding is that in the case of JWT proofs issuer should issue one credential per jwt proof sent by the wallet. Why should this change if key attestation is used in the header of the JWT proof?

[babisRoutis]

To my understanding,

• Credential issuer should issue a Credential for each JWT proof.
• key_attestation JOSE header is an optional way to validate that the pub key (used to validate the proof signature) comes from a WCSD that meets issuer requirements.

The Credential Issuer SHOULD issue a Credential for each cryptographic public key specified in the attested_keys claim within the key_attestation parameter

I believe that the above text probably needs to be updated.

[Sakurann]

@vafeini @babisRoutis i think there is misunderstanding. the whole point of defining an option to pass key attestation in the header of JWT proof type was to enable use cases where key attestation includes all of the keys that are being attested to with only one of those being used to sign the JWT proof type. which means that when a JWT proof is used with key_attestation in the header there is no need for the wallet to send one credential per jwt proof.

in other words, key_attestation in the jwt proof header (A) achieves the same things as attestation proof type (B). we kept these two options that do not require a proof per key because there can be different architectures: A allows key_attestation to be pre-generated and freshness comes from the nonce in the jwt proof type, while B allows to generate fresh key attestations.

cc @paulbastian @c2bo

[babisRoutis]

Dear @Sakurann

Thank you for your detailed response.

It seems that the semantics of a JWT Proof have changed significantly. Depending on the header of the JWT Proof it may:

• Indicate the issuance a single credential instance (when there is no key_attestation), or
• Indicate the issuance of multiple credential instances, otherwise

I have the impression that the description of the JWT proofs doesn't convey clearly those new semantics, especially for implementers that have followed VCI up to draft 14.

After the removal of proof parameter, JWT proofs are provided as an array (inside the proofs parameter). Specification doesn't prevent a wallet from sending JWT proofs mixed (some with - different- key_attestation headers, others without key_attestation).

Perhaps a rule could be added that requires that jwt to be either

• a non-empty array of JWT proofs without key_attestation header, or
• an array with a single JWT Proof having a key_attestation header

[Sakurann]

specification doesn't prevent a wallet from sending JWT proofs mixed

why is this a problem? Not sure I see a problem

also assuming you meant to say Perhaps a rule could be added that requires that **proofs** to be either

[Sakurann]

chair hat on. pending close in a week unless objections.

[babisRoutis]

specification doesn't prevent a wallet from sending JWT proofs mixed

why is this a problem? Not sure I see a problem

Dear @Sakurann

Is there a case where a wallet would send (or an issuer would expect) a credential request that has

a) Two or more JWT proofs that contain key_attestation header (probably with different keys)? b) Mix JWT proofs with and with out key_attestation header (to the same credential request)

IMHO, there isn't such case.

The text bellow, I think - correctly - calls to either send an attestation or a single JWT proof with key_attestation header. The only problem is that after the removal of the single proof, the description bellow was not updated.

There are two ways to convey key attestations (as defined in Appendix D) of the cryptographic key material during Credential issuance: The Wallet uses the jwt proof type in the Credential Request to create a proof of possession of the key and adds the key attestation in the JOSE header. The Wallet uses the attestation proof type in the Credential Request with the key attestation without a proof of possession of the key itself.

Anyway, it seems that for other reviewers/implementers it is clear (judging by the absence of comments)

[jogu]

@babisRoutis I think we're missing a description of the problem. I think you're perhaps saying "the current text makes implementing an issue more complex because " but it would be very helpful if you explicitly stated the problem if you see one :)

However I agree the text you point out is a bit weird. I've opened a PR to try and clarify that text: https://github.com/openid/OpenID4VCI/pull/524

[babisRoutis]

@babisRoutis I think we're missing a description of the problem. I think you're perhaps saying "the current text makes implementing an issue more complex because " but it would be very helpful if you explicitly stated the problem if you see one :)

However I agree the text you point out is a bit weird. I've opened a PR to try and clarify that text: #524

Hi @jogu

I believe two areas could be potentially improved

• The description of single JWT-Proof (content)
• The description the Proofs

For the description of a JWT proof 8.2.1.1:

The Credential Issuer SHOULD issue a Credential for each cryptographic public key specified in the attested_keys claim within the key_attestation parameter.

This phrase should be made conditional, since it is not applicable in general, but only if key_attestation is present. Furthermore, it describes the behavior of the Credential Issuer partially. For instance what the issuer should do in case there isn't key_attestation?.

IMHO, this phrase could be removed from the paragraph, given that it is related to the processing of the credential request and not the content of the jwt proof.

kid: OPTIONAL. JOSE Header containing the key ID. If the Credential shall be bound to a DID, the kid refers to a DID URL which identifies a particular key in the DID Document that the Credential shall be bound to. It MUST NOT be present if jwk is present. jwk: OPTIONAL. JOSE Header containing the key material the new Credential shall be bound to. It MUST NOT be present if kid is present. key_attestation: OPTIONAL. JOSE Header containing a key attestation as described in Appendix D

The kid and jwk are explicitly mutually exclusive. It is not clear to me, if key_attestation is also mutually exclusive to kid and/or jwk, or if it can co-exist with either of them.

In addition, as all of the attributes of the JOSE header are optional, except typ & alg, a JWT Proof can be sent having neither kid, nor jwk, nor key_attestation. Does this makes sense? I guess not.

Finally, returning to the multiple jwt proofs of the credential request. To my understanding this was a key change to unlock batch issuance after the batch endpoint was removed.

Until the introduction of key_attestation to a JWT proofs (and attestation proof type), this was the only option to convey multiple pub keys with a single credential request.

Yet now, with the new options I think that some further refinement is needed. To be more specific

"proofs": {
    "jwt": [ 
    ]
  }

I have the impression that in case of JWT proofs the jwt array must contain

• either a single JWT Proof having a key_attestation or
• one ore more JWT Proofs having kid, or
• one ore more JWT Proofs having jwk

Hope that helps & thank you for asking

[jogu]

Thanks.

https://github.com/openid/OpenID4VCI/pull/519/files fixes the kid/x5c/jwk point I believe.

I think the claims required or not in the proof is a separate discussion that should go into a separate issue to keep things clear.

For the contents of the JWT proofs array, I don't think that limitation is specified or implied, and it's not clear to me yet why we would want to add that restriction.

[babisRoutis]

Thanks.

https://github.com/openid/OpenID4VCI/pull/519/files fixes the kid/x5c/jwk point I believe.

I think the claims required or not in the proof is a separate discussion that should go into a separate issue to keep things clear.

Indeed probably that's a good idea.

For the contents of the JWT proofs array, I don't think that limitation is specified or implied, and it's not clear to me yet why we would want to add that restriction.

Christina replied something similar a few comments above. Yet, I was wondering in which case a wallet will send a credential request with a "mixed" array of JWT proofs.

For instance, in which case a wallet will place a request having 4 jwt proofs that use kid, 3 jwt proofs using jwk , 2 using x5c and 3 more using key_attestation?

Sorry for asking this again. Frankly, (and obviously) I don't get it.