search

eu-digital-identity-wallet / eudi-doc-architecture-and-reference-framework

The European Digital Identity Wallet
https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/
Other
369 stars 55 forks source link

Careful Evaluation of DID Feasibility is Required #205

Open henkbirkholz opened 4 days ago

henkbirkholz commented 4 days ago

All major browser vendors ultimately blocked further DID specification in 2022 and there is no reason to assume that there will be any support from them in the future: https://www.w3.org/2022/03/did-fo-report.html https://www.w3.org/2022/06/DIDRecommendationDecision.html

The scope of the new DID WG charter is extended to work on a CBOR representation. DID Resolution is listed in the background, but it is not a goal of the WG. Working group proceedings have been contentious for years so the following was added to the new charter: "The Working Group must pursue [absolute! -Henk] consensus in any task pursued under the name of the working group--whether by Chairs, Editors, or other contributors--including any Notes for publication by the WG and any Charters for a future DID WG." https://www.w3.org/2024/04/did-wg-charter.html

The primary objection to v1.0 where:

  1. There is no mandatory to implement DID Method.
  2. There is no normative process defined for resolution, so there is no interoperability across DID Method.

The working group will attempt to solve interoperability by specifying resolver behavior, the input document is: https://w3c-ccg.github.io/did-resolution/

DID Resolution is a mostly not needed step, given that it is a fancy and complicated replacement for a JSON-LD document loader: https://www.w3.org/TR/json-ld11/#loading-documents

The DID ecosystem is built on JSON-LD, despite the fragmented and contentious working group process alll terms are defined in the context of JSON-LD design: https://github.com/w3c/did-spec-registries/blob/main/vocabs/v1/context.jsonld#L12

All of the "new security terminology" is build on a redirection service which is hosted by a few W3C members: https://w3id.org/

w3id is not the W3C, although it has become a de-facto standard in the linked data space, because it enables linked data URLs to be permanent, but to redirect to newer resources. If a redirect changes a JSON-LD context, the associated RDF graph is changed. There is no difference between w3id.org and c2pa or ccc or any other consortium, which is funded by private companies. The network logs on w3id.org observe any miss-configured applications that resolve contexts over the network, which despite not being recommended remains an observed reality. In the IETF, for example, this problem is addressed via URLs, established protocols and standard key formats.

Henk Birkholz (Fraunhofer SIT) Orie Steele (Transmute)

csuwildcat commented 4 days ago

@henkbirkholz mind telling me how one would both allow for multiple types of decentralized systems to underpin DID Methods, while also normative defining a singular resolution process that operates exactly the same across DID Methods, despite inherent differences in the underlying substrates they utilize?

OR13 commented 3 days ago

I'd like to clarify that the objections to DID Core were that DIDs were not ready to standardize without a few concrete DID Methods.

The objections were ultimately overruled, and so far there are still no DID Methods standardized.

The closest candidate methods are DID Web, which is a URN for what could have been a well known URI for JWK or COSE Key Set, and DID Key, which is basically a URN for a JWK or COSE at best, and at worst a new non interoperable key format, that implementations need to translate to and from, in order to us.

henkbirkholz commented 3 days ago

@csuwildcat, I really do not know. The following section was just intended to summarize the first link in the issue (in the context of 2nd & 3rd link):

The primary objection to v1.0 where:

  1. There is no mandatory to implement DID Method.
  2. There is no normative process defined for resolution, so there is no interoperability across DID Method.

Is that summary incorrect?

csuwildcat commented 2 days ago

Two points:

  1. Any standard for truly decentralized identifier methods should allow for different types of implementations based on different substrates, which necessitates differences in resolution steps. This is not a bad thing, and if a spec did not allow for that, it would make it far too inflexible.
  2. Everyone I talk to is bullish about standardizing a few 'must implement' methods (I would argue did:jwk, did:web, did:dht), and we have a clear path to doing so in a W3C WG, if we choose.

All in all, DIDs are certainly a key part of creating a real decentralized Web where user data and communications is unbound from providers, and I think trying to completely redo or throw out DIDs is a very bad idea.

henkbirkholz commented 2 days ago

I am aware that multiple types of resolution methods were intended to be a feature and not a bug. We highlighted that this feature of freedom of choice in contrast to at least one fully interoperable DID method that is MTI became a reason for a formal objection from major browser vendors. With that I am not trying to argue my personal opinion about the feasibility DIDs. We were simply trying to focus attention on the fact that it is openly documented that there is no browser vendor support for DIDs anymore and that it is unlikely to return.

We also highlight that this objection was overruled despite the lack of consensus, that there is not one standardized resolution method up to this day, that DID resolution methods are not in scope of the current DID WG charter, and that one veto in the consensus procedure in the DID WG today can block any work item.

I apologize, if the items I just restated have read like a personal opinion in the initial issue text. That was not the intent. These items are just a collection of facts.

