did:tdw!

[snarfed]

Has anyone read the did:tdw spec yet? I read the first half of it just now. It's interesting! I hear it's maybe somewhat inspired by did:plc? Certainly looks like it! Based on did:web, adds a cryptographically verifiable immutable log, rotation keys, portability across DID domains, and iiuc account recoverability via the DID Controller? I guess for did:tdw specifically, DID Controller is their version of a PLC directory? That part I'm a bit fuzzy on, along with when and how keys are custodial. Seems like they have to be, since the DID Controller generates the SCIDs?

Regardless, interesting!

(Also, "trust DID Web" => "trusted web," lol, lmao)

[bnewbold]

I've skimmed it, I think it is definitely one of the more legit and interesting DID methods in the ecosystem, and it has some degree of institutional adoption/inertia which is critical!

My vague memory (only skimmed a couple months ago) is that there is a mechanism for the DID to change, with a way to securely prove that the new/updated DID is the same (or controlled by by the same entity) as the previous. AKA, "part" of the DID changes, another "part" doesn't. That doesn't fit or work with atproto in it's current form: the DID must stay the exact same over time, there is no concept of DID migration or mutation. So I don't think it is a path as an alternative to did:plc in terms of removing DNS and domain ownership/control from the equation.

It does seem to be an improvement over did:web though! Depending on how complex the validation logic is, and what ecosystem/library support ends up looking like, we would consider adding it as a DID method in atproto from that angle.

[snarfed]

Yes! Good point, you're right, the actual DID itself contains both a cryptographic hash (the SCID) and the did:web domain/path, which changes if you move domains. That does make it meaningfully less portable, at least for ATProto.

I wasn't directly advocating for you all adopting it, just curious about the connection with did:plc, if any.

[erlend-sh]

Very interesting!

Would this allow for an institutional topology similar to the world of SSL certificates? I.e. it’s not widely decentralized, but there’s at least a handful different institutions of very high trustworthiness to choose between for a free SSL certificate, and many more for an affordable paid service, kept competitive by the high quality of the free options.

That to me is a sufficiently decentralized DID strategy. did:plc has paved the way in terms of usability and real world use, and I’d consider its governance structure Good Enough if it managed to establish an ICANN-like custodian of its centralized key storage

However, 3-5 cooperating institutions is radically more robust than one. I hope that minimal degree of decentralization isn’t completely out of the picture for the future of did:plc.

@dmitrizagidulin is support for the likes of atproto within scope for did:tdw?

[dmitrizagidulin]

@dmitrizagidulin is support for the likes of atproto within scope for did:tdw?

Say more -- what would it mean for a DID method to support ATProto?

One easy way I could see the two methods interoperating (did:tdw and did:plc) is in the alias sense. Meaning, the user might have 2 DIDs, a TDW and a PLC one, and each would have an alsoKnownAs property pointing to the other.

Is that the kind of thing you meant?

[erlend-sh]

That sort of thing, yeah!

The other, more nebulous question is whether the did:tdw group has any interest in making a completely AT-compatible did-method, I.e. a potential/theoretical replacement for did:plc that’s not as centralized.

Bluesky is surely one of the biggest real world deployments of DIDs on the web right now, so it’s a fitting use case for DID researchers to target novel DID-methods at. And Bluesky itself is unlikely to innovate further on the status quo in the short term since they’ve already arrived at a Good Enough state that works for them as an org & product.

Maybe did:tdw has its distinct use case clearly chartered ahead of it already, but there’s always the possibility of a forked did:tdwat (heh) reshaped specifically to resolve this incompatibility:

“part" of the DID changes, another "part" doesn't. That doesn't fit or work with atproto in it's current form

[erlend-sh]

Worth noting that did:tdw is compatible with the draft-stage OpenID proposal “Self-Issued OpenID Provider”

• https://openid.net/specs/openid-connect-self-issued-v2-1_0.html
• https://github.com/decentralized-identity/trustdidweb/issues/128

..which I don’t have the technical knowhow to parse, but at a surface level it rhymes with atproto’s ’self-authenticating’ nature.

[erlend-sh]

Transitioning from web to tdw

In the linked OIDC/SOIP issue above, @swcurran told me:

any use of did:web can be improved by transitioning to did:tdw.

which is also the first line item in the spec:

Ongoing publishing of all DID Document DIDDoc versions for a DID instead of, or alongside a current did:web DID/DIDDoc.

So on that note I wonder if there’s anything else you’d like to see in tdw @bnewbold that would move this prospect along:

It does seem to be an improvement over did:web though! Depending on how complex the validation logic is, and what ecosystem/library support ends up looking like, we would consider adding it as a DID method in atproto from that angle.

[apatrida]

This is now did:webvh (renamed) and talks about SCID as a stable ID generated from the first DID document. Also witness servers and ways to have no single point of policy control as PLC can turn out to be in the wrong hands.

https://identity.foundation/didwebvh/next/

In generating the first version of the DIDDoc, the DID calculates the SCID for the DID from the first log entry (which includes the DIDDoc). This is done by using the string "{SCID}" everywhere the actual SCID is to be placed in order to generate the hash. The DID Controller then replaces the placeholders with the calculated SCID, including it as a parameter in the first log entry, and inserting it where needed in the initial (and all subsequent) DIDDocs. The SCID must be verified by the resolvers, to verify that the inception event has not been tampered with. The SCID also enables an optional portability capability, allowing a DID’s web location to be moved, while retaining the SCID and verifiable history of the identifier.

and

The witness process for a DID provides a way for collaborators to work with the DID Controller to “witness” the publication of new versions of the DID. This specification defines the technical mechanism for using witnesses. Governance and policy questions about when and how to use the technical mechanism are outside the scope of this specification.

Witnesses can prevent a DID Controller from updating/removing versions of a DID without detection by the witnesses. Witnesses are also a further mitigation against malicious actors compromising both a DID Controller's authorization key(s) to update the DID, and the DID's web site where the DID log is published. With both compromises, a malicious actor could take control over the DID by rewriting the DID Log using the keys they have compromised. By adding witnesses to monitor and approve each version update, a malicious actor cannot rewrite the previous history without having compromised a sufficient number of witnesses, the DID Controller's key(s), and the Web Server on which the DID Log is published.

[bnewbold]

Cross-referencing to a comment thread over here: #2705 (reply in thread)