You are reading content from Scuttlebutt
@cel %lZ4ZeBAdwEPQ1U1vqInHCKf0YiM4vqx7cXghtjyAn6w=.sha256

SSB DID Method (did:ssb) Draft 2021-04-04 (v0.1)

This is an initial draft for a SSB DID (Decentralized Identifier) Method specification.

This version: draft-cel-did-method-ssb-0.1.html

Latest version - online:
Latest version - patchoo: http://localhost:8027/web/%25B79jjfhYHrr%2BCPSDpr2S5vRGWUJ5vwyfzbYCp0OyV9k%3D.sha256

Changes since the previous thread %k70jWA9...:

  • Created document template, inspired by ReSpec and SSB HTTP Authentication.
  • Wrote Operations section. (Except use of DID URLs with paths)
  • Removed feed-specific-id from the DID syntax. (Keep things simpler for now.)
  • Started privacy and consideration sections.
  • Started abstract and introduction.

The Security and Privacy sections still need more work to satisfy DID Core's Security Requirements and Privacy Requirements for DID method specifications.

Please review if you are interested! tiniest_hermes.gif Feedback and improvements are welcome. If this is a good direction, I will open a draft PR to add it to the DID Specification Registries.

#ssb #did #did-ssb

User has not chosen to be hosted publicly
@cel-desktop %1KqElFkO2oDrU1+CLXQd1/WBngpwZprTH2ZjgIRWNrQ=.sha256

@jefdaj I assume you are asking about SSB generally. At the DID level, Verification Methods could be rotated or revoked, by publishing SSB messages to update the DID document accordingly. But an SSB feed itself doesn't natively have feed key rotation or revocation: whoever has your feed's private key can publish to your feed - forks notwithstanding.

SSB replication expects that every message is signed by the public key that is in the feed id (message author).
Prrevious discussions/mentions of feed key rotation: @ktorn in %0qQZ/Gp...; @dinoworm šŸ› in %AbdR7Rk....

Feed key revocation would be in other words, tombstoning: discussed by @cinnamon in %J8QCM+9...; @daan2 in %tSMYxsd....

It may be possible to implement analogous features to feed key rotation and revocation on SSB in the application layer - using the existing SSB primitives and protocols. But this would increase the complexity of the DID resolver/manager implementations, especially to support feed rotation. It would break the one-to-one association between the SSB feed and DID. In that case it seems odd to me to use a public key as the DID since that would only be the initial feed public key which might be later rotated: maybe instead the DID should contain a message id corresponding to a "create DID" message; then a feed could create multiple DIDs and be able to transfer control of them to other SSB feeds (as that is what application-level feed key rotation means). This more complex way could also be specified as a different additional subtype of the SSB DID, i.e. indicated in the feed-type instead of "ed25519". I think part of the "success" of SSB is its simplicity, e.g. using public keys as feed/account identifiers; I think it would be good to implement and demonstrate the simple way first, and gain experience with that before attempting a more complex integration. But it is good to know what features are desired, if at least so we can leave room for a future version or extension to support them.

@Rabble %YSMKcjw0612l5pCum9AQ31VrBGMK8fmxmPFVgoodZso=.sha256

I'm liking all the work you're doing on SSB & DID's. Have you thought about connecting with what @cryptix is doing with ssb-login? If we could make it so the ssb login was a did using jwt and did-auth it'd open up ssb to be the key to login to many services.

User has not chosen to be hosted publicly
@cel %e7lp+yGV8hQyRNj52o3nR00vYYOXKyOLZoyVYDn0IrM=.sha256

@Rabble I'm not familiar with ssb-login. What is this? cc @cryptix

There are multiple ways to authenticate using a DID. For example, Self-Issued OpenID Connect Provider DID profile (SIOP DID) (although I am not sure the status of this). I am more familiar with DID Auth based on JSON-LD Verifiable Presentations - as demonstrated in %vl6H2nZ.... That RWoT article is good and discusses what I think is an older version of VP-DIDAuth, as well as a JWT-based approach (I'm not sure what the latest version of that would be). Are there particular services you have in mind?

An SSB DID could be used with PatchBoot / Scuttle Shell Browser by @farewellutopia for in-browser authentication using Credential Handler API (CHAPI).

I'm not sure exactly the relationship between CHAPI and WebAuthN (which @cryptix did work on: %mE1gK3H...) - except that they are both extensions to the Credential Management API.

I don't see SSB authentication necessarily converging on DIDs: ssb-http-auth by @andrestaltz has ongoing work, as does login-with-ssb by @ancientsorcerer. Some applications may just want to authenticate SSB users specifically. But if SSB DIDs are specified and implemented, applications wanting to authenticate SSB users could consider DIDAuth based on a SSB DID as a possible option(s).

@cryptix %UTwqpq0esYgK0VZq0lrozNymBKdElXna3m/uzEt4lzI=.sha256

Iā€™m not familiar with ssb-login. What is this?

Me neither. While I was at planetary we vaguely dabbled around with some ideas similar to ssb-http-auth but never pushed something concrete.

Join Scuttlebutt now