Re: [EXTERNAL] Re: did:webs vs did:tdw

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>
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>
> *Date: *Tuesday, 25 June 2024 at 00:56
> *To: *Daniel Hardman <daniel.hardman@gmail.com>
> *Cc: *Julien Fraichot <Julien.Fraichot@hyland.com>, W3C DID Working Group
> <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>
> 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)
>
> *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.
>