Consider removing `cwt` proof type

[awoie]

It would be worth discussing whether we should remove the cwt proof type for the following reasons:

• The encoding of cwt proofs is not fully specified. I guess it is supposed to be base64url of the COSE_Sign1 structure. But given that nobody complaint about this not being specified, my assumption is that there cannot be many implementers.
• Even if implementers want to avoid using JOSE in favor of COSE, they won't be able to do that in a lot of cases because they will likely need wallet attestations/oauth attestation-based client authentication that will represent probably the same keys and proofs as JWKs and JWTs. To be clear, I'm not recommending we should add cwt proofs to those drafts.

[babisRoutis]

Totally agree.

[TakahikoKawasaki]

Well, I have already implemented the CWT Key Proof for the Interop Event that POTENTIAL has been hosting. The Interop Event consists of 6 tracks. In the Track 1, CWT Key Proof is used. Demo steps using CWT Key Proof are written here in detail:

4.3. POTENTIAL Interop Event / Track 1 / Light Profile
https://www.authlete.com/developers/oid4vci/#43-potential-interop-event--track-1--light-profile

An open-source CBOR library (authlete/cbor) I have written contains a tool for generating a CWT Key Proof. It can be used like below.

git clone git@github.com:authlete/cbor.git
cd cbor
mvn compile
./bin/generate-cwt-key-proof \
    --issuer ${CREDENTIAL_ISSUER_IDENTIFIER} \
    --key ${PRIVATE_KEY_FILE} \
    --client ${CLIENT_ID} \
    --nonce ${C_NONCE}

The name of the property, cwt, naturally implies that the format of a CWT Key Proof conforms to "RFC 8392 CBOR Web Token (CWT)". Therefore, there is no ambiguity. My OID4VCI implementation can accept the following formats.

• COSE_Sign
• COSE_Sign1
• COSE_Sign with the CWT CBOR Tag (RFC 8392, 6. CWT CBOR Tag)
• COSE_Sign1 with the CWT CBOR Tag (RFC 8392, 6. CWT CBOR Tag)

If the specification of CWT Key Proof were to be removed, someone from the DCP WG would need to explain to the person in charge and the participants of the POTENTIAL Interop Event Track 1 that the CWT Key Proof specification is being discontinued and should not be used.

To discontinue the specification of CWT Key Proof, convincing reasons are needed.

[paulbastian]

@TakahikoKawasaki neither the ISO document nor the POTENTIAL document mentions cwt, in fact the example in ISO is given with jwt, so I think you have some assumptions here that are not reflected in the standards.

Edit: I seem to be wrong... No clue how that got in there

[TakahikoKawasaki]

@paulbastian
LSP_POTENTIAL_Interop-Event_Description_Track1_v5.pdf mentions CWT Key Proof. The section, "IV. Parameter specification", explicitly says as follows.

The proof_types_supported value in the credential issuer metadata is cwt

In addition, "(2.2) OID4VCI metadata" in "(iii) Worked examples of OID4VCI mdoc profile" shows "a non-normative minimum viable OID4VCI metadata configuration for the light profile" that includes:

// indicates CWT is supported in the credential request as proof type
// may contain additional entries
"proof_types_supported": {
  "cwt": {
    // these indicate ES256 with P-256 is supported
    // may contain additional entries
    "proof_alg_values_supported": [ -7 ],
    "proof_crv_values_supported": [ 1 ]
  }
},

Also, "(5) Worked examples of credential request/response" contains the following:

{
  "format":"mso_mdoc",
  "doctype":"org.iso.18013.5.1.mDL",
  "proof": {
    "proof_type": "cwt",
    "cwt": "..."
  }
}

Are you talking about other Tracks of the POTENTIAL Interop Event? For example, Track 2 uses SD-JWT VC and does not use mdoc.

[paulbastian]

I think this has not been present in earlier versions.

The ISO specification still doesn't make a choice on this and I'm tending to agree with Oliver here.

[TakahikoKawasaki]

The operator of POTENTIAL Track 1 removes the previous version from the Git repository when they upload a new version of "LSP_POTENTIAL_Interop-Event_Description_Track1_v{?}.pdf". (IMO, this is a bad practice.)

