Autonomous identity for the pluriverse based on OAuth/OIDC

ActivityPub
1

Both the primordial fediverse of ActivityPub as well as the federated Matrix have been mulling over various private-key approaches to the ideal of decentralized or nomadic identity, but I think we’ve been trying to solve too many deep-rooted problems in one go. This has kept us in a holding pattern for many years:

Meanwhile there’s a major convergence of OAuth/OIDC support across apub applications, Matrix is going all-in on it as its root default, and other social web protocols are tagging along as well.

ActivityPub

Matrix

Other

  • Solid-OIDC

  • 2023 Protocol Roadmap | AT Protocol
    “Auth refactor: We want to improve both third-party auth flows (eg, OAuth2), and to support verifiable inter-service requests (eg, with UCANs). These involve both authentication (“who is this”) and authorization (“what is allowed”). This work will hopefully be a matter of integrating and adapting existing standards.”

Core Identity

I’ve been thinking intently about identity since the start of this year:

This line of thinking brought me to a framing that helps me categorize different web applications for my own purposes:

  • Stream = Declarative, linear flow.
  • Bonfire = Discursive, omnidirectional flow.
  • Garden = Contemplative, bottom-up flow.
  • Identity = Conduit of flows.
    Your identity (ID) both inhabits and holds the places and behaviors which the Bonfire, Stream and Garden symbolize, simultaneously experiencing and expressing itself through those outlets.

These metaphorical constructs exist in the web as concrete protocols:

There are no strict boundaries in the Stream/Garden/Bonfire trio. A blog for instance can behave like a bonfire when it is more discursive through its comment sections, it can be consumed in stream-form via an RSS reader, and it takes the shape of a garden when it’s deeply interlinked and less concerned with chronology.

Likewise, Reddit’s individual threads are bonfires, its frontpage feed is a stream and its ‘best of last week/month/year’ is an organically structured garden.

There’s no need to agree on the exactness of these analogies. What I do hope we can agree on is that identity ought to be distinct from any specific authorship protocol.

Mitigating sysadmin authority

Like the separation of church and state, it seems prudent to keep the management of our digital identities separate from our social network servers.

My default ‘fedi ID’ is currently hosted on writing.exchange/@erlend - a Mastodon instance. This is already a big improvement from letting Twitter (or Google, or GitHub) be the chief custodian of my digital identity, since they won’t even let me move elsewhere if I’d like to do that. Mastodon makes that possible, thus giving me some genuine ownership over my contact list.

But I’m still beholden to an external server admin. Should writing.exchange go down, that’s my fedi ID gone, along with all my followers (contact list). This has already happened to several fediverse instances being run by hobbyists who for whatever reason (lost interest; finances; health; technical issues) stopped running their server, in some cases with no warning whatsoever.

Users on a fediverse server are also disempowered in more subtle ways:

  • If an instance admin defederates from another instance in the fediverse, users won’t be notified of any followers they had from that instance; they’re just silently lost
    (Apparently Mastodon has plans for this, but I don’t think instances should be fully trusted with this responsibility anyhow.)

  • A user can be banned, their account made inaccessible, unable to take their data elsewhere. Regardless of legitimate reasons for banning users, invalidating their default online persona is a kind of digital death sentence without opportunity for appeal. Very few offenses actually merit that kind of punishment.

Bluesky solves this in a web3 kind of way as a self-authenticating social protocol, based on a combination of DNS names and Decentralized Identifiers. However, some number of unknown unknowns remain in this space, and for now their solution depends on a centralized authority to function.

However, I do think some limited degree of centralized authority is necessary as a first step out of our current identity entanglement. The internet runs on all sorts of centralized technologies - e.g. Let’s Encrypt - and we go along with it because their innate openness grants us credible exit. The loss of Let’s Encrypt isn’t an existential thread to my online persona, but the loss of of my Google/GitHub/Mastodon account very much is.

Domain-based accounts

The shortest path to a baseline of identity autonomy as far as my fedi ID is concerned would be if Mastodon allowed me to log in with my own OIDC account, instead of insisting on making one for me.

