Drop all references to DIDs and DID resolution

[leifj]

Section 3.5 references DIDs and DID resolution but does so in a very underspecified way. The document already supports extensibility so there is no reason why specific ecosystem processing rules need to be in this document at all. The DID community should write a profile doc that describes DID related processing rules in detail.

[selfissued]

DIDs are non-interoperable, since there are no mandatory-to-implement DID methods. It's easy for the spec to say "the recipient MUST retrieve the public key from the DID Document resolved from the DID in the iss value" but that doesn't make it practically implementable.

Therefore, I agree with dropping DIDs from the spec. As the spec says, "Separate specifications or ecosystem regulations MAY define rules complementing the rules defined above". Let DIDs be handled in that manner.

[bc-pi]

[Speaking as an individual] I am in 100% agreement with @leifj and @selfissued and favor (or favour here in Canada) of completely removing all the DID content from this draft. For reasons already mentioned. And others.

[peacekeeper]

-1, this is a bad idea for various reasons:

• DIDs provide an extensibility mechanism that makes it much easier to plug in different public key distribution and discovery mechanisms through DID methods. If you want to use a different discovery mechanism than HTTP, you can simply use a DID method for your favorite (decentralized) public key infrastructure. Several DID methods are already specified, implemented, and used in production.
• The argument "DIDs are non-interoperable, since there are no mandatory-to-implement DID methods" has been discussed many times (e.g. here), so it makes no sense to repeat that here. Due to the design mentioned above, DIDs actually enable interoperability.
• DIDs are used in various large EU projects that also have an interest in SD-JWT VC, e.g. EBSI, Gaia-X, etc. Removing DIDs would create unnecessary interoperability issues for these projects.
• A proposal to include DIDs in the EUDI Wallet's ARF has received more thumbs-ups than any other issue in that repository.
• DIDs are used in various ways in connection with OID4VC and OAuth2, which have a close relationship with this specification here.
• Many implementations and applications of the Verifiable Credentials Data Model (VCDMs) use DIDs. The fact that this specification here has adopted and overloaded the term "VC" is already causing a lot of confusion and technical ambiguity. Removing DIDs from this specification would only lead to further unnecessary divergence.
• The W3C DID Working Group is currently standardizing DID Resolution, and efforts to standardize specific DID methods are also underway.
• The SD-JWT VCDM proposal, which apparently is already being standardized somewhere, mentions that it is based on SD-JWT VC and that it supports DIDs.
• There is also an ideological argument. The concept of VCs has historically emerged out of a desire to enable decentralized identity, self-sovereign identity (SSI), and decentralized public key infrastructure (DPKI), and to use identifiers that are independent of central authorities and intermediaries. To attempt to eliminate elements of decentralization from a specification that contains the term "VC" raises concerns about the goals and values behind this effort.

Please don't reply with "nobody stops you from creating a profile that uses DIDs" or with "standards are about making choices". Support for DIDs is described as optional anyway, so there are no downsides of supporting them, but many upsides (see list above).

[decentralgabe]

The arguments made against DIDs are not only inaccurate (as @peacekeeper notes), they're irrelevant. Retrieving keys from DID Documents in a consistent manner should be all that is needed. This is a close analog to how well-known issuer metadata is resolved with JWKs.

DIDs are and will continue to be used by many organizations, companies, and individuals. Dropping support for them harms interoperability.

What the specification can do, is make it clearer how DIDs can be used with SD-JWT-VCs in a consistent manner. I made a comment here speaking to one such recommendation.

There are already plenty of open source tools and demonstrations that meet this set of capabilities. Not only that, like Markus mentioned, the DID WG is currently working on a Recommendation-track document to further specify DID Resolution, which will only make things better.

There are other ideas we can explore too, like requiring DID Documents to have publicKeyJwk based Verification Methods, which should even further lower the barrier to interoperability.

I am happy to help construct language improvements to Section 3.5 in service of this effort.

[bc-pi]

I understand there are some ardent supporters of DIDs and the VCDM. And some folks who are not. But this issue isn't the place to try and litigate any of that.

[peacekeeper]

@bc-pi What do you mean by "litigate any of that"? Isn't the point of Github issues to discuss (and ideally, offer arguments) whether a certain change should be made or not, in this case, removing DIDs and DID resolution from this specification?

[ssanchocanela]

I'm afraid I have to disagree with this proposal; I don't see any argument in its favour. My proposal is the opposite: to specify examples of DID usage in SD-JWT VC to increase adoption and strengthen the specification. A broad community of wallets supports DIDs, including all those EBSI Conformance. Ignoring DIDs in the specification is a statement of intent.

[bc-pi]

@bc-pi What do you mean by "litigate any of that"? Isn't the point of Github issues to discuss (and ideally, offer arguments) whether a certain change should be made or not, in this case, removing DIDs and DID resolution from this specification?

Well, it sure seems to me that the arguments offered veered well into the territory of general advocacy for the wonders of Decentralized Identifiers from the DID community itself. While also misunderstanding or misconstruing the actual implications of removal from this draft. This issue isn't the place for that. And honestly it's tiresome. Also probably not having the effect you think or hope it is.

[peacekeeper]

Well, it sure seems to me that the arguments offered veered well into the territory of general advocacy for the wonders of Decentralized Identifiers from the DID community itself. While also misunderstanding or misconstruing the actual implications of removal from this draft.

Apologies, I admit I'm not so familiar with the process and culture of this group. If advocacy for the benefits (not "wonders") of a feature that is being proposed for removal is not welcome here, and considered "tiresome", then what would be a more acceptable way of expressing a dissenting opinion about this proposal?

[bc-pi]

Apologies if I've been unable to articulate myself in a meaningful way but I believe the point has been missed.

