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

I think this is a great explanation!

I just want to comment on one item here that suggests a common 
misconception about DIDs:

/> A key design intent of did:tdw is full compliance with the DID Core 
specification, allowing a DID Controller to include any desired 
information directly into their DIDDoc, treating the DIDDoc as the 
primary data model for the DID Method.
/

While I agree that having an actual DID document "file" on a web server 
that can simply be uploaded/edited/downloaded is something that makes 
did:web and did:tdw easier to understand and use than did:webs, there is 
nothing in the design of did:webs or even did:keri that is not DID Core 
compliant.

The fact that in did:webs the DID document is constructed from a KERI 
event stream (rather than using an arbitrary file) does NOT make 
did:webs non-compliant.

The fact that in did:keri the DID by itself may be insufficient for 
being able to resolve it (you need additional information such as an 
OOBI or addresses of watchers) does NOT make did:keri non-compliant.

The fact that in some DID methods you don't have full control over what 
to put into a DID document does NOT make such DID methods non-compliant.

Markus

On 6/25/24 9:44 PM, Jordan, John CITZ:EX wrote:
>
> Hi Julian,
>
> Thanks for the questions.  I thought I would offer thoughts from our 
> team as the business sponsor for this proposed did method.
>
> did:webs and did:tdw have different design intents. While they both 
> aim to be “a better web-based DID method than did:web” they have 
> independent implementations. What we can offer, to the best of our 
> abilities,  is a description of the design intent and key features of 
> did:tdw. It will be up to individual adopters to make their own 
> determination as to the appropriateness of the did method they choose 
> for their services.
>
> A key design intent of did:tdw is full compliance with the DID Core 
> specification, allowing a DID Controller to include any desired 
> information directly into their DIDDoc, treating the DIDDoc as the 
> primary data model for the DID Method.
>
> Additionally, we aimed for the DID method to be significantly more 
> useful and secure than did:web, without increasing the complexity of 
> deployment. The following list, largely sourced from the spec 
> introduction, provides more details (currently available here – 
> https://bcgov.github.io/trustdidweb/):
>
>   * Ongoing publishing of all DID Document (DIDDoc) versions for a DID
>     instead of, or alongside a current did:web DID/DIDDoc.
>   * The same DID-to-HTTPS transformation as did:web.
>   * Capable of using the same High Assurance DID-to-DNS mechanism
>     (https://datatracker.ietf.org/doc/draft-carter-high-assurance-dids-with-dns/).
>   * The ability to resolve the full history of the DID using a
>     verifiable chain of updates to the DIDDoc from genesis to
>     deactivation.
>   * A self-certifying identifier (SCID) for the DID that is globally
>     unique, embedded in the DID, and derived from the initial DIDDoc.
>     The SCID enables DID portability, such as moving the DID’s web
>     location (and so changing the DID string itself) while retaining a
>     connection to the predecessor DID(s) and the DID’s verifiable history.
>   * DIDDoc updates contain a proof signed by the controller(s)
>     authorized to update the DID.
>   * An optional mechanism for publishing “pre-rotation” keys to
>     prevent the loss of control of a DID in cases where an active
>     private key is compromised.
>   * DID URL path handling that defaults (but can be overridden) to
>     automatically resolving <did>/path/to/file by using a comparable
>     DID-to-HTTPS translation as for the DIDDoc.
>   * A DID URL path <did>/whois that defaults to automatically
>     returning (if published by the DID controller) a Verifiable
>     Presentation containing Verifiable Credentials with the DID as the
>     credentialSubject, signed by the DID.
>   * A mechanism for supporting the concept of witnesses --
>     collaborating parties that approve DIDDoc versions before
>     publication (planned, but not yet in the spec or implementations).
>
> Combined, the additional features enable greater trust and security 
> without (we think) compromising the simplicity of did:web.
>
> In parallel with developing the spec, we created two implementations, 
> one in TypeScript, one in Python, and the implementation learnings 
> contributed substantially to the specification. Both implementations 
> have most of the features listed above and are less than 1500 lines of 
> code each. After our presenting the DID Method at IIW in April, we 
> understand a Rust implementation has been developed that will be open 
> sourced Real Soon Now.  An implementer's guide (currently in the spec, 
> but to be separated) provides guidance on deploying did:tdw.
>
> The spec and implementations were created in the Government of British 
> Columbia GitHub repos, and there is an approved Trust Over IP task 
> force that has been formed, with meetings to begin shortly. To be 
> determined is where to take the spec. further, and what, if any 
> relationship it has with the did:web specification.
>
> Thanks again for your question, and we hope this offers some 
> information for your contemplation.
>
> Links:
>
>   * Presentation at DICE 2024: Trust DID Web - A New Web-Based DID Method
>       o https://docs.google.com/presentation/d/1WvE3w_7C_umR_aDX87Mje-qcRU8o2PNMs4eRAOssHR0/edit?usp=sharing
>   * Specification: https://bcgov.github.io/trustdidweb
>   * Trust over IP Task Force Page:
>     https://wiki.trustoverip.org/display/HOME/Trust+DID+Web+%28did%3Atdw%29+DID+Method+Task+Force
>   * Typescript Implementation: https://github.com/bcgov/trustdidweb-ts/
>   * Python Implementation: https://github.com/bcgov/trustdidweb-py
>
> John Jordan
>
> Executive Director, Digital Trust
>
> Cybersecurity and Digital Trust
>
> Government of British Columbia
>