key attestation in the jwt proof header should be able to be pre-generated...

[Sakurann]

The intent of having both attestation and jwt proof types was the following:
A. jwt proof type: key_attestation in the jwt proof header can be pre-generated (attested keys in the attestation can also be pre-generated), and jwt proof signed using one of the attested keys needs to be generated fresh since it contains nonce from the issuer.
B. attestation proof type: all attested keys can be pre-generated, and key attestation needs to be generated fresh since it contains nonce from the issuer.

However, there is this text for key_attestation in the jwt proof header, which defeats the intent above because key attestation in jet proof type cannot be pre-generated since it needs to contain a nonce:

key_attestation: OPTIONAL. JOSE Header containing a key attestation as described in Appendix D. If the Credential Issuer provided a c_nonce, the nonce claim in the key attestation MUST be set to a server-provided c_nonce.

original issue #438 pointed to a nonce claim in key attestation jwt itself but the PR #501 added clarification to key attestation claim in the jwt header itself

I think we have two options (still investigating feasibility of both; not advocating for any of these at this point):

1. do an errata of VCI and fix the above by removing "If the Credential Issuer provided a c_nonce, the nonce claim in the key attestation MUST be set to a server-provided c_nonce."
2. define a new proof type in VCI 1.1 that achieves the purpose A above that jwt proof type was supposed to achieve
3. define a new proof type in HAIP 1.0 that achieves the purpose A above that jwt proof type was supposed to achieve

[babisRoutis]

Dear @Sakurann

The introduction of a new Proof type probably will express the intent in a more accurute way, but then, specification would be left with a Proof type jwt that is "unintentionally" more complex that needed.

Hope (1) is feasible

[TimoGlastra]

To me option 1 also seems best, as the restriction in the current spec seems unintentional.

I checked our implementation and we actually don't enforce the nonce being present when using jwt proof type (but we do when using attestation proof type), since we initially based our key attestation implementation on the pre-draft 16 text, which clearly distinguished between the two options:

• for attestation key type the key attestation MUST use a nonce
• for jwt proof type the key_attestation MUST use exp.

If there's valid uses cases for using nonce in the key_attestation when using jwt proof type (i'm not sure if there is when you can also use attestation proof type), a new proof type might be better, but I wonder if it won't just hinder interoperability due to a third way of including a key attestation.

I'm not a big fan of adding it to HAIP. It seems like an issue that should be solved within OID4VCI.

[tlodderstedt]

WG call: Mike explained the errata process to us. We need to decide whether this issue will be fixed in an VCI 1.0 errata.

[tlodderstedt]

@paulbastian will check back with the ETSi editor to figure out the best way to refer to the VCI from the ETSi spec.

[jogu]

I couldn't find any text mentioning that the jwt proof type + attestations was intended to be usable with long-lived / pre-obtained key attestations - we might want to incorporate this somewhere in introductory text or similar at the same time.

[babisRoutis]

I couldn't find any text mentioning that the jwt proof type + attestations was intended to be usable with long-lived / pre-obtained key attestations - we might want to incorporate this somewhere in introductory text or similar at the same time.

Couldn't agree more 👍

[awoie]

Wouldn't we have the same issue with the attestation proof type of type key attestations?

In Annex D, we have:

nonce: OPTIONAL. String that represents a nonce provided by the Issuer to prove that a key attestation was freshly generated

We don't have another mechanism than c_nonce values from the nonce endpoint for this, or am I missing something?

[awoie]

I couldn't find any text mentioning that the jwt proof type + attestations was intended to be usable with long-lived / pre-obtained key attestations - we might want to incorporate this somewhere in introductory text or similar at the same time.

Couldn't agree more

I think it was not clear to me either that the difference between jwt+key attestations and attestation proof type was that they can be pre-generated. I thought the difference was the missing pop. This should be documented.

[awoie]

After reading the issue a few times, and not really understanding where the issue is, because I thought that what is needed is already possible, I came to the conclusion that the sentence is indeed just not clear enough. I was reading the following:

JOSE Header containing a key attestation as described in Appendix D. If the Credential Issuer provided a c_nonce, the nonce claim in the key attestation MUST be set to a server-provided c_nonce.

... AS follows ... if the nonce param is present, then it MUST be set to a server-provided c_nonce. In this case, the jwt proof can have a key attestation without a nonce and the problem is solved. I do think that this is apparently not clear enough and needs an errata though. There is no such thing as nonce MUST be present, it just means that the nonce has to be the c_nonce if provided.

Perhaps, it becomes more clear if it reads as follows:

JOSE Header containing a key attestation as described in Appendix D. If the Credential Issuer provided a c_nonce, if present the nonce claim in the key attestation MUST be set to a server-provided c_nonce.

