Autonomous identity for the pluriverse based on OAuth/OIDC

[erlend_sh]

@jenniferplusplus

As far as anyone on the fediverse is concerned, my identity is my actor ID, which is a URL controlled by my server. OIDC doesn’t change that. If I sign up for a 2nd service, the fediverse sees that as two actors. So this makes OIDC nice to have, but not advancing any real goal related to identity. Even if you host your own IDP.

The possible alignment at hand seems clearer now thanks to the emergence of “B.Y.O. Actor ID”:

FEP-7952: Roadmap for Actor and Object Portability

Discussion thread for FEP-7952: Roadmap for Actor and Object Portability, which is a normative FEP about how to create and handle Actor-rooted (as opposed to Server-rooted) ids for objects, based on self-hosted/independently-hosted, and long-lived (migration-aware, migration-suriving) Actor objects. Sound complicated? It’s not, I just really wanted to fit all the spicy stuff into one long sentence. Give it a read!

Unbundle the services and concerns of a typical instance

1. Sign everything: Recognize client-side cryptographic signatures as proof of authorship (by implementing FEP-8b32: Object Integrity Proofs), in addition to the current practice of relying solely on the instance URL.
2. B.Y.O. Actor ID: Using Object Integrity proofs enables Identity Hosting to be separated from the other instance concerns. Actor profiles can now be hosted separately from the instance (including as a static JSON object on a personal website), which in turn enables service providers to offer their users a “BYO (Bring Your Own) domain name” feature.
3. Separate Inbox/Outbox: (Optional) The previous steps enable message transfer and Inbox/Outbox hosting to be outsourced to separate service providers (the Actor profile links to these in the usual manner).
4. Separate Object and Collection hosting: (Optional) Similarly, AP Objects and Collections can now be stored on domains separate from the Actor’s domain (since authorship and controller-ship can be proven cryptographically, in a domain-independent way). This enables the user to migrate storage service providers without having to change their Actor ID.

@bumblefudge

the idea is to detach the Actor object (which could be operated by a microserver that consumes almost zero resources, and basically just operates a big redirect table like a link-shortener) from the Service Provider, to be a little more like email (in the use case where you point a domain that you own and configure at protonmail or mailgun or some other provider) or SMS service (in that regulation enables you to keep your number when you switch phone co’s).