I am curious as to whether ActivityPub could support something like did:web or maybe did:webfinger for discovering the Actor object/document
-
@erincandescent perhaps better interoperability with things using did’s? e.g., I see some stuff about using did’s for verifiable credentials and stuff.
It's funny, we've did’s, activitypub actors/webfinger, and webid, all defined by the W3C
-
Erlend Sogge Heggenreplied to Emelia 👸🏻 on last edited by
@thisismissem @pfrazee.com some prior art by @arcanicanis here:
Nomadic identity for the fediverse?
hey all, was wondering, is anyone still actively working on #nomadicidentity for the fediverse? My interest in nomadic identity is somewhat inspired by scuttlebutt: to allow for migrating an account between servers, wit…
SocialHub (socialhub.activitypub.rocks)
-
did:web is basically just https: but guaranteed to resolve to a did document
(some) did methods (like did:web) come with the `services` property which can be used with `service` + `relativeRef` param to build relative URLs (which could allow you to e.g. make your activitypub ids have a variable baseURI, useful for migrations or for vhost type situations)
you also can put your keys into the did document instead of in the actor (and specify allowed usage of keys)
-
infinite love ⴳreplied to infinite love ⴳ on last edited by
@thisismissem @erincandescent for example having separate keys for separate purposes, your `authentication` key should not be the same as your `assertionMethod` key. if someone steals your `authentication` key they can login as you but they can't make any assertions on your behalf. this is like how github has separate sign-in keys and signed-commit keys
-
infinite love ⴳreplied to infinite love ⴳ on last edited by
@thisismissem @erincandescent note that you don't strictly need dids to do this stuff, it's just that did-core provides a convenient standardized framework for defining these things.
it's possible to have an actor uri be both a did document and an actor document and probably also a gateway/endpoint that resolves relative references. there's a fep that tries to do something like this https://w3id.org/fep/e3e9
-
@thisismissem I really do think AP could support did:web (and its successor, did:tdw). That was part of the motivation behind FEP-e3e9: Actor-Relative URLs https://codeberg.org/fediverse/fep/src/branch/main/fep/e3e9/fep-e3e9.md (basically, to provide a path for upgrade to DIDs). What's a DID? 1) Keys, and 2) service endpoints. For 1, there is https://codeberg.org/fediverse/fep/src/branch/main/fep/521a/fep-521a.md For 2, FEP-e3e9 and https://codeberg.org/fediverse/fep/src/branch/main/fep/9091/fep-9091.md show examples of how to do it. Taken together, they essentially turn an Actor into a did:web.
-
Erlend Sogge Heggenreplied to Emelia 👸🏻 on last edited by
@thisismissem @aaronpk sidebar: what about DIDs and OIDC, can we bring them into harmony?
#atproto couldn’t do OIDC because of their did:plc. Will resolving that require some major protocol wrangling?
-
Emelia 👸🏻replied to Erlend Sogge Heggen on last edited by
@erlend @aaronpk I think they could, there must be some JWT claims appropriate for DIDs, if not, that's a specification for someone to author: https://www.iana.org/assignments/jwt/jwt.xhtml
-
@thisismissem @erlend @aaronpk there isn't anything particular about DID:PLC w/r/t combining DIDs and OIDC.
some of our concerns with OIDC are that more-so than other parts of OAuth, devs/integrators expect OIDC to work in a particular way and integrate just like a central platform (Google, Twitter, Facebook, etc). where there is a single button you click to "Sign In With" -
@thisismissem @erlend @aaronpk in a decentralized system, what server does that button send the user to? the button doesn't know who the user is or have a way to determine what their home instance/server is. if you change the form/button to have that context, now you aren't really doing OIDC the way folks expect, you are doing some other para-OIDC thing. we though it was safest to just stick with our OAuth profile, which lets you type in a handle/account and then do authn
-
@thisismissem @erlend @aaronpk FedCM is a very promising solution here. OAuth generally is flexible. maybe OIDC can be made to work and we just couldn't figure out in a way that is both useful (gets the benefits of OIDC) and safe/secure (does not lead to exploits)
-
@thisismissem @erlend @aaronpk I know Emelia and Aaron know this, but a key thing for other folks reading this thread is that these identity standards are not simply "you implement them or you don't". there is a ton of wiggle room and sub-standards and vendor-specific decisions. so it isn't like you "implement OAuth" and magically everything interoperates.
though it is getting much much better in that regards over time!
-
@bnewbold @erlend @aaronpk yeah, of course not, and I'm not saying "use OIDC" (solid has managed to though, and it's a system much like AT Protocol, afaik), but we definitely can borrow ideas from OIDC (e.g., prompt, or userinfo endpoint, or profile scope)
I just found it surprising that AT Protocol's OAuth implementation is just tokens and features no mechanism at all to know who you've authenticated as nor where you need to talk to to access their PDS
