SSB DID Methods
In %xfBoK+g... I mentioned the idea of a SSB DID method. @kas previously explored this in %i2COg3Z....
@alanz and @Mix Android discussed multi-device/author DIDs around %F9ZnCGp.... I wrote about ways that can work: %65eRuSM....
I also started exploring using SSB ids with
There is room for more than one SSB DID method. e.g. one could be
ssb, another could be
Just one SSB method would be good for interoperability, but it could also be good to keep one simple and easy to implement, while another could support greater complexity.
There could also be other DID methods coming out of this and/or adjacent communities/networks, e.g. Earthstar, Bamboo, Pigeon.
Would anyone like to help make a
did:ssb implementation and specification? It would be great if there were multiple interoperable implementations, especially using different SSB stacks. I will probably start a
ssb-server/JS-based one, since that is the stack I am most familar with, but I could also help with a Rust-based one.
For hosting a specification and implemention(s) source, I plan to use
git-ssb. Repo (empty currently): %/DFLuc2...
Here is what I am thinking for it now. Syntax rules follow, borrowing some from DID Core's ABNF.
ssb-did = "did:ssb:" feed-id (":" feed-specific-id) feed-id = feed-type ":" 1*idchar feed-type = "ed25519" feed-specific-id = *( *idchar ":" ) 1*idchar idchar = ALPHA / DIGIT / "." / "-" / "_" / pct-encoded pct-encoded = "%" HEXDIG HEXDIG
The DID would be based on the SSB feed ID, with an optional additional part (
feed-specific-id). I propose that the feed id public key be encoded as base64url without padding (omit trailing "="). Using base64url allows for easier interop with existing SSB applications and SSB URI formats, but the "=" is not allowed in the DID
method-specific-id (it would need to be percent-encoded).
Creation, Updates, and Resolution
An SSB feed may create a DID document by publishing a message of some type. The message contains the DID Document representation type (e.g. JSON or JSON-LD), and the DID Document in that representation. Depending on the representation type, the DID document would be encoded as JSON in the message, or a string in the message, or possibly in a SSB blob which would be included by reference. To get the latest state of the DID document for a DID, one would query the most recent message of this type from the corresponding SSB feed.
It might be useful to allow updating the DID document with a patch, e.g. using JSON Patch, rather than requiring it to be published in full each time an update is made. I am not sure if the space savings would be worth the extra complexity required for this. Space limitations due to message size can be worked around by storing the document in a blob instead, and/or by moving parts of the document into separate resources (i.e. a verification method object could be stored separately and referenced with a DID URLs.
A SSB feed could also create DIDs other than their main DID, by appending ":" and some
feed-specific-id after their DID. This means each SSB feed controls a namespace for additional DIDs.
Additionally, the SSB DID method could support DID URLs with paths. A SSB feed could publish resources to paths under its DID by publishing a message similar to that of updating their DID document. Dereferencing these DID URLs would be similar to resolving DIDs. Resources at DID URLs with paths could be useful for referencing from the DID document(s), and/or other purposes.
DID Core encourages key rotation. SSB itself does not have this for feeds, although there have been discussions of it. I would like to largely defer to the underlying SSB mechanism for the relationship between an SSB DID and a SSB feed ID. If a mechanism of key rotation for SSB feeds gains adoption in multiple SSB stacks and distributions, then I think it could make sense for SSB DIDs to use that.
A simple starting point for SSB DID could be easily understood and have multiple independent interoperable implementations. DID-specific mechanisms for multi-party control could be used without specific support from the DID method, as described in %65eRuSM.... We could specify how multiple DID controllers should be handled. If SSB-specific multi-author/device mechanisms become prevalent, we could consider enable SSB DIDs to upgrade to use those. Or we could specify different feed types in the
feed-type part of the DID (which currently would otherwise be
Should non-SSB networks (alternative SHS capability key) be supported? This could be done with an additional optional part of the DID, or as a DID parameter (i.e. query string parameter). What about seed phrases for SHS cap keys (as in
ssb-gardens - %Jm+/spO... by @micro). Message signing cap keys?