ToIP work on DID methods and VID types

[talltree]

This discussion is to prepare for a special ToIP meeting on Friday May 24 (10:30-noon PT / 17:30-19:00 UTC). See the ToIP Calendar for details.

The topic, broadly speaking, is: “What work on DID methods and VID types should be pursued within the ToIP Technology Stack Working Group?”

Background

The TSWG did:webs Task Force was formed in July 2023 to define a new DID method that would combine the power of self-certifying identifiers (SCIDs) with the simplicity and ease of the did:web method. For the full story, see the ToIP blog post announcing the public review of the did:webs specification.

@swcurran of BC Gov agreed to co-chair of this Task Force because he and BC Gov were excited about this new DID method. However, as Stephen can further explain in this thread, as the spec matured, he had concerns about complexity, and in December he decided to step down as a co-chair to explore if there was a less complex solution.

This spring, he and Andrew Whitehead and @brianorwhatever developed an alternative did:web + SCID approach called did:tdw. They presented it at IIW # 38 in April 2024. Here is the draft did:tdw spec.

Stephen then proposed a new TSWG Task Force based on this charter. This proposal was discussed at the May 14 TSWG Plenary meeting. The discussion raised questions about what DID methods and VID types ToIP should be pursued at ToIP. The action item was to arrange a special meeting on the topic and start this thread for asynchronous discussion.

Key Questions

In addition to addressing the specific question above, in this thread feel free to add your views on any of the following questions:

1. Is it okay for the TSWG to have multiple Task Forces working on different DID methods or VID types?
2. What should this mean for our overall stance on interoperability?
3. What should this mean for our overall stance on security?

[swcurran]

While this is not directly relevant to the questions raised, I understand there was considerable frustration at a recent TSWG meeting about BC walking away from the did:webs work, seemingly abruptly, and for some, without reason. We feel we were open in the calls and discussions about our disillusionment with the effort (and some heard that), and in leaving we tried not to cast aspersions on the hard work of others.

For those that didn't understand our motivations here were the reasons:

From the outset, we were not involved in did:webs for the KERI aspect of the work, but rather with the primary goal of having an easily used web-based DID method that was a significant improvement over did:web. We see did:web fast becoming the dominant discoverable DID method, and want to have a DID that can replace did:web, but that is more secure and capable. We want everyone that is using did:web to want to switch to the new DID method. As well, for those that started on blockchain based DIDs, we wanted a DID Method that had some of the characteristics of a ledger-based DID but without requiring a ledger. Thus, our goal was not to use the KERI ecosystem, but rather to enable easier collaboration with other communities using DIDs (or wanting to use DIDs).

In our first look at that, KERI features seemed to be a shortcut to that goal. We liked the KERI features (SCID, history, signed versions, chained history, key prerotation, multi-sig, etc.), but we didn't know what it took to get them. We thought that getting those features (for "free"), the convenience of did:web style publishing and discovery, and the extra services like signed files and /whois would be a winner.

The did:webs working group efforts showed the challenges. Instead of getting a DID Method as the first order object, we got a KERI identifier that could (sort of) be published as a DIDDoc. Instead of saying "I want my DIDDoc to look like ", the user would execute some KERI events that sort of resulted in a DIDDoc like we wanted — an indirect and rather convoluted approach. KERI events had to be defined and added that (sort of) allowed us to build the DIDDoc we wanted. The KERI folks didn't really see a need for such events -- they weren't needed for KERI (which makes sense from that perspective). The result was something that a developer experienced in using DIDs would not recognize, and there was no obvious path to how to "fix" that. Basic features of a DIDDoc (e.g., adding arbitrary services) had to have special KERI events added to accommodate the feature. And the overhead of creating and managing a did:webs DID required a full embrace of KERI (which again, was not our goal). did:webs is a DID as a bi-product of using the full KERI ecosystem. And that was not our goal.

We stopped our efforts with did:webs and started on what became did:tdw because we thought we could get a DID-first DID method that had the important features of KERI, implemented differently, that a developer familiar with DIDs would understand. By completing several requirements/implementation iterations, we think did:tdw as it stands is a pretty complete, simple, and easy to use DID Method that achieves much of what we want, with a minimum of code and few dependencies. We even think that adding more advanced KERI features (witnesses, watchers, judges, and even anchored signatures) can be done with simple, optional did:tdw features. That's the work of whatever Task Force begins to work on did:tdw.

