Re: Goals and Requirements for DID Method Standardization?

Hi folks!

New subscriber and group member here. I work at Bluesky on the AT
Protocol, including the account identity system, which builds on DIDs.

Apologies for taking so long to chime in on this thread. I wanted to
share some of the criteria we used when assessing DID methods in the
past, as well as some constraints on DID methods that make them work
well (or not) for applications like ours.

Our original criteria are described publicly here:
https://atproto.com/guides/identity#did-methods

I would rephrase and re-emphasize them a bit differently today:

* Low and predictable marginal cost at scale (millions of accounts):
as an example, SMS verification of user accounts can be prohibitively
expensive for service providers, even when costing well under a US
dollar per account
* Ability to create and update identifiers rapidly (within seconds,
ideally under a second)
* Key rotation is a must
* Reliable and predictable-latency operation, both for updating
identifiers and resolving them (the "tail latency" of resolution is
important)
* Identifiers are long-lived and continue to function after periods of
inactivity
* Resolution should not require additional state or context, and "new"
resolvers can independently resolve all "old" identifiers
* DIDs are permanent and immutable account identifiers

The last two requirements make most forms of "DID migration" very
difficult to implement with AT Protocol. It is not feasible to
re-write DIDs, because they are included in URIs which get included in
content-addressed data records. Keeping track of aliases or DID
history out of band would mean that a newly-instantiated client or
service would be missing history, and would not be able to
successfully resolve the same DIDs as an established service. We took
it as an invariant that account identity is one-to-one with a
permanent DID string.

--bryan

Received on Thursday, 12 December 2024 06:57:29 UTC