- did:oyd seems to generate non-permanent identifiers. These identifiers change each time a corresponding DID document is updated. In my opinion that negates the primary reason to use DID in the first place.
- did:keri is quite complicated and I canāt figure out how it works. For some reason, authors chose to skip the most important part of the resolution algo: The method for discovering the Key Event Log is outside the scope of this specification. Possible implementations include the use of a Distributed Hash Table (DHT), anchoring a KEL in a ledger or the use of a gossip protocol involving a witness network.
- did:plc is a joke. Everything is stored on a single server controlled by BS.
Matrix also has a long-standing discussion evaluating different forms of nomadic identity, recently narrowing in on DIDs:
https://github.com/matrix-org/matrix-spec/issues/246#issuecomment-1350064767
While I agree that thereās every reason to be cautious about Blueskyās centralized approach, I think itās worth noting that private-key identities solve two distinct problems:
- Instance-independent identity with credible exit
- Self-sovereign identity with no 3rd party authority
Personally I donāt actually want to be 100% responsible for the safeguarding of my private identity key, for the same reason I use a bank instead of storing my money in a safe at home.
I want to fully own my identity, but I donāt need exclusive custodianship over it. I have a much more urgent need for (1) than (2), so Iām okay with solving the former first as long as thereās a clear path from there to the latter.
Blueskyās approach is in principle fine with me, provided their promise of credible exit can be substantiated. However I might only be willing to trust such a third party if it was Mozilla or some other similarly established open-web institution.
did:web is a good solution for key custody. It is simple, allows multiple providers to exist and allows key rotation. Even Fediverse instances can be did:web identity providers!
For did:plc, thereās a only one provider. They are misleading their users when they refer to it as ādecentralized identifierā .
Two new FEPs related to nomadic identity and data portability:
Iāve been floating an idea for Kitsune that might be applicable to ActivityPub servers in general:
how aboutā¦
Make Kitsune possible to run as just an auth server (identity db). And, conversely, just a send/receive server (pubsub pipe). Or both.
It takes a lot for me to be bothered with the overhead of self-hosting, but if I could take proper ownership of my federated identity and its authorized app personas by self-hosting it, Iād probably start doing that.
I donāt think Iāll ever wanna bother with the pipes on my own; I wanna outsource that to the most fitting host-collective. I wanna self-host something like a
kitsune-authand outsource the rest to akitsune-pipesWhat this would enable is a two-tiered hosting setup. Itās a bit like splitting Kitsune up by the metaphorical duality of body and soul.
Point being that āeveryoneā (at least as far as the early-adopter techie crowd goes) takes care of their own soul (auth), which can be plugged into any larger body-organism (pipes) of oneās choosing.
By separating out the auth-layer of Kitsune to let users self-host that subsection of the app in the most lightweight way possible, you empower users to interface with the rest of Kitsune from a point of self-sovereign digital identity.
I tend to agree with your take of being in control of my own identity. I believe it should be seperated from the webgui and backend of a specific service. They together would perform operations on my data via activitypub operations and display those to me in the relevant user friendly way. Relegated to terminals you can use to access your data in unique ways, Microblogging view, threads view etc.
I imagine my identity server acting as a sort of data store. It has all my comments, followers etc. It would give me control to make pseudonyms and trust levels for interactions on relevant data. It would take over the āroleā of your homeserver url as it were for moderation purposes.
I should also mention FEP-ef61 here, which builds on previous proposals and describes a complete data portability solution. It is an early draft, and have not been implemented anywhere yet, so feedback is welcome: FEP-ef61: Portable Objects.
@arcanicanis published a nice article which explains how all these FEPs fit together: The Path to Decentralized Identity in ActivityPub.
Matrix team drafted a useful spec in the last few months:
This was followed up by two scrutinizing but ultimately positive blog posts by a community member:
Unfortunately they apparently rn out of funding for this work, so itās stalled at the moment. I believe the work was happening as a substrate of their overarching effort to become MLS compatible.
The MIMI/MLS standardization effort is well worth reading up on for anyone working on nomadic identity in the fediverse. Thereās a lot of overlapping requirements pertaining to identity.
End-to-end (E2E) security is a critical property for modern user
communications systems. E2E security protects usersā communications
from tampering or inspection by intermediaries that are involved in
delivering those communcations from one logical endpoint to another.
In addition to the much-discussed E2E encryption systems, true E2E
security requires an identity mechanism that prevents the
communications provider from impersonating participants in a session,
as a way to gain access to the session. This document describes a
high-level architecture for E2E identity, identifying the critical
mechanisms that need to be specified.
See also:
A WIP protocol called Polyproto is also figuring out federated identity.
The polyproto protocol is a home-server-based identity federation protocol specification intended for use in applications where actor identity is needed. polyproto focuses on federated identity, and apart from the usage of Messaging Layer Security (MLS) for encryption, does not specify any application-specific features. Instead, it is intended to be used as a base for application implementations and other protocols, such as
polyproto-chat- a chat protocol built on top of polyproto. Through a shared ābase layerā, polyproto implementations are intercompatible in a way where one identity can be used across various polyproto implementations.
we had been in talks with some folks on client-only weak multihoming, but not much ever came out of it, mainly everyoneās too busy with other stuff to work on it.
Iāve been discussing this in various contexts and Iāve been trying to understand what the requirements are for Portable Objects. Do they include:
- An
idthat survives migration or āserver deathā of the originating server? - Deduplication of content across imports, i.e. to dedup the original and the imported version on a 2nd server when importing everything from the 2nd to a 3rd server,
- Tamperproofing the object against failed imports, i.e. scaffolding failovers/manual-interventions/etc.
- Long-lived identifiers for content (for, say, moderation tracking and replayability)
- Globally-unique identifiers for content,
- Requiring a live DID āin the loopā on each dereferencing of an
id(isnāt that what happens when you make a DID the authority of a URI?), or for that matter the opposite of that, - Some others Iām missing?
The only requirement is location independence. The object should be valid when it is served by a server, and it should also be valid when it is stored on a USB flash drive, for example.
FEP-ef61 portable objects have this property, and that leads to solutions of many problems, including the ones you listed (though Iām not sure what do you mean by 6). The price of that is a new problem: key management.
Right, the key management problem was what I was fumbling for a way to talk about in #6 ā if a private key controlling a did:key gets lost or compromised, donāt did:key URLs break, or at least render authentication of them impossible or dangerous? I was surprised to see a DID method without rotation offered as the only example!
Maybe this FEP would be more powerful if it described a pattern that multiple DID methods could work with rather requiring one specific DID method? That way you offload key management problems (and the āPDS question,ā i.e. how portable and uniform to make data stores for portable data) to different DID methods per use-case/user-profile/implementation, which might make different tradeoffs and support a different subset of possible did methods and PDS interfaces.
For example, the DID spec defines a few query params that theoretically can work across all did methods (or at least, defines them as āreserved wordsā that the did method canāt overdetermine), while DID URL pathing (did:example.com:1234/actor) only works for DID methods that happen to implement pathing in their resolvers (there arenāt very many of them using this! the most advanced is did:cheqd, which runs on Cosmos IIRC). For example,
did:example:123?service=files&relativeRef=/<some GUID>&hl=<hash for integrity-checking>
is a valid DID URL across any DID method that supports a serviceEndpoint of type files, itās kind of the low-level API for asking the DID resolver:
point me to this fine DID's portable object <GUID> and what you send back better match <hash>
, which a DID resolver routes to the files endpoint if DID 123 has one.
FWIW lots of DIDs do use a specific endpoint typed files and have relatively-similar APIs running at those endpoints:
did:ionwas maybe the first (used in Microsoft Authenticator and Blockāsweb5initiative),did:plcis crucial to BlueSkyās portability design, you update your did doc (new files endpoint, new pubkey) when you move your data to a new PDS,did:webis free-form, you can put any properties you want in adid:weband rotate keys or endpoints as often as your web server setup allows you to. Fewdid:webs of the formdid:web:example.comuse service endpoints, but presumably systems might some day exist that have rotatable/portable PDS for each user of a large system, likedid:web:example.edu:bumblefudgeordid:web:xitter.com:user1234, and automate a bit key rotation and updates to ācustodialā DID docs that a server portions out to users not directly empowered to control their apex domain website.
None of this is an argument against defining a did:ap (I think itās inevitable that at least one AP implementation will want one for something!), but independently of that I wanted to spitball towards a more generic Portable Objects concept that accomplishes the same goalsā¦
did:ap can be used to extend any DID method. The relevant part of the FEP:
did:apis a DID method that can be used to add DID URL functionality to other types of DIDs.
So did:ap:web can be defined in the same way as did:ap:key. Iām primarily interested in did:ap:key because it doesnāt require any servers or blockchains.
Can you say a bit more? How does a did:ap:key get resolved, if there are no servers?
did:ap:key is a generative DID method which is identical to did:key but has DID URL logic attached to it. DID URLs are resolved by ActivityPub servers (so I should probably have said ādoesnāt require any additional servicesā).
Right, so basically, did:ap:key offers the worst of both worlds (of did:key and did:web) ā like a did:web, it needs a server (to resolve the service endpoints), but unlike a did:web, it canāt be rotated.
Just use did:web.