I hope that helps.

[2byrds]

I hope in the VID space we keep returning to security features and keep acknowledging the work behind us and ahead of us is significant. I hope we can avoid splintering on non-security features that won't help VID appraisal. And can instead acknowledge that VID appraisal is worth investing into together. I would like our combined effort to compel even the largest/legacy/centralized identity and security providers. But even more so, I'd like the earnest BC, EU, and other identity customers to have a clear appraisal of the identifiers they choose to use.

@swcurran I will always be grateful for the Aries community you helped build. And I was very grateful for the did:webs discussions, debates, and feedback you provided. Thank you for summarizing your experience as part of the did:webs specification task force. While you did a lot of work to engage on the specification, I'm not aware of BC doing any significant development on did:webs as an implementation.

I want to add my experience and opinion as a did:webs developers. It is hard for me to imagine how your concerns/decisions would have enough information, to transition from did:webs to the hypothetical did:tdw. I understand the desire to find a shorter/better path to your desired outcomes. But, making that determination before doing any development on did:webs and then spinning up a new did method specification AND development team for did:tdw seems like it is missing significant developer knowledge. I don't understand how that determination can be reached without the hard work of significant development.

The features from KERI that you mentioned; "SCID, history, signed versions, chained history, key pre-rotation, multi-sig, etc." and the advanced features you mentioned (really they are necessary features) "witnesses, watchers, judges, and even anchored signatures" and the features you didn't mention, like delegation that will almost certainly be needed, all require an incredible amount of development work and understanding. They will require an implementation that looks VERY similar to KERI, if they are real and secure. Once that understanding is achieved through significant development work, then I could see how a proper determination could be made about yet another did method and yet another implementation.

I mentioned "real and secure" because VIDs will provide an appraisal of their security capabilities. KERI is leaps and bounds ahead of any other identifier ecosystem in terms of implemented security features that will be part of that assessment. Whois, etc. are nice features that you advocated for in our did:webs meetings. But, they won't improve a VID security appraisal. The only features that will improve the VID appraisal, are all those features listed above that did:tdw (or any other identifier ecosystem) will have to re-implement from KERI.

I want to acknowledge that you and your team have done an INCREDIBLE amount of development on Acapy, etc. And so you have probably experienced MANY parts of that community rolling their own implementations in hopes of finding a shortcut to real/deployed SSI only to see them produce half-baked attempts. Maybe that was their way of doing significant development to determine if their organization would adopt DIDs, etc. But the truth is we see hundreds of DIDs and several are no longer are active. If that collective effort had first taken the time to dive deep into the development and realize how much work it takes to build Acapy, etc before they rolled their own implementation, your velocity would have likely improved. And generally far fewer splinter implementations would exist because they would have known how much work was needed just to implement enough code to then realize how much more work was actually necessary to solve their real world secure identity needs.

I encourage anyone wanting to implement a VID whose appraisal will be favorable for secure organizational identity like what the vLEI, or BC, or EU, etc. will need.... Please join forces. Work hard on development to understand what it takes. KERI provided many of the innovations and is a long way down the path. And there is still a lot of work to do. We should do it together.

[edeykholt]

Although I haven't seen this stated, I wonder if an objective behind did:tdw was/is to help existing users of W3C VCs and did:indy (or its derivatives) create solutions that integrate with websites, while protecting their investments and not disrupt their deployed systems? If so, I respect that, and would be curious what the KERI and ACDC advocates might suggest for how such projects should plan to eventually migrate, assuming they become convinced about the motivations, requirements, and merits that drive the KERI and did:webs. Or, is did:tdw envisioned to be long-lasting and meeting all their communities' requirements for key management, etc., and thus not only a practical tactical step forward?

[swcurran]

Although I haven't seen this stated, I wonder if an objective behind did:tdw was/is to help existing users of W3C VCs and did:indy (or its derivatives) create solutions that integrate with websites, while protecting their investments and not disrupt their deployed systems?