My personal opinion is that decentralized identifiers can be a significant improvement to the WWW, the Internet, and civil society in general. There are obviously also benefits to multiple available types of standardized decentralized systems. Based on the highlighted facts, I simply fear that the time where DIDs can still become an accepted and standardized building block for decentralized identifiers might have already passed. But my crystal ball is pretty cloudy, so I am rather bad at predicting the future, tbh. Still, basing any solution for hundreds of millions of people on an assumed availability of at least one well-reviewed, consensus-driven DID resolution standard that is widely accepted seems like a risky bet to me. That is why Orie and I agree that it is valuable use of our time to make this issue more visible via this consultation process.

kimdhamilton commented 2 days ago

Hi Henk, your personal opinion about DIDs is indeed valuable and welcome. This may not be the best repo to discuss, but I think we can help clear up some questions. Before jumping in, let me ask some clarifying questions.

Many statements appear to reflect a misunderstanding, but we can start with the following 2; can you provide more details and context so we can understand your point?

DID Resolution is a mostly not needed step, given that it is a fancy and complicated replacement for a JSON-LD document loader

The DID ecosystem is built on JSON-LD, despite the fragmented and contentious working group process alll terms are defined in the context of JSON-LD design: https://github.com/w3c/did-spec-registries/blob/main/vocabs/v1/context.jsonld#L12

OR13 commented 1 day ago

I wrote many of those statements, as an author of the DID Spec and a maintainer of the DID Spec registries:

For example, see: https://www.w3.org/TR/did-core/#extensibility

We may not agree on where the DID Core data model comes from, or how the JSON media types are related to the DID vocabulary, and you may note that the vocabulary for DIDs is defined here: https://www.w3.org/ns/did

I'm not sure this issue is great place to get into the details of how the specification works, the primary point of this issue is to highlight that people don't agree on exactly how it works, and that impacts the political and technical support for any recommendation to use DIDs, DID Resolvers, and DID related verification methods as they relate to verifiable credentials... for example: https://github.com/w3c/controller-document/pull/28/files

The VCWG uses the term "controller document" to reflect the DID Core data model, but with the requirement to use DID URLs.

When considering the difference between an HTTPS URL and a DID URL, I believe that an HTTPS URL for a controller document is a better solution than a DID URL which requires a resolver, which is not yet standardized, but I also note that both of them are less useful than a JWKS or other existing media type for expressing collections of verification material, for example JKU, etc... https://www.rfc-editor.org/rfc/rfc7516.html#section-4.1.4

jandrieu commented 1 day ago

Unfortunately, the argument favoring non-DID identifiers has a number of misstatements. I want to clarify one in particular.

All major browser vendors ultimately blocked further DID specification in 2022 and there is no reason to assume that there will be any support from them in the future

In fact, this is not true.

First, "All major browser vendors" did not "ultimately block" anything. Rather, three browser vendors objected to accepting the initial DID Core specification. The total number of formal objections, including those vendors, represented less than 1% of the W3C membership. After the W3C's internal processes worked through those objections, the organization eventually accepted the specification as a formal Recommendation. Ultimately, the DID specification was adopted, not blocked.

Second, the current DID WG's charter was unopposed by browser vendors. No formal objections were raised by browser vendors during the chartering process. None. Those vendors have, in fact, shifted in their initial opposition and their concerns are actively reflected in a manner that offers a route for any updates to the DID spec to address those concerns. This is a shift in support for the work.

The real error in this argument however, is to misunderstand how DIDs work.

Adopting "DIDs" isn't just adopting the DID Core specification, it also means selecting at least one DID method. Debates about features of DID Methods should be focused on the communities developing those methods. Some are better than others. Choose wisely.

In particular, the approach of DID methods makes it possible for any community to define its own DID Method that meets that community's requirements. This is why efforts like did:ebsi https://gataca.io/blog/ebsi-did-v2-a-test-to-ssi-usability-and-its-use-of-blockchain-technology/ are able to explore a uniquely European take on how a DID method could operate, leveraging the W3C specification without being unnecessarily restricted in how they satisfy its core requirements. In fact, the DID approach was specifically designed to enable communities to use any standards process or institution for standardizing DID methods. It was never intended that the W3C be the place where DID methods must be standardized.

So, yes to the stated intent of this issue: careful evaluation of DIDs and DID Methods is required. However, the base arguments against DIDs misstates and misunderstands how DIDs actually enable the EU greater flexibility and autonomy.

henkbirkholz commented 23 hours ago

Effectively, four browser vendors pulled out (one vendor is quoted and one vendor is anonymous, but maybe k-anonymity is broken here...). That is all we are restating. There was a blocking action that was resolved by being overruled. Okay. But I assume that everybody sees the actual gravity of what has happened there, yes?

Life experience shows, that individuals/entities who pulled out of a standardization effort tend to not engage in that effort as strongly as before. Hence, "no opposition" does not indicate "support", in literally every case. I think that is clear to anyone who has participated in a WG/RG/SIG/etc. in an SDO.

Adopting "DIDs" isn't just adopting the DID Core specification, it also means selecting at least one DID method.

