cryptographic_binding_methods_supported Support for listing specific DID methods?

[Niels Klomp]

The spec states:

• cryptographic_binding_methods_supported: OPTIONAL. Array of case sensitive strings that identify how the Credential is bound to the identifier of the End-User who possesses the Credential as defined in Section 8.1. A non-exhaustive list of valid values defined by this specification are did, jwk, and mso.

‌

Right now it can contain the value did indicating DID support for the issuer. In the JFF plugfest we are now encountering the problem that some issuers support only DID key, whilst others support DID JWK for instance. As a wallet we cannot know up front without hardcoding which methods they support when we create our Proof of Possession. So we would get an error back from the issuers and would have to try again, which isn't really a solution of course.

‌

In SIOPv2 there is subject_syntax_types_supported which allows for only the value did , indicating that the RP supports multiple DID methods. But it also allows to specifically list for instance an array containing did:jwk, did:key . I think it would make sense to have issuers signal their supported DID methods in the cryptographic_binding_methods_supported field, so that a wallet can choose which DID method to use for thier PoP and thus subject value.

[Torsten Lodderstedt]

I agree with the proposal to support listing of concrete DID methods in cryptographic_binding_methods_supported.

I also think the set of binding methods is different across the credential formats, perhaps we don’t even need this parameter for some formats. For example, some formats might just support raw pubic keys, mdoc (ISO 18013-5) does not support DIDs and AnonCreds uses linksecrets only.

So I guess we need to modify the metadata parameters to depend on the credential format as well.

[Kristina Yasuda]

we can borrow a definition from here https://openid.net/specs/openid-connect-self-issued-v2-1_0.html#section-8.2-5.8.1

When Subject Syntax Type is Decentralized Identifier, valid values MUST be a did: prefix followed by a supported DID method without a : suffix. For example, support for the DID method with a method-name "example" would be represented by did:example. Support for all DID methods is indicated by sending did without any method-name.

‌

[Niels Klomp]

Indeed that was what I suggested.

‌

@Torsten Lodderstedt Not sure I understand you correctly, or why current approach would not be satisfactory.

Right now it is a non-exhaustive list that can contain did, jwk and mso. My proposal is to make it similar to the SIOPv2 approach, where it can also include did:example, did:key etc. Why could we not have anoncreds or whatever with even whatever/keytype to express support?

[Kristina Yasuda]

agree to add concrete DID methods

[Torsten Lodderstedt]

@Niels Klomp the SIOP approach might be the next step. However, we have introduced the concept of format specific metadata in the meantime (see https://openid.bitbucket.io/connect/openid-4-verifiable-credential-issuance-1_0.html#name-supported-credentials-objec). So we can make the definition of the metadata even more specific to a certain credential format.

What I’m envisioning is: the credential metadata object has a parameter “format”. If this format is set to, for example, “jwt_vc_json”, the “cryptographic_binding_methods_supported” parameter may contain different DID methods but not “mso” (simply because it does not make sense). For the format “mso_mdoc” there is no variance in binding methods, so no “cryptographic_binding_methods_supported” is needed. And even if we would have it, the range would be “mso” only. Similar for AnonCreds. “format” is “ac_vc”, no need for “cryptographic_binding_methods_supported” as AnonCreds support link secrets only.

‌

[Niels Klomp]

Ah cool. Thanks for the clarification. That makes sense indeed

[Kristina Yasuda]

PR #361 (I did it yesterday, might need to catch up with your latest conversation)

[Torsten Lodderstedt]

I made comments on PR #361. As indicated, I’m ok with first extending the current text to support specific DID methods. I would like to file another PR to align the metadata structure to the needs and capabilities of the different credential formats this way making it more robust.

[Kristina Yasuda]

Filed issue #1723 for the next step suggested by Torsten - I agree it would be beneficial to introduce the concept of credential format profiles to the 4vp spec too.

[Kristina Yasuda]

PR merged