I can imagine three different degrees of OIDC autonomy:

  • Completely self-hosted OIDC provider.
  • 3rd party OIDC provider service, entrusted to do auth on behalf of my own domain.
  • 3rd party OIDC provider service that provides a (sub-)domain for me.

Even the last option is an improvement over the status quo, because even though I’m still entrusting my identity management entirely to a 3rd party, at least my identity isn’t tightly bundled together with my social networking persona. And that 3rd party would generally be more trustworthy/reliable than your average ActivityPub instance if some institutional actors similar to Let’s Encrypt have stepped up as providers, like Mozilla, Linux Foundation etc.

So what I want is for Mastodon to let me sign up on its server via my personal domain name, the same way currently I log into Mastodon/ActivityPub clients via my personal (but not autonomous) Mastodon domain.

I.e. when signing up for an account on an instance like writing.exchange or mastodon.social, I should get to sign up with erlend.sh via web sign-in.

:warning:
My inability to follow the exact technicalities of authentication specifications is a limiting factor here, so I will need some help correcting or expanding upon what comes next.

I know what I want is something IndieAuth-like, which apparently Mastodon is close to supporting already. But it seems more accurate to refer to the functionality I need as plain web sign-in, because IndieAuth is apparently not OIDC compatible.

But that general method of signing in with ones personal domain is essential for self-hosted/indie OIDC to work as a form of SSO in spaces that are outside of your own control, e.g. a Mastodon instance, because we can’t rely on prefilled provider options such as Google, GitHub & Facebook.

Web sign-in presents a middle road between the broken status quo and the ideal state we need to get to. It doesn’t solve the subtle lock-in effects of a traditional fediverse instance on its own, but it realizes the essential first step of making netizens’ online identity independent from their impermanent choice of fediverse instance.

As such, domain-based accounts, especially when self-hosted, serve the function of a minimum-viable ‘nomadic identity’.

minimal definition of user agency:

  • Own your ID
  • Own your content
  • Own your contacts

Another way to put this is that I wanna make the equivalent for the fediverse of what my former boss Jeff Atwood envisioned for Discourse as a “gravatar on steroids”.

Implementation

Whether Mastodon will be the pioneer of OIDC-powered web sign-in remains to be seen.

This Kitsune issue served as a seeding ground for the ideas I’m conveying with some degree of greater clarity here. Kitsune is a particularly exciting candidate for this exploration because it aspires to support multiple domains as well as domains as usernames, which aligns perfectly with domains as root authorities of identity.

It’s also made in Rust, further aligning it particularly well with Rauthy which, to my knowledge, is the most mature OIDC server/provider around that is optimized for self-hosting. I’ve previously written about how Rauthy could essentially be used as a compatibility layer between ActivityPub and Solid, but Solid is in no way a prerequisite for any of this ‘autonomous fedi-ID’ MVP to work. The storage layer backups of post content & contacts could just as well be built directly on top of Rauthy, or an experimental protocol like Solid-lite.

Proving this out will require:

  1. An implementation of web sign-in/up in the likes of Mastodon or Kitsune.
  2. Support for web sign-in in Rauthy.
  3. A hosted instance of Rauthy, configured for ActivityPub SSO.

Personally I’m also very interested in the fully self-hosted use case of Rauthy, which could be operated through a Tauri desktop app and bundled together with a basic site generator:

This topic serves as an open-ended call to action for anyone who might be interested in pursuing this together with me and a bunch of other folks such as the maintainers of the Rust projects mentioned herein.

3 Likes
2

These problems are not unsolvable and in fact were solved long time ago (see Hubzilla and Zot).
FEP-c390 is almost 1 year old, it is a very simple mechanism that can be quickly implemented. It’s not like we’re desperately looking for solutions here in Fediverse. We have them.

OIDC is not really a solution, it is just kicking the can down the road. As an ordinary user, you still don’t own your identity, but instead of instance operator your identity is controlled by a 3rd party (identity provider). It will open the door for things like “Sign In With Google”, literally a recipe for re-centralization and corporate capture.

3

I’m a big fan of FEP-c390 and have been advocating for it all year. I do believe it’s key to a longer term solution, strong emphasis on long term. It has yet to get any traction in the wider fediverse. Meanwhile, OIDC is implemented (or on its way) practically everywhere.