That was not the motivation. The driver was a desire to interact with anything that used DIDs, understanding that “did:web” is becoming the de facto standard in DIDs, that did:web is insufficient, and that adding concepts (vs. Implementations) from KERI in a “did:web” consistent way is helpful.

Or, is did:tdw envisioned to be long-lasting and meeting all their communities' requirements for key management, etc., and thus not only a practical tactical step forward?

That is closer — missing the word “DID” in the description.

[daidoji]

“What work on DID methods and VID types should be pursued within the ToIP Technology Stack Working Group?”
Is it okay for the TSWG to have multiple Task Forces working on different DID methods or VID types?

These two are a bit above my pay grade. I think that the whole crux of TSP, and the overall direction of the various working groups of which I'm less familiar hinge on the question of: "what is a VID?", alternatively and/or "Which did or other digital identification support the minimum security contexts that we can be comfortable publicly supporting for use in any of our published stacks with the stated goal of creating a unified Trust Layer for the Internet ™️ ?".

That is, when I'm reading about the Trust Registry Task Force's API, I'm thinking, this API is fantastically simple, should do what's required to meet the task force's objectives, but really all come down to hinging on:

1. the specific security context of the registry and the ecosystem of identities that it represents IE who really controls the identifiers both actively (and in various shadow methods of control).

When I'm reading about the Governance Architecture Working Group I'm thinking, "This is great stuff. Organizations can use this as a roadmap for developing governance procedures for their ecosystems that hinge on answering a bunch of the questions to help both outside users and inside entities / groups manage ecosystems in the vein of: does my operating environment and security context allow me to manage this in a way that can't be abused (by the large or the small)? . A lot of these questions will boil down to:

1. What is an identifier in this scheme?
2. Who really controls that identifier?

In TSP, with which I'm most familiar) as a user or developer to the protocol I'm asking myself:

1. What ecosystems would I trust my information (even encrypted and confidential and all that) passing over the wire?
2. What type of identifiers do those ecosystems support and who really controls those identifiers? ie) even if I can trust an ecosystem, maybe regular_guy_nsa_dude_VID@super_great_VID_network (or the Chinese MSS, or FAPSI or whatever) isn't always my friend when it comes to creating a "trust layer" for the Internet.

I think there's a tradeoff between embracing systems that are already widely deployed, operational, and battle tested and embracing systems that will be much more secure due to not necessarily having to deal with the baggage and engineering mistakes and choices of the past. There's a tradeoff between anarchic systems (like KERI that have the ability to be completely self organizing in a bunch of super secure, novel, interesting ways) and those that are governed quite rigorously through oligarchies if not necessarily central authorities like the Federated models that dominate the Internet today.

I certainly have my preferences in what I choose to work on (KERI, did:webs), but I understand that a lot of us have opinions and some of us represent entities that have much larger difficulties and don't have the benefit of a professional opinion on the topic. My vote would be to allow the rough consensus of whatever methods seem applicable. I think that things like KERI/did:webs should win in the end because they'll be much more adaptable to the old systems AND the new patterns, but that's just my opinion. Only time will tell.

What should this mean for our overall stance on interoperability?
What should this mean for our overall stance on security?

However, the caveat to all that kumbaya above is that it is increasingly necessary that we be very specific and very clear in communication about what all the work done under our banner is. It should be unified and interoperable and should clearly define what tradeoffs and security/operational/economic/governance implications arise from the choice of what we publish. A Trust Layer for the Internet requires that the layer operate seamlessly via all its parts. The hourglass model doesn't work if identifiers in one ecosystem have no clear bridge to identifiers in another system. The hourglass model doesn't work if one set of security implications in some layer degrades the models of all the other layers it touches. That's kind of the Internet we have today.

Anyways, I won't be able to make it to the meeting on Friday but hope maybe some of these points contribute to the discussion even if in a small way.

[brianorwhatever]

From trustoverip.org

Our mission is to provide a robust, common standard and complete architecture for Internet-scale digital trust.

I interpret that as Trust Over IP would have a single identifier mechanism as a "common standard". If that is the case I believe that it is short sighted. Since I've entered the space I have heard "the market will decide what DID methods are adopted" and I do believe this. It might take a long time to reach that but that is fine. Right now from my perspective the market has adopted the following methods:

• did:key
• did:jwk
• did:peer
• did:web

The first 3 of those are static making them very limited and then of course did:web is dynamic with some major functionality missing. I bring this up to show that a reinterpretation of the mission could be that Trust Over IP could take on the role of helping to show the world what methods are being adopted broadly and the specific tradeoffs being made. This would leave ToIP free to develop a range of different DID methods with different tradeoffs.

So, I am proposing ToIP starts 2 new task forces:

1. DID Adoption Task Force
2. Trust DID Web Task Force

Key questions:

1. Is it okay for the TSWG to have multiple Task Forces working on different DID methods or VID types?
   Yes, as described above.

2. What should this mean for our overall stance on interoperability?
   A DID Adoption task force would greatly improve interoperability broadly as it would enable insight into the methods being used.

3. What should this mean for our overall stance on security?
   DID Method security is one of the most important aspects the DID Adoption task force could help the market decode.

[darrellodonnell]

I really like:

help the market decode.

I initially thought it may have been a spelling (decide) mistake, but then my brain though it through. That is a very well chosen word.

[darrellodonnell]

Our mission is to provide a robust, common standard and complete architecture for Internet-scale digital trust.

I interpret that as Trust Over IP would have a single identifier mechanism as a "common standard".

Interesting. I don't interpret the statement to say "single identifier mechanism," at least not to say "the one DID Method". I do interpret that statement to imply that there may be opinions about which DID Methods (more particularly VIDs) are acceptable. Further, that the architecture would allow decisions that fit in a common way.

[talltree]

I want to thank everyone who has contributed to this discussion today as it really helps us prep for the call tomorrow (Friday May 24, 10:30-noon PT / 17:30-19:00 UTC, see the ToIP Calendar for details).

I myself plan to wave "the SCID flag" (self-certifying identifier) on the call tomorrow because, having invested seven years of my life in seeing the DID spec all the way through to a W3C standard, I now believe that both the most secure AND the most decentralized DIDs are SCIDs.

So more than anything, I'd like to see ToIP promote VID types that are SCID types. To me, it's no coincidence that all three of the VID type efforts we are discussing right now — KERI AIDs, did:webs DIDs, and did:tdw DIDs — are SCIDs.

One way or another, I look forward to us using tomorrow's call to see if we can come to "rough consensus and running infrastructure".

[sumapnair-ibm]

Obvious typo: "The TSWG did:webs Task Force was formed in July 2024 to define a new DID method" please correct it to July 2023. :) We aren't there yet.

[darrellodonnell]

are you implying did:tdw isn't forward-compatible? 🤣 good catch.

[talltree]

Good catch! Typing too fast. Fixed.

[talltree]

Here is a link to the recording of the special ToIP VID Methods Discussion on Friday May 24. My own major takeaways from the call:

1. The Trust Spanning Protocol Task Force (TSPTF) has always been in agreement that the TSP must support different VID types. The question is what the "bar" should be for registering those VID types.
2. @wenjing make the point that security requirements are always relative to a context. Some contexts require high security/high assurance. Some do not. So it is reasonable that different VID types may have different capabilities to support different security/assurance contexts.
3. One conclusion on which there was complete consensus is that ToIP must produce a VID appraisability framework that enables adopters of the ToIP stack to have a full understanding of the security tradeoffs involved with any particular VID type.
4. It was also agreed that, instead of spinning up another task force, the VID appraisability framework should be a deliverable of the TSPTF because VID types (and VID type registration) is such a core component of the TSP specification.
5. Lastly, at the end of the call it was agreed that the proposed did:tdw Task Force should go forward because: a) it will be a place within ToIP that work can be done to determine if another VID type (in this case, a SCID-based DID method) can interoperate with other TSP VID types, and b) this TF will be able to contribute to the VID appraisability framework.

Finally, on the call I shared this diagram to illustrate how dramatic of an improvement it will be to move to any type of SCID vs the status quo security mechanisms for the Web:

[darrellodonnell]

I like the forcing function here that help push to establish an appraisability framework for VIDs. It helps up ensure that we know what the rubrics is for "good".