In any case, the statements "We will not use the CWT Key Proof specification", "We believe people prefer the JWT Key Proof to the CWT Key Proof", "We don't think vendors would implement the CWT Key Proof specification" are different issues from "We should remove the CWT Key Proof specification that has been approved as part of OID4VCI ID1 from the approved specification."

Those who want to prohibit CWT Key Proof can develop their own "profiles" (similar to how POTENTIAL Track 1 has created the "light" profile and the "full" profile), and they don't have to attempt to make breaking changes to the base specification.

[bc-pi]

The name of the property, cwt, naturally implies that the format of a CWT Key Proof conforms to "RFC 8392 CBOR Web Token (CWT)". Therefore, there is no ambiguity.

The suggested ambiguity is in how that binary structure is included as a string in the Credential Request JSON. Which is definitely not specified in OpenID4VCI.

[TakahikoKawasaki]

In standard specifications related to CBOR, CBOR data is represented as hexadecimal strings. I guess that this is primarily because the hexadecimal notation is much easier for explaining the CBOR specification compared to base64(url).

On the other hand, as "7.3. Credential Response" of OID4VCI says as follows:

The encoding of the Credential returned in the credential parameter depends on the Credential Format. Credential Formats expressed as binary data MUST be base64url-encoded and returned as a string.

CBOR-based credentials must be represented in the base64url notation. (I initially used the hexadecimal notation in my OID4VCI implementation, but switched to the base64url notation after discovering this requirement in the specification.)

Therefore, I naturally assumed that a CWT Key Proof in a credential request should also be represented as base64url. However, as you pointed out, the "7.2.1.3. cwt Proof Type" section does not specify the notation for CWT Key Proof.

To resolve this ambiguity, it would suffice to add one sentence to the specification such as "the value of the cwt property MUST be base64url-encoded." Lack of this sentence cannot be a convincing reason to drop the entire specification of CWT Key Proof.

[bc-pi]

... "the value of the cwt property MUST be base64url-encoded." Lack of this sentence cannot be a convincing reason to drop the entire specification of CWT Key Proof.

It's not a reason in and of itself, but it is evidence that very few people are even looking at this part of what is already an arguably too long and complicated specification. I would even suggest that your explanation of how you arrived at base64url versus hexadecimal is further evidence of thereof.

Somewhat related, what did your implementation do with the content type? The way it's defined doesn't seem like it could possibly be correct https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-13.html#section-7.2.1.3-2.1.2.2

[Sakurann]

since POTENTIAL LSP mandated cwt proof type, i think it would be wise to wait for their implementation feedback before we make a decision to remove or keep cwt proof type.

[Sakurann]

@bc-pi from your emojis, you seem to be very excited at the potential of removing cwt proof type.

The way it's defined doesn't seem like it could possibly be correct https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-13.html#section-7.2.1.3-2.1.2.2

can you please elaborate why? cwt claims can be of value type text string.

[babisRoutis]

I believe that @awoie in his initial comment provided the best reason for simplifying VCI by removing CWT proofs:

It cannot be used with attestation-based client authentication ( A requirement of ISO23220-3 & HAIP, if I am not mistaken)

Even for POTENTIAL LSP it is not clear, at least to me, how & if attestation-based client authentication can be implemented in their full profile when using CWT.

[awoie]

Another issue that I have with cwt is the usage of the String label COSE_Key to convey the actual key. CWTs typically use integer identifier for this. Using String labels is not the natural way COSE would do that.

Instead of using COSE_Key the spec should have probably used cnf (8) with COSE_Key (1).

[awoie]

I think this has not been present in earlier versions.

The ISO specification still doesn't make a choice on this and I'm tending to agree with Oliver here.

JFYI: ISO does not use cwt either. I remember when we had our initial conversations with the interop event organizers that they insisted on cwt (for Track 1) which is why the latest profile is using it as well. AFAIK, the initial proposal we did on Track 1 used jwt.

[awoie]

Another issue I found is the requirement to use the content type header which MUST be set to openid4vci-proof+cwt. This is not how the content type header is used normally. It indicates what is secured, not what the CWT is. Note that the jwt proof type uses typ instead of cty. IANA just registered typ for CWTs and assigned the number 16.