Interesting new DID method: "did:self"

One consequence of trying to separate identity hosting from the other components of the system is that it makes the other components harder to bootstrap. If I run just one component of my instance in isolation, how can I authenticate to it in order to configure/manage/test it, if I don't have an identity that I can use?

The answer might be to use a did:self identifier. The flow would look something like

• Management CLI tool generates a JWT describing a did:self identifier, and stores the private key locally
• Admin uses scp or something to copy this JWT to the right place on the server
• The server now has the ID's public key and so the CLI tool can prove that it "owns" the identifier

Which seems like a reasonable fix for the classic problem of "how do you create the first user", and also a useful fallback for when the system is too badly borked to be able to look up real identities.

Another interesting property of did:self is that seems to be possible to add extra metadata, such as a human-readable name, to the ID, by using standard JWT claims - without needing the data to appear in the DID document.

Of course these identities will only be visible to the server they're copied to, not to the whole network, but that shouldn't be a major problem.

(Cue the peanut gallery, with their suggestions of "it's easy, just do so-and-so", because everything looks easy when you take it out of context...)

#ActivityPubDev #FediDev