See: http://microformats.org/wiki/relmeauth for more details.
- 1 Testimonials
- 2 Implementations
- 3 FAQ
- 4 Issues
- 5 Articles
- 6 See Also
http://microformats.org/wiki/RelMeAuth is nifty... like OpenId but even simpler.
RelMeAuth looks good, might have to re-add rel=me's to my site http://microformats.org/wiki/RelMeAuth
Invited to @IndieWebCamp, didn't have IndieAuth domain to login. Took 10s to add rel="me" to homepage. No "providers". Your move OpenID
Open source implementations
- IndieAuth.com - service and open source
- PHP: https://github.com/themattharris/RelMeAuth/
Q: Why does RelMeAuth need a silo backlink?
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.
Selectively Displaying rel-me Info
Selectively Displaying rel-me Info (e.g. hiding your phone number).
Tantek points out that he would like to be able to use SMS auth on IndieAuth.com, but doesn't want his cell phone number public on his site. 
Ideally your site would know that the request was coming from an (your?) IndieAuth server, and only render your phone number 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
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_secretwhich checks to see if the secret is passed in an HTTP header called "IndieAuth-Secret".
echo '<link rel="me" href="tel:+15035551212">'
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)
- 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!
A potential workaround is putting your phone number in a
<link> tag in your HTML head so that it isn't visible to viewers of your web page. (Currently aaronparecki.com does this.) While this doesn't actually prevent a person from seeing your phone number, it is at least an unlikely place for them to look.
RDFa Parsing Problems
Consolidated identities do not carry inherent trust
- 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.
Possible solutions have been mentioned through an extra link relation:
- Dan Q wrote a GitHub issue against IndieAuth.com proposing a
non-authoritativelink relation that could be added next to
meto instruct a RelMeAuth implementation to not use that page for authentication.
- Josh Juran proposed a
authlink relation in reaction to Martijn’s comment. If an
authis detected on the page, all
merelations should be ignored for authentication.
- 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 sknebel
- agreed, it's kind of like the addition of the
authrel value on a link upgrades that page to be more secure. Aaron Parecki
- 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
- 2013-08-26 How to set up Web Sign In on your @squarespace website
- 2013-08-31 On the Indie Web Camp Sign In UX Barrier
- 2013-08-31 On evolving IndieAuth