RelMeAuth

This article is a stub. You can help the IndieWeb wiki by expanding it.

RelMeAuth is an authentication method that uses personal URL for identity that rel-me link to established OAuth provider(s) to perform the actual authentication.

See: https://microformats.org/wiki/relmeauth for more details.

IndieWeb Examples

Most people listed on chat-names and Special:RecentChanges have set up RelMeAuth on their personal domain, since that or IndieAuth are required to edit the wiki!

Testimonials

Dan Connolly

http://microformats.org/wiki/RelMeAuth is nifty... like OpenId but even simpler.

[1]

Dan W

RelMeAuth looks good, might have to re-add rel=me's to my site http://microformats.org/wiki/RelMeAuth

[2]

Jeff Lindsay

Invited to @IndieWebCamp, didn't have IndieAuth domain to login. Took 10s to add rel="me" to homepage. No "providers". Your move OpenID

[3]

Implementations

Open source implementations

IndieAuth.com - service and open source
Node.js:
- https://npmjs.org/package/relmeauth
- https://github.com/superfeedr/node-relmeauth
Web
- https://observablehq.com/@endpointservices/auth
- https://auth.hawx.me/
  - Go source code: https://github.com/hawx/relme-auth
PHP: https://github.com/themattharris/RelMeAuth/

FAQ

Q: Why does RelMeAuth need a silo backlink?

A: RelMeAuth is composed of two building blocks, rel-me, and OAuth. rel-me requires bidirectional linking for confirmation of identity consolidation.

There are also usability, error detection, and recovery reasons for keeping such a double opt-in mechanism when delegating authentication. For example, it prevents one from delegating their RelMeAuth to another person's silo account.

Chat log

Issues

Selectively Displaying rel-me Info

Selectively Displaying rel-me Info (e.g. hiding a one-off email address).

Ideally your site would know that the request was coming from a RelMeAuth server, and only render your one-off email address if so.

This would require either

some sort of pre-registration with the indieauth server so your site could verify a shared secret
crypto signing with public keys so that pre-registration is not required

It is not possible to provide information to an arbitrary site without it also being available to attackers. A better solution to this problem is to implement IndieAuth so that you can have a trusted relationship with your IndieAuth server and authenticate with it however you want. That gives you a trusted channel to enter your email address, set up a multifactor auth option, etc.

1 pre-registration

Here is a potential example flow.

Sign in once to your IndieAuth server
Click a "generate shared secret" button, which is some 128-bit string that the IndieAuth server stores internally on your user record.
You take the string and add some code like this to your home page:
if header['IndieAuth-Secret'] == shared_secret echo '<link rel="me" href="mailto:oneoffemail@example.com">' end which checks to see if the secret is passed in an HTTP header called "IndieAuth-Secret".

2 public key

The IndieAuth server publishes its public key in its own h-card like
When the IndieAuth server makes a request to fetch the HTML of your home page, it also adds an HTTP header which is a signature of the IndieAuth server hostname, your domain name and the timestamp. It would send three additional headers:
- IndieAuth-signature: signature of indieauth.com;example.com;1378052578 (Format is a placeholder, in reality we might use something closer to the JSON web token format or something)
- IndieAuth-server: indieauth.com
- IndieAuth-nonce: 1378052578
When your server gets the request for your home page, it can read the IndieAuth-server header to discover which server is making the request, then go fetch its public key.
It would then compute the signature of the three pieces of information and verify that the signature passed in the header matches, at which point it can render the private info.

Please document here if there is some other existing mechanism that can solve this!

potential workaround

A potential workaround is putting your one-off email in a <link> tag in your HTML head so that it isn't visible to viewers of your web page. While this doesn't actually prevent a person from seeing your one-off email, it is at least an unlikely place for them to look. Though robots would likely still index it, so this is not a sufficient workaround.

RDFa Parsing Problems

If you use RDFa and are having problems, see rel=me: What about RDFa Problems.

Consolidated identities do not carry inherent trust

The addition of RelMeAuth (spec) makes for two use-cases for rel-me (spec):

Identity consolidation, enabling things like distributed verification.
Authentication through the linked identity.

These can sometimes be at odds with each other if the user does not trust the external profile page host to handle authentication. This can be because of lax security practices, a lack of certain features like 2FA, or any other subjective reason.

Martijn van der Ven has removed all rel="me" attributes, as of 2018-02-15, from links to websites that do not support 2FA. He only wants to use authentication providers that offer 2FA as fallbacks to his IndieAuth endpoint. Even if that meant giving up on identity consolidation.

See also the chat starting with his comment on the matter.

Possible solutions have been mentioned through an extra link relation:

Dan Q wrote a GitHub issue against IndieAuth.com proposing a non-authoritative link relation that could be added next to me to instruct a RelMeAuth implementation to not use that page for authentication.
Josh Juran proposed an auth link relation in reaction to Martijn’s comment. If an auth is detected on the page, all me relations should be ignored for authentication.
1. this seems nicer, explicitly calling out the trusted ones, and slightly nicer to implement. Also kind of establishes a pattern of rels to check in order: authorization_endpoint, auth, me Sven Knebel
2. agreed, it's kind of like the addition of the auth rel value on a link upgrades that page to be more secure. Aaron Parecki
3. I can understand the desires to 1. provide a non-authorative broader identity consolidation (which you would do with rel=me as documented), 2. keep the simple rel=me way to do both consolidation and authn, 3. and a way to limit which of those you wanted used for authentication. In which case, I'd suggest "authn" as the new rel value to use. And then there are a number of possibilities for how it should work. I like the "upgrade a rel=me" semantic that Aaron Parecki suggests. Though the effect is more of a slight downgrade of all the *other* rel=me links on the page. - Tantek Çelik
4. I don’t think it is either “upgrade” or “downgrade” at all. More of a branch off. For people with long lists of identities (I am approaching 30) trust may become an issue and thus branching authentication away from consolidation makes sense. Curious though: why the extra n in authn for the link relation? — Martijn van der Ven
5. That seems more-elegant than my suggestion; presumably we'd want both attributes (i.e. rel="me auth") in cases where the resulting link both represented me and could be used to authenticate me? So the process for an authenticator would be: (a) check for "auth", failing that (b) check for "me", and the process for a different service simply spidering for where I am found on the web found be: (a) just check for "me". Dan Q
6. This has been implemented in indielogin.com. See https://indielogin.com/setup#choosing-auth-providers for details.

Articles

2013-08-31 Barnaby Walters: On the Indie Web Camp Sign In UX Barrier (archived)
2013-08-31 Aral Balkan: On evolving IndieAuth. (archived)
- On Evolving IndieAuth Followup
2013-12-08 Barnaby Walters: How to set up Web Sign In on your @squarespace website (archived)
2018-05-27 Aaron Parecki: Dropping Twitter Support on IndieAuth.com (archived)

Brainstorming

Alternative flow for RelMeAuth via email

ask the user for their email address (like Slack and nearly every other service)
fetch the web page at the domain of their email address (e.g. aaron@aaronpk.com -> fetch https://aaronpk.com)
look for rel=me links on that page
if there is a rel=me link to their email address, use their domain name as their RelMeAuth identity
send a one-time link to their email address
when clicked, sign them in as their domain

note: obviously have a blocklist of bigco email providers domains that no one owns as a personal domain (gmail.com, hotmail.com, etc.)