[kimdhamilton]

Of relevance; for any interested in contributing to DID method standardization: https://identity.foundation/publications/LOI-DIDMethodStandardization.pdf

[leifj]

Getting back to this (apologies for the late feedback). Much has been made in this thread of the importance of DIDs in the ecosystem. My proposal has nothing to do with the importance or non-importance of DIDs but is all about weather the current language is appropriate guidance for implementors. If in fact DIDs are important they deserve more care than half a paragraph and a separate specification that profiles this specification for use with DIDs is imo entirely appropriate in that case. IETF standards are not marketing documents but technical specifications and as such the current language on DIDs is unusable for an implementer.

I propose that the the proponents of keeping DIDs in the current specification open a PR with language that ensures interoperability - something which is clearly a requirement for a standards-track IETF document.

[awoie]

@peacekeeper @kimdhamilton @decentralgabe Do you have an implementation of SD-JWT VC that uses DIDs and did you have the feeling the current spec was clear enough?

[decentralgabe]

@awoie we are planning an implementation at TBD. Reviewing the spec, here is where I think there's room for improvement to support DIDs:

• Section 5 on Issuer Metadata. Supporting other mechanisms to fetch metadata besides /.well-known/jwt-vc-issuer would be useful.

  • Something like being able to fetch this metadata by resolving a DID Document. It could be included directly in a DID Document itself, through a service, or another property registered as an extension. Language speaking to these possibilities and examples would be great.
  • Today, if issuers wanted to use DIDs it would be quite tough to interop with the JWT VC Issuer Metadata ... there would need to be intermediary/translating services to map what a DID surfaces to the expected request/response model defined by this spec.

• Similarly the guidance in 8.1. Server-Side Request Forgery would need to be updated to note retrieving issuer metadata from sources other than the issuer itself, such as a Verifiable Data Registry (VDR) that could house a DID Document.

• The guidance in 8.4 Robust Retrieval of Type Metadata would need to be updated to include deferring resolution guidance to a DID method's best practices. Caching may not always be a recommended approach.

• 9.3. Issuer Phone-Home could mention that certain DID methods prevent this vector entirely, since with DID methods like did:dht issuers would have no way of forcing a phone home.

• As I commented here I would recommend updating this guidance in 3.5 to require absolute DID URL references when using DIDs.

• In 4.1 Key Binding JWT there is room to improve guidance on key binding when interfacing with DIDs. The simple approach would to something like "DID Documents may have multiple keys, or rotate keys over time; however, key binding relies on a persistent key. If that key is removed from a DID Document binding is no longer possible." IOW -- there is no DID Binding but instead there is binding to a key present in a DID Document.

• Another concern when interfacing with DIDs is accessing key material that's not in a JWK format (publicKeyJwk), since other key formats are supported like publicKeyMultibase. A simple solution would be to only support publicKeyJwk, or require those using non-JWK key representations to support a transformation to a JWK.

With these tweaks (and maybe some more...) I would say the spec is "clear enough" in interfacing with DIDs. I hope these points illustrate why I believe it's a bad idea to remove DID content from this spec. Doing so would maintain the existing confusion I highlighted and guarantee interoperability issues.

[peacekeeper]

@awoie We are also working on an implementation, and will be happy to share updates as our work progresses.

[kimdhamilton]

In a former life I made a toy implementation of it and had some minor issues with the sd-jwt spec at the time, but I'm sure those have been addressed. No issues with DIDs in my recollection. Here's the writeup with links to code fwiw, but take this with a grain of salt.

[peacekeeper]

Those who are following this thread here should be aware of a PR that would remove support for DIDs: https://github.com/oauth-wg/oauth-sd-jwt-vc/pull/251

[bc-pi]

standards are about making choices and nobody stops you from creating a profile that uses DIDs

[bc-pi]

My assessment, acting as co-editor of this draft and endeavoring to represent the rough consensus of the WG, is that consensus favors removal of the references.

[peacekeeper]

rough consensus of the WG, is that consensus favors removal of the references

How does the co-editor understand "rough consensus", and how has he come to this assessment?

[decentralgabe]

rough consensus of the WG, is that consensus favors removal of the references

How does the co-editor understand "rough consensus", and how has he come to this assessment?

Clearly, when 5 people express dissent a co-editor can declare "consensus."

[andorsk]

For consensus building, there are a number of RFC's describing the IETF process. The conversations here seem to indicate to me there is no "rough consensus".

In particular, RFC7282 Section 6 and many of the other sections in RFC7282 focused on "rough" consensus building.

Also, it should be noted a PR was submitted that seems to be a result of this issue #251 but was not linked. It was also named Tightened exposition of Issuer-signed JWT Verification Key Validation section #251 which seems to provide a perception of distance to this issue, when clearly they are related. This harms the visibility of discussion and context for the PR, which from my understanding, is not aligned with IETF Mission Statement around an open/transparent process for discourse.

I understand there are two camps of thought here, but there are solid reasons (technically and practically) provided by pro-DID side, and there is consensus procedure to deal with the objections raised here which need to be addressed and do not seem like they have been.

According to Section 3 of RFC7282, rough consensus can be achieved when all issues are addressed, but not necessarily accommodated:

What can't happen is that the chair bases their decision solely on hearing a large number of voices simply saying, "The objection isn't valid." That would simply be to take a vote. A valid justification needs to me made.

That seems to contradict the actions here: https://github.com/oauth-wg/oauth-sd-jwt-vc/issues/250#issuecomment-2473526620

It seems to me this issue has not been appropriately addressed given the concerns raised. Stating one is "tired" of discussing the issue is not a valid argument, and I for one would like to see the concerns addressed by the previous commenters addressed.