What is actually needed is that it is possible to pre-generate key attestations before contacting the issuer. With the approach above it should be possible. Do you agree @Sakurann ? If this is the case, then the intention even with the current text is that nonce can be optional in the key attestation inside a jwt proof but I'm fine with an errata that clarifies this.

If the nonce is not provided by the issuer, then it cannot be checked by the issuer and just serves as additional entropy. If this is needed, then jti can be used, or the nonce of the jwt proof can provide this entropy already. Although there is probably no need for additional entropy since the public keys should have enough entropy anyways.

[Sakurann]

yes, i agree with @awoie

key_attestation: OPTIONAL. JOSE Header containing a key attestation as described in Appendix D. If the Credential Issuer provided a c_nonce, the nonce claim in the key attestation MUST be set to a server-provided c_nonce.

this text is meant to be read as " If the Credential Issuer provided a c_nonce, the nonce claim in the key attestation MUST be set to a server-provided c_nonce (if nonce is present in the key attestation)." current text does not say that nonce must be present in the key attestation, it only says that the value needs to be set to c_nonce if the wallet wants to use it. hope this makes sense.

in summary...
if there's a nonce endpoint, nonce in jwt proof type body and key attestation proof type is mandatory for wallet to send. but it's up to the wallet whether to put nonce into key attestations in the jwt proof type header

so i think it is ok if we clarify this in VCI 1.1

[charsleysa]

" If the Credential Issuer provided a c_nonce, the nonce claim in the key attestation MUST be set to a server-provided c_nonce (if nonce is present in the key attestation)."

Isn't this already covered in Annex D.1?

nonce: OPTIONAL. String that represents a nonce provided by the Issuer to prove that a key attestation was freshly generated.

[babisRoutis]

" If the Credential Issuer provided a c_nonce, the nonce claim in the key attestation MUST be set to a server-provided c_nonce (if nonce is present in the key attestation)."

Isn't this already covered in Annex D.1?

nonce: OPTIONAL. String that represents a nonce provided by the Issuer to prove that a key attestation was freshly generated.

The problem is here, I think

key_attestation: OPTIONAL. JOSE Header containing a key attestation as described in Appendix D. If the Credential Issuer provided a c_nonce, the nonce claim in the key attestation MUST be set to a server-provided c_nonce

[awoie]

" If the Credential Issuer provided a c_nonce, the nonce claim in the key attestation MUST be set to a server-provided c_nonce (if nonce is present in the key attestation)."

Isn't this already covered in Annex D.1?

nonce: OPTIONAL. String that represents a nonce provided by the Issuer to prove that a key attestation was freshly generated.

The problem is here, I think

key_attestation: OPTIONAL. JOSE Header containing a key attestation as described in Appendix D. If the Credential Issuer provided a c_nonce, the nonce claim in the key attestation MUST be set to a server-provided c_nonce

IMO, this does not say that the nonce MUST be present. In other places we say this explicitly. I read it as: if the nonce is present, it MUST be set to a server-provided c_nonce. In this case, it is a wallet decision whether or not the key_attestation in the jwt proof contains a nonce. If there is a nonce, then it must be the c_nonce if the issuer has a nonce endpoint. Note that there is enough entropy anyways even without setting the nonce in the key_attestation because of the contained public keys. Also note that for attestation proof type, it is a wallet decision whether the nonce is present but if present, it must be the c_nonce value.

For example, for jwt proofs, we say explicitly two things 1) that the nonce MUST be the c_nonce, and 2) that it MUST be present if nonce endpoint is provided:

nonce: OPTIONAL (string). The value type of this claim MUST be a string, where the value is a server-provided c_nonce. It MUST be present when the issuer has a Nonce Endpoint as defined in Section 7.

For key_attestation in jwt proofs, we just say 1) what the value must be set to in case it is present.

Because I agree that this is not very clear, we should have an errata.

To allow pre-generated keys, one can use a jwt proof with/without nonce param, and key_attestation without nonce parameter. Essentially these combinations are possible:

• jwt proof with nonce; key_attestation with nonce
• jwt proof with nonce; key_attestation without nonce
• jwt proof without nonce; key_attestation without nonce

The following combination is not allowed or possible as per spec because if there is a nonce endpoint, the jwt proof must contain a nonce value (violated below because nonce must be present but is not present), and if there is a nonce in key_attestation then it must be a nonce from the nonce endpoint (requires nonce endpoint to be possible).

• jwt proof without nonce; key_attestation with nonce

But if the nonce is present, then it must be the c_nonce in case the issuer provided a nonce endpoint.