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

Thanks Markus… that is fair and the statement wasn't meant to imply other methods  are not in compliance. It speaks more to how a controller creates and manages the doc.
John

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Markus Sabadello <markus@danubetech.com>
Sent: Wednesday, June 26, 2024 7:12:01 AM
To: public-did-wg@w3.org <public-did-wg@w3.org>
Subject: Re: [EXTERNAL] Re: did:webs vs did:tdw


[EXTERNAL] This email came from an external source. Only open attachments or links that you are expecting from a known sender.


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
     *   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