DID Discussions Meeting

[bmann]

Kicked off by a long thread by @dhuseby, who is now part of PL, in the #identity channel on FIL Slack. I kicked off a thread about doing some info sharing, and looking at if we might evolve the did:plc spec from ATProto / BlueSky (did:plc docs), and who might be interested in working on that.

Tagging @blaine @bumblefudge @Gozala @hugomrdias @expede @depatchedmode @cdata

Created a placeholder event for May 18th on Luma https://lu.ma/az50yb9v (sorry, we have a bunch of travel and events, but we can do some async sharing in the meantime).

[bmann]

One thing that this group is likely interested in, is that BlueSky's did:plc "Placeholder" is something that we'd like to form a wider group around who would actively use an evolved version of a did:account (or similar). Continues in thread.

I had an initial discussion with Privy https://privy.io/ who have did:privy that is also sort of a placeholder.

BlueSky literally labeled it placeholder because they want to go back and improve it. They are open to being part of an open process, but of course are also moving quickly.

Fission has been using very simple did:key, and is seeing a need for a sort of accounts container. Blaine Cook @blaine has been thinking lots about this with his NNS work.

Our revocation approach with UCAN doesn't use blockchain -- and neither does BlueSky -- so I think did:plc would be primarily a non blockchain DID approach, and it might be UCAN centric, not sure

[dholms]

This sounds great! I should be able to make it fine.

We should get @sternhenri from privy in on the call as well. He and I got the chance to talk about PLC a few weeks back.

I'll quickly note that the PLC docs are a bit out of date. The general model of consensus/authority/recovery remains the same, but we've updated the data model so that it's much more expressive as a full DID method now (instead of being particularly tuned to our usecase). It supports flexible service types & verificationMethods. Altho does not yet have support for did controllers, all crypto (only supports p256 & k256 atm) or verification relationships. This is primarily because we haven't needed them yet, not any philosophical stance.

I'm desperately trying to find time to update the docs, but haven't yet. Hopefully soon - next week or so! Til then, if there are any questions feel free to ping me

[bmann]

Great @dholms. Yeah I'll ping Privy, I see this very much as a kick off meeting to share info.

Getting clear on the constraints / requirements that people have would be excellent.

[sternhenri]

Would love to join! :) Lots of work to do here :)

[ianconsolata]

Just popping in to introduce myself and mention that I'm hoping to come to this too. I think most of you know me already, but if you don't I work at the Filecoin Foundation working with large social impact projects that use decentralized storage, and have a personal passion for decentralized identity and decentralized social apps of all flavors. I also co-organized the DecentSocial conference with @bumblefudge and others.

[OR13]

sigh.... this is truly a decentralized experience.

[bmann]

Adding a HackMD for notes for the session this week https://hackmd.io/MFqGxWiVTO-G_bz1MLS3Ow

@dholms you going to be able to update the docs ahead of this meeting?

@sternhenri can you please add a link to did:privy

I've put a couple of questions of my own in there for both of you.

everyone else -- feel free to add questions you have, otherwise we'll consider this an intro / kick off meeting to see who is interested in what.

[oed]

I've been thinking a bunch about DID interop recently and while it's hard I think there's a viable approach in using generative DIDs and revocation registries.

Wrote up my thoughts here:
https://stigmergic.org/posts/generative-did-maximalism/

[dmitrizagidulin]

I'm looking forward to this call!
As the co-creator of the did:web spec, I find it validating that the ordered hash log that did:plc uses is exactly the direction I would like to have seen did:web move towards (though several voices in the community opposed this).

[OR13]

BlueSky already lets you claim handles with txt records.

I think it would be cool to make more use of that feature, and allow for at least a few keys there.

Either by value or by reference to a JWKS.

I'd be cautious building complex did methods.

Keep an eye on the key transparency charter at IETF.

[bmann]

@OR13 got a link to that key transparency charter?

[AaronGoldman]

Does anyone know how did:dns works?
Is it like the BlueSky's _atproto.example.com TXT "did=did:plc:*"
even a _did.example.com TXT "did:key:123" that only populated the alsoKnownAs would get you most of what you need.

[OR13]

@bmann https://datatracker.ietf.org/wg/keytrans/about/

[OR13]

@AaronGoldman yep, exactly.

you could link any generative did method, to a specific https://www.w3.org/TR/did-core/#verification-relationships for at protocol, using the same approach.

You might also prefer to link by a reference there, like how OIDC uses well-known/openid-configuration

https://auth0.com/docs/secure/tokens/json-web-tokens/json-web-key-sets

You might care to take this approach if you want x5c / x5u support.