cryptographic_binding_methods_supported Support for listing specific DID methods?
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 aredid
,jwk
, andmso
.
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.
Comments (10)
-
-
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 bydid:example
. Support for all DID methods is indicated by sendingdid
without any method-name.
-
reporter 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
andmso
. My proposal is to make it similar to the SIOPv2 approach, where it can also includedid:example
,did:key
etc. Why could we not haveanoncreds
orwhatever
with evenwhatever/keytype
to express support? -
- changed status to open
agree to add concrete DID methods
-
@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.
-
reporter Ah cool. Thanks for the clarification. That makes sense indeed
-
PR #361 (I did it yesterday, might need to catch up with your latest conversation)
-
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.
-
Filed issue
#1723for 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. -
- changed status to resolved
PR merged
- Log in to comment
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.