Re: did:webs vs did:tdw

So … a “battle of the bands” … crypto style?  ;-)

One of the observations about KERI is its complexity (see KERI paper https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/KERI_WP_2.x.web.pdf).  That said, to more easily understand what KERI is & does, here’s Part 2 of The Hitchhiker's Guide to KERI (https://medium.com/finema/the-hitchhikers-guide-to-keri-part-2-what-exactly-is-keri-e46a649ac54c).  While the paper is the definitive source, the latter gives the general idea more quickly.  Both describe how participants (Holders, Controllers) create / employ their respective “Autonomic Identifiers” (KERI’s self-certifying identifier), Key Event Receipts, Key Event Logs, interaction protocols, etc.

From what they’ve said, the BC Gov team was looking at ways to achieve KERI’s goals while eliminating much of the complexity.  Here’s a draft of a spec that describes what they are proposing with Trust DID Web “did:tdw” (https://bcgov.github.io/trustdidweb/).  Sorry, no “hitchhikers guide” for did:tdw, but it is a shorter read.

Anyway, I hope that makes it easier to compare the 2 methods.

Regards,

Steve


On Jun 25, 2024, at 09:51, Daniel Hardman <daniel.hardman@gmail.com> wrote:

My suggestion on this is that you invite Stephen to present (or record, or write) some kind of summary of how his solution addresses certain security goals, and then invite Sam to compare and contrast.

On Tue, Jun 25, 2024 at 1:17 PM Julien Fraichot <Julien.Fraichot@hyland.com<mailto:Julien.Fraichot@hyland.com>> wrote:
Thanks all for your contributions, but I feel I’m still puzzled by the justification for did:tdw vs did:webs.

So did:tdw is a “lighter”weight version of did:webs? What philosophically speaking drove the need for the did:tdw creation? And I apologize if it’s obvious, but I wanted to ask this question at DICE but time ran out (and I had (still have but a bit less) a limited grasp of did:webs then.


  *   does not have a dependency on KERI is because it avoids the witness and watcher features that a full KERI implementation would need

About this, I understand that this eventually should become a network, or 2, or witnesses and watchers. How are we today in terms of adoption/implementations of such entities?


  *   as a choice to forego certain redundancy, duplicity detection, and error recovery options in order to avoid some complexity and ease adoption

Sam Smith at DICE was quite adamant that implementing half of KERI was forfeiting all and any benefits from using KERI;  the analogy going to battle in full armor but without an helmet because it’s impractical. I am not a security expert nor a KERI one for that matter, so I tend to lean towards the opinion of the experts, let alone the creator, of a security solution. On paper I find did:tdw more accessible from an implementation perspective, but if in the end it turns to be insecure, again, back to my initial question, why philosophically speaking choose did:tdw over did:webs?

Again sorry to be pushy on the subject, but I would like to understand the pros and cons as I have to make some business recommendations.

Thanks

From: Stephen Curran <swcurran@cloudcompass.ca<mailto:swcurran@cloudcompass.ca>>
Date: Tuesday, 25 June 2024 at 00:56
To: Daniel Hardman <daniel.hardman@gmail.com<mailto:daniel.hardman@gmail.com>>
Cc: Julien Fraichot <Julien.Fraichot@hyland.com<mailto:Julien.Fraichot@hyland.com>>, W3C DID Working Group <public-did-wg@w3.org<mailto:public-did-wg@w3.org>>
Subject: [EXTERNAL] Re: did:webs vs did:tdw
CAUTION: This email originated from outside of Hyland. Do not click links or open attachments unless you recognize the sender and know the content is safe.

Daniel, as one of the drivers behind did:tdw, I'd like to clarify a misconception about did:tdw.

We have come up with an approach for the inclusion of witnesses in did:tdw. We've not implemented it yet, but it is a relatively small addition to the spec, with a correspondingly lightweight implementation. Watchers (and KERI's "judges" and "juries" components) are external parties to the management of the DID/Identifier, so while they might be part of an "implementer's guide", we don't think they need be part of the did:tdw spec. That could change, but that's the plan for now.

Hope that helps.

On Mon, Jun 24, 2024 at 12:23 PM Daniel Hardman <daniel.hardman@gmail.com<mailto:daniel.hardman@gmail.com>> wrote:
From what I’ve gathered so far, the main difference is that did:webs relies on KERI while did:tdw does not. Is that the only notable difference?

The reason that did:tdw does not have a dependency on KERI is because it avoids the witness and watcher features that a full KERI implementation would need. This is best understood as a choice to forego certain redundancy, duplicity detection, and error recovery options in order to avoid some complexity and ease adoption. I don't want to argue the merits here, but I do want to make sure that the choice is not framed as the choice between two identical approaches that differ only in that one has a dependency and the other doesn't. I think evaluators would be well served to understand the theory of witnesses and watchers as they evaluate.

This is coming from someone who worked on did:webs, but who also admires all of Stephen's amazing contributions to the community, so take that with whatever political baggage seems appropriate. :-)


--

Stephen Curran
Principal, Cloud Compass Computing, Inc. (C3I)
Chair - Sovrin Foundation (sovrin.org<http://sovrin.org/>)

Schedule a Meeting: https://calendly.com/swcurran [calendly.com]<https://urldefense.com/v3/__https:/calendly.com/swcurran__;!!C8mu0vCj!YjSa_a26VC15x1iIAd8n1sU8w81V48JEwgFRxbVKCDjaBQEbM2JMsOr2Mvp9PHqIpsZbQVuZHKJAQmaAeSEo4eCItILI$>

----------------------------------------- Please consider the environment before printing this e-mail -----------------------------------------

CONFIDENTIALITY NOTICE: This message and any attached documents may contain confidential information from Hyland Software, Inc. The information is intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, or an employee or agent responsible for the delivery of this message to the intended recipient, the reader is hereby notified that any dissemination, distribution or copying of this message or of any attached documents, or the taking of any action or omission to take any action in reliance on the contents of this message or of any attached documents, is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail or telephone, at +1 (440) 788-5000, and delete the original message immediately. Thank you.