Let’s say you have a mastodon account at mastodon.social and you want to move to a smaller niche community: there are some pain points there.
You can have it forward your identity but it’s a little weird and you’ll come up multiple times when people use tools like debirdify to find your mastodon.
Let’s say that I’m on mastodon.social but I want to browse a bunch of profiles on mastodon.gamedev.place. The experience from the web browser isn’t great and it’s pretty bad if not impossible to do this from the mastodon native app. You have to copy and paste names back over to the instance you’re from or use the multi step redirect follow action modal.
There’s lots of friction that needs to be worked out.
At least some of this appears to me to be rooted in a really proper federation of identity.
The Jack Dorsey, blockchained powered Bluesky protocol claims to have support for portable federated identity. https://blueskyweb.org/
Tim Berners-Lee has created a thing called the Solid project that’s specifically focused on federated identity. https://solidproject.org/
Is there any interest or movement on this subject within the AP community?
It seems to me to be a crucial source of a lot of friction for users.
You may want to breathe new life into the crossposted topics I maintained for a while between both communities. On SocialHub that is:
And on Solid community forum:
One issues is that both communities aren’t really healthy and keeping cross-pollination going is therefore hard. On SocialHub the reason is that AP dev movement is so grassroots and on Solid side the core team of people aren’t interested in community and focus first and foremost on commercial application of their specs to drive adoption.
There is a similar concept: nomadic identity. Though I’m not sure if it’s the same thing you’re talking about:
I’m currently writing a specification for a mechanism of linking any key-based identity to a fediverse account, you can find some additional information in that thread. AFAIK Solid uses domain-based identities, so unfortunately it’s out of scope.
There is a difference between nomadic identity and portable identities.
Portable identities allow you to migrate your identity to another server, whereas nomadic identity allows you to use your identity on and from multiple servers simultaneously.
As far as I know, the Zot protocol in Hubzilla, and the Nomad protocol in Streams are the only protocols that allow nomadic identity, and neither of them use DIDs. We are hoping that FEP-c390 would be written to allow nomadic identities by recognizing multiple authorized domains/clones of an account.
Bluesky’s ATP seems to allow portable identity, not nomadic identity, based on the limited docs available online. ATP uses DIDs. I am not sure how Solid identities work.
Another technology that should be considered is OpenWebAuth, which allows you to log in (technically, remotely authenticate) on other websites with your social identity. This is implemented in Hubzilla and Streams, and other forks of these projects. Recently, some developers are working on implementing this in other platforms.
OpenWebAuth would be out of scope of ActivityPub, but I mention it since it is relevant to the concerns mentioned in the original post.
Does that really make it out of scope? For the Identity Proofs spec perhaps, but I think not for nomadic identity in general. I kinda want a domain-based identity coupled with a key-based identity. Isn’t Solid a good foundation to which key-based ID could be added?
Though i am not deeply familiar (yet) with fediverse protocols, i will elaborate on how webid + dpop + solid-oidc, enable decentralized, nomadic identity that can be provable.
Say a user has ownership over a web uri (https to be complete). Eg: https://eg.org/user#me, which he can use as his name. I.e. user themself is a resource, and it is their universal name. This will be their webid. From now onwards anyone can use this name to talk about them in rdf statements.
Webid is required to either derefer or redirect to a web document, which is known as webid-document. In above case uri of the webid-doc is https://ex.org/user. (different from https://ex.org/user#me).
This document is public for the span of the world of discource. It contain authoritative info about the user as an rdf graph.
But user can also link to their oidc identity-provider.
Thus the main trick to decentalized id is this: User choose and own their id. That is dereferable. And links to their chosen (preferably self-hosted) oidc idp. Thus resource-servers (RS) and applications(RP) can trust the idp’s mandate on user’s identity.
When idp issues an id token to a client (RP), it can use that with any resource servers to act on behalf of user. (Scoped probably).
But an issue arises in decentralized ecosystem. I.e a malicious resource server can use that id token with other arbitrary resource-servers too.
Thus, it is imperative that, an id token issued by an idp must be scoped to a single client. This is what sender-constrainined-access-token do. DPoP essentially addresses this problem.
In dpop layered oidc, when client initializes oidc flow, it also sends its public key to the idp. Idp, then “bounds” the id token to this pub-key. And it includes that pub key in id-token signed jwt payload.
Thus, when a client wants to use it at a resource-server, it should send a dpop-proof, along with the id token. That depop proof must be signed with the private key corresponding to the pub-key it previously used at idp.
Thus resource server can verify the proof against bounded pub key to asset that, token is being used by the same client to which it is granted.
I was probably working on FEP-c390 at the time. Identity proofs rely on DIDs for encapsulation of key data, so in theory one could use did:solid too. The did:solid spec seems to be unfinished though.
The WebID spec is not finished. Unfortunately the chair of the WebID group sadly passed away, but it appears there’s a group wishing to continue.
I’ll be using WebID in solid lite and hopefully writing an AP implementation with microfed, and finally nomadic identity using nostr.
I dont think you need any more than this, I would avoid the other half-baked design-by-committee or token–based identity systems. There are quite a few out there.
WebID can handle all the use cases, and I’m in the process of documenting and implementing it with a few others.
I’m cautiously optimistic that this will unify the all the open social systems giving users more features, and allowing to move between the FLOSS systems fairly seamlessly.