IndieAuth and RelMeAuth

[erlend-sh]

As part of Rauthy for fediverse logins, support for IndieAuth would further facilitate this. Mastodon is already close:

• Add support for IndieAuth authentication mastodon/mastodon#24066

Frankly I don't understand what remains in Mastodon to be IndieAuth-capable, since it already supports a form of the 'authenticate with own URL' flow that's emblematic of IndieAuth. Partially explained here:

there’s also been mention of IndieAuth which has a very similar flow to Mastodon but doesn’t require generating a disposable “client” connection up-front (and has a few other affordances to standardize how profile information is shared).

I also don't understand the difference between IndieAuth and RelMeAuth (web-sign-in) 😅 but the two seem closely related.

[sebadob]

I have never heard of both of them, but could this be an overlap with #133 ?

[erlend-sh]

There's probably some overlap, yes. To my basic understanding, IndieAuth and Solid are two different approaches to the "bring your own id" model. To some extent I think they also have a notion of 'domain-based identity' in common.

The similarities probably end there though, since IndieAuth is merely an OAuth extension designed to accomplish nothing more than the aforementioned, whereas Solid is a standalone, general-purpose protocol for decentralized applications.

Maybe @damooo can speak more to the similarities/differences.

[damooo]

There are these specs, namely: OAuth, PKCE, DPoP, OIDC, Solid-OIDC, IndieAuth. They are related in following ways:

OAuth:

A specification to authorize third party apps (RP/Relying parties) to access resources belonging to a resource-owner from a resource-server(RS). It accomplishes that by introducing an extra authorization-server (AS), and describe few flows, so that client(RP) can get an access-token from AS that riefies resource-owner's consent. The RP then uses the token at RS to access resources in scope. RS honours the request, if issuer AS is trusted by it, and token is valid.

PKCE, DPoP

These are general extensions to oauth flow to mitigate few security attacks. PKCE will mitigate stealing authorization_code to later using for token. DPoP mitigates using stolen tokens or replay attacks. These are recommonded and implemented in most solutions, like keycloak, okta, auth0, connect2id etc. And are mandatory for few profiles of derivatives like solid-oidc, FAPI for financial apps.

OIDC:

Openid connect is a layer over generic oauth protocol that is specialized for getting user's identity information, rather than (or with) any other generic resources. It specifies and standardizes many more steps over oauth protocol, like discovery endpoint, user-info resource structure, extra id-token, etc. It is bit complex than simple oauth.

Solid oidc:

It is one of the many components of solid ecosystem and rdf ecosystem.
Is a thin profile over oidc, to tuned for decentralized identities. "Thin" in the sense, it adds following requirements:

• Users have webids that are dereferable to a doc that links to their prefered oidc identity provider.
• Client registration is optional, and if client_id is a uri that derefers to a oidc client description, it should be honoured.
• dpop is mandatory, so that tokens can be sender-constrained.

I described here on how it enables decentralized identities.

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. And dpop provides sender-constrained semantics allowing to be used in decentralized systems.

Indie auth

Has same goals as solid-oidc.
But it is not oidc compatible. Specifies custom profile over oauth.

• It requires user to have a web uri as id (just like webid). But the notion of what the uri represents is not rdf compatible.
• It requires client, and AS too have a web doc.
• The discovery of information about user, client, AS is through derefering corresponding web page, and parsing the html to extract indie-auth specified indie-metadata.
• It doesn't yet specify any mechanism to prevent token reuse by malicious resource servers at other resource servers in decentralized ecosystem.

[erlend-sh]

IndieAuth combined with self-hostable OIDC by the likes of Rauthy solves the most critical shortcoming of the fediverse as it exists today, which is the lack of self-sovereign identity.

My fedi ID is currently hosted on https://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 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.
• 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.

IndieAuth 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 Mastodon instance on its own, but it realizes the essential first step of making netizens' identity independent from their impermanent choice of fediverse instance.

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 IndieAuth.

[sebadob]

Support for Solid OIDC should (hopefully) be good with this: #133 (comment)

Regarding IndieAuth, I had another look at it. As I understand it, it would actually be obsolete, if you have your own Rauthy instance already, since Rauthy works as your own SSO provider and I don't see the value you would get from putting IndieAuth as man-in-the-middle. Am I missing something here?

[erlend-sh]

Am I missing something here?

Probably not, as long as some form of web sign-in is still possible. IndieAuth is just one specific implementation of that concept. But that general method of signing in with ones personal domain is essential for self-hosted OIDC to work as a form of SSO in spaces that are outside of your own control, e.g. a Mastodon instance.

[sebadob]

Okay, got it. I will have a look what would be needed to make this work with Rauthy directly.