I see it as an intermediary step. Something for the ecosystem to converge on, leading up to the much larger coordination challenge of truly decentralized identity.

You are making perfect the enemy of good here. If you self-host your own OIDC provider you do indeed own your identity, and doing so is much more realistic than a resource intensive and always-on apub server.

And even if you rely on a 3rd party host, an important separation of concerns has taken place, thus taking one step closer to full autonomy.

That’s simply not true. Web sign-in (like IndieAuth) by OIDC is the antidote to the auth-monopoly of the megacorps.

OAuth/OIDC is already implemented in most of the popular apub applications, and they’ve opted not to add ‘social logins’. Nothing I’m proposing here would change that.

2 Likes
4

What do you mean by “full autonomy”? And how OIDC is one step closer to that?

Autonomy is when you control your private key, OIDC is a very different thing. Given an option, most people would choose convenience and use 3rd party provider (no autonomy). Then lock-in happens and it gets much harder to switch to a better technology. Also, people who are able to self-host have no reason to deploy OIDC provider because the footprint of a good AP server is comparable to the one of Rauthy (which you used as an example).

OAuth, but not OIDC.

5

I don’t understand how just signing in with OIDC changes anything about whether you own your identity, or have autonomy with it, or whatever. I think you’re making some specific assumptions about what an identity even is, and it would help if you could unpack those.

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.

2 Likes
6

It’s not completely orthogonal though. OIDC can serve as an arbitrator of private keys:

This sort of thing paves a path towards incremental adoption of private keys rather than working in opposition to it as some either-or proposition. It’s not a lock-in scheme, it’s an onboarding mechanism.

An AP server requires persistence. An identity server does not. You only need to run an identity server when you’re authenticating yourself online, which makes it particularly well suited to self-hosting even by non-technical people:

  • Persistent uptime is not a concern.
  • Attack surface is minimized by limited windows of uptime.
  • Total resource usage is orders of magnitude smaller than always-on server :leaves:

Right, thanks for making this clear. That’s the kind of technical exploration I need help with thinking through here, in a ‘it could work if…’ kind of way rather than ‘it won’t work because’.

For instance, could a lightweight OIDC provider like Rauthy be extended to act as an ‘actor ID provider’? Thus letting me extricate and properly own my actor ID from whichever apub server I am effectively renting as a pipe-on-demand.

The Rauthy maintainer has clearly expressed openness towards this type of functionality. They already added WebID logic to accommodate Solid.

1 Like
7

Could it work? Maybe. Other servers are going to retrieve your AP objects by making get requests to the ID url*. So you could conceivably have some situation where the IDP will host your actor object, while the fedi server does all the federated messaging, and presumably hosts all your content. But then the fedi server likely also needs to be able to modify the actor object stored by your IDP, because the fedi server has to have access to your private keys so that it can authenticate you to it’s peers, but the IDP server needs to serve the corresponding public key as part of your actor object so that the peers can verify your signatures.

This all gets very complicated very quickly, and for a benefit that seems pretty marginal. I think it’s also straining the role that identity providers play, which is really to be an authentication authority within an IAM system. I think in the past you’ve proposed a standard of being able to effect a credible exit from one fedi host to another. I think that’s a lot more manageable, and the benefit is clearer. The main technical requirement to accomplish that is to be able to take your private key with you and import it to the new server so that it can generate activities for you that 3rd parties will recognize as authentic.

*As I understand it, Mastodon doesn’t do this consistently, and will only do actor lookups via webfinger in may situations. But that’s not a behavior envisioned by the AP spec, and not the way any other fedi software works, as far as I know.

1 Like
8

All very complicated. Why not simply use nostr public keys like soapbox/ditto. This is going to work, is already in progress in major clients, adds massive developer base, eco system and apps. Also compatible with Solid (OS / lite).

This will be working quite soon, id suggest hopping on board.

Nevertheless, it will be interesting to see if other approaches are tried.

It’s one 64 char field in the profile. Allows sigs, encryption, migration, portability, single sign on, and much more.