Yes, but since 2022 (and later the rechartering) there is no place to standardize DID methods in the W3C for that (I understand that it does not have to happen in the W3C, actually). Again, there is no DID method being close to being standardized in any SDO today. I am aware that I start to focus on the "con"s here (which is not actually good code of conduct, sorry), but insisting on some not-realized "pro"s also does not help.

@csuwildcat stated:

we have a clear path to doing so in a W3C WG, if we choose

There was no such decision though (no place to create such path was realized via chartering in a viable SDO, no "we chose" happened), which again is simply a fact.

You stated:

The real error in this argument however, is to misunderstand how DIDs work.

I assume what you mean here is "how DID standardization works" (as the paragraph following is about DID method standardization)? Please correct me, if I am wrong. I am well aware how the majority of proposed DID methods work. I am indeed surprised by the perception that the DID standardization is going to work out though, tbh... looking back at the events of the past five years. The statements in this paragraph are personal opinions!

While I personally really like the GATACA pun, what information relevant to standard does your did:ebsi reference state:

All other links are pointers to blog posts from gataca.io itself again. As an exercise, I delved into the first self-referenced blog post. The only standards-relevant link in there points to https://www.w3.org/TR/did-core/. The rest was again self-referenced blog posts. I did not dig deeper. I am not saying that anything stated there is wrong or misleading. I really do not know. I am saying that I am failing to grasp the relevance of the did:ebsi reference you provided to any standardization related activity. Maybe you can help me out here.

In fact, the DID approach was specifically designed to enable communities to use any standards process or institution for standardizing DID methods. It was never intended that the W3C be the place where DID methods must be standardized.

But if a DID resolution is not standardized in an open-ended and unbiased SDO, I would repeat my feeling of apprehension that this is a pretty risky bet to made for hundreds of millions of people. I still fail to see a solid basis here. Maybe you can help me out here, too.

My personal bias might be that I assume that "any community to define its own DID Method that meets that community's requirements" that intends to do feasible and "careful evaluation of DIDs and DID Methods" must enable and enact:

My sincere hope is that this open consulting process comes at least to a similar conclusion. If such a DID method defining community would be yet an"other consortium, which is funded by private companies" only as Orie says, I'd also start to feel a bit uncomfortable considering the scope of the planned action.

csuwildcat commented 21 hours ago

The reason the browser vendors brushed off the spec during and after has nothing to do with the various Game of Nerds episodic plots highlighted above, it's simply because the whole class of tech was something, at least at the time (I've heard minds are changing), they:

  1. Didn't think was necessary, because they love the centralized systems they control and think the Web is fine as-is.
  2. Didn't have any immediate business need for them or direct path to revenue.
  3. Didn't like one particular formulation of them that caused their tender, misguided, ideological sensibilities to flare up.

If anyone here thinks more than 5% of the reason they declined to jump in, help develop, and adopt is because they don't like the curly brace formatting, have a few nits to pick with the spec, or really wanted a DID Method but couldn't find one, I have a few bridges I can sell you on heavy discount due to a lack of buyers in this high interest rate environment.

TallTed commented 19 hours ago

@henkbirkholz —

You might benefit by exploring the DID Method Rubric, which we developed explicitly because different communities with different use cases might find different attributes of DID Methods to be more and less important, and so choose different DID Methods for their deployment.

SDO is not currently a criterion registered in the DID Method Rubric Registry, though characteristics of SDOs might be considered to be part of several other criteria, starting with Rulemaking.

Thinking about it a bit, the DID Method Rubric might be treated as a more generalized ID Method Rubric, where DIDs are a subset of IDs. Using the DID Method Rubric to evaluate other candidate ID methods, as well as any DID Methods (including the general class of DIDs), being considered by/for EU Digital Identity use would provide some useful information for all.

henkbirkholz commented 4 hours ago

@csuwildcat

various Game of Nerds episodic plots

I understand that there are highly invested stakeholders participating here, but in order to appropriately trying to understand your point, could you please be a little bit more specific here? I'd really like to understand.

Additionally, as another personal point of view in contrast to "I've heard minds are changing", I've seen open push-back on DID inclusion in global standards due to the lack of consensus and maturity live on stage. I personally defended the "identifier agility" DIDs can provide for about two years until I had to decide not to die on that hill and fold to unblock work. I really understand why the core concept of decentralized identifiers include really useful ideas in support of civil society. I really do (personal opinion again).

But you have to face the facts that not a single DID method is even close to be a reliable building block. I feel the frustration on this topic and I feel the invested emotions. And I am actually quite sympathetic with that, but speaking from an SDO's point of view, there is nothing to reliably build on. The feedback (we sometimes call that bashing) was brutally honest on that.

If anyone can reference a "change of mind" (that is not, for example, in a magazine or a blog post), a convincing consensus building activity that is transparent and observable, or anything that can really boost confidence in DID, I am happy to float that, too. Orie and I are reflecting a harsh reality out there into the consultation process here. That are no scripted episodic plots... you [quote] literally "cannot make that up".