IndieAuth-brainstorming

Brainstorming
Please consider opening a new issue on IndieAuth GitHub project instead of using this wiki page for new brainstorming.

naming confusion
There has been ongoing confusion between IndieAuth(-the-protocol), IndieAuth.com and RelMeAuth.

Most people use IndieAuth by using IndieAuth.com as their authorization_endpoint, which then does RelMeAuth to authenticate them, which has people conflate IndieAuth with rel=me-links.

Some might also just have rel=me links set up and only log in to sites which use IndieAuth.com (or other services that support RelMeAuth directly) to handle login for them, which means they are using RelMeAuth, but not IndieAuth(-the-protocol), while thinking they are using IndieAuth.


 * One problem with the indieauth.com site being called just "indieauth.com" is that people then think that IndieAuth is somehow centralized around this service.
 * plans to rename the two services that IndieAuth.com provides (an authorization_endpoint for people who want their site to support the IndieAuth protocol, and handling signing in users for sites like this wiki) to different names to lessen this confusion
 * See https://github.com/aaronpk/IndieAuth.com/issues/138 for name finding, and https://github.com/aaronpk/IndieAuth.com/milestone/1 and https://github.com/aaronpk/IndieAuth.com/milestone/2 for goals for the two separate services
 * This seems to be resolved. IndieAuth.com will become IndieLogin.com. The scope for IndieLogin.com is defined as “a service that developers use to log users in to a website. you create a web sign-in form that asks for their domain, and it directs people to indielogin.com to authenticate. users can authenticate by linking to Twitter/GitHub/email address/PGP key, and then they are asked to authenticate at one of those when signing in.”  Making a clear distinction between IndieAuth and any external login services.
 * In in-person conversations about IndieAuth/RelMeAuth/OAuth with people, I've found that most people think of RelMeAuth when they are talking about IndieAuth.
 * Another possibility is to rename the IndieAuth protocol (which is an extension of OAuth 2.0) to make it clear that the OAuth 2.0 extension has nothing to do with RelMeAuth
 * : I think renaming the protocol is your call, as the author of said protocol, but I feel it would be unnecessary. Especially if indieauth.com is getting renamed. This feels like an education issue, possibly a documentation issue (which we are already solving with wiki-gardening!). We don’t go and rename microformats because people have been writing blog posts where they used the word “microformats” and then described some other system like Microdata. Instead we educate on what the name microformats is.
 * : +1, I think that'd lead to even more confusion
 * : Note that no implementers have made the mistake. Acquiescence, commentpara.de, Known, selfauth all talk about IndieAuth as the protocol.
 * : This is a great point, and convinces me the name of the spec is fine.
 * : And no consumers advertise it wrong as far as I can find. Are there any implementations that use only indieauth.com and claim to be IndieAuth? That means not using something like indieauth/client and using the service as a fallback, but really using only the service? This wiki is an example of that, but also does not claim to use IndieAuth in any way! It describes its login as web sign-in and not IndieAuth. It mentions IndieAuth as an alternative for people who do not want to use their social media accounts, that’s a very correct description:  [[File:indieweblogin.png]]
 * Indeed, web-sign in seems like a fitting term here (given that the definitions talk about the general concept of using your homepage URL to sign in, and reference both RelMeAuth and IndieAuth as implementations)
 * I've been explaining IndieAuth at HWC Berlin to people from "has written an endpoint following authorization-endpoint" over "has logged into the wiki" to "IndieAuth, never heard of it". One of the first category wasn't quite clear on the status of non-Indieauth.com implementations of sites to log-in to (since they'd only used it with sites using Indieauth.com, primarily the wiki), second wasn't necessarily aware of a difference between service and protocol. Explaining the difference (and how RelMeAuth fits in) wasn't an issue, but had to be explicitly mentioned. I believe a different name for IndieAuth.com would go a long way there.
 * The wiki pages for IndieAuth don't always make this distinction clear, work has begun during IndieWebWeek (2017-05) to improve this
 * Work continued 2017-07-19 by moving FAQ and Issue items from this page to the pages they were about: RelMeAuth or indieauth.com.
 * New copy for this wiki page was written in a separate sandbox page where the focus was on explaining IndieAuth and its 3 parts. See User:Vanderven.se martijn/IndieAuth.
 * +1, to me this is just clarifying and extending existing documentation (e.g. the different endpoints, that currently only have their separate pages, and clearly separating .com from the protocol)

how-to should include endpoint definition
This would make sure first time users do not have to try and figure this out themselves. Example:

Getting myself validated through IndieAuth was already taken care of by the  links, but some services needed me to declare IndieAuth as my  ; […] — Embracing the IndieWeb by Daniel Goldsmith

Here “IndieAuth” refers to indieauth.com-the-service. The discussion above is about clearing up the name issue, this is only about including the endpoint declaration in HTML. Daniel ran into services that offered him to login with IndieAuth and required him to declare the authorization endpoint, completely according to how IndieAuth works. (As documented above, most implementers stick to the spec when they talk about IndieAuth.) This is currently completely left out of the how-to and new users are left to figure it out for themselves.

The wiki leaves users hanging who try to login using IndieAuth outside of the wiki. This how-to issue is documented here specifically because undefined wondered why an extra step was needed.


 * I say this is a mistake in the How-to that needs to be addressed. —
 * agreed, instructions about IndieAuth should explicitly include the endpoint — sknebel
 * -1 disagreed. Don't make more work for the >99% to satisfy the &lt;1% who want to install their own IndieAuth providers. IndieAuth authentication services should handle rel=me without needing an explicitly specified endpoint. - undefined
 * Again this just points to the confusion around the responsibility of who is trusting who. If you are just trying to sign in to the wiki with your domain, you do not need to ever worry about or see the term "IndieAuth". The wiki is doing "web sign-in" via RelMeAuth, IndieAuth, email or PGP authentication by letting the indielogin.com service handle the implementation details. If someone actually wants to implement IndieAuth, it's because they want to specifically tell applications where to send them to sign in, in which case they do that by specifying an authorization_endpoint on their home page.

IndieAuth using form-encoded responses instead of JSON
IndieAuth uses standard form-encoding for requests and response because it has been a standard encoding format since the beginning of the web. If it were a JSON response, then 7 years down the road you'd be asking "why is the response in JSON instead of ____" where ____ is the next trendy thing that replaces JSON. (Remember when XML was the new hotness?)

Proposal for content negotiation: https://www.tuxed.net/fkooman/blog/proposed_changes_to_indieauth_protocol.html#content_negotiation &mdash; Wwelves.org perpetual-tripper 02:26, 5 March 2015 (PST)


 * To me this would violate Postel's law, requiring every implementation to publish many different formats. I don't care which format IndieAuth produces, but I do think we should settle on one canonical format. Kylewm.com 10:03, 5 March 2015 (PST)


 * Agreed that there should be only one format. The only valid argument for JSON is that the OAuth 2.0 spec defines the response as JSON. Aaron Parecki 10:06, 5 March 2015 (PST)


 * OK I withdraw my objection to content negotiation. Agree it is a relatively small burden on a relatively small number of providers; it's worth supporting multiple formats for convenience to the large number of consumers Kylewm.com 12:06, 5 March 2015 (PST)


 * Just to be anti-inventing-new-formats (too many of them around and demanding attention), I'd go for form-encoded -- 00:21 2015-03-06


 * I just never saw HTTP POST form encoded _responses_ anywhere, only POST url encoded form requests... Any link to other (REST) services that use this? e.g. XMLHttpRequest does not support form encoded responses at all... fkooman

Requesting additional user details
The auth consumers may want to receive additional information about a user, and not just their homepage URL. Andy Baio raised some points in regard to this in a backer-only Kickstarter post, Opening the Source and The Great Auth Debate, 2015-03-16, when deciding what authentication mechanism to use for Upcoming.org.


 * Silos may give the application access to the user’s social graph: who their friends are, who they are following.
 * This would require some IndieWeb format for following.
 * This is great for applications like readers to start a user off.


 * Silos may give the application location information about the user.
 * This is great for applications like Upcoming.org that want to show relevant events.
 * This is possible by parsing the homepage URL of the user for h-card or recent checkins.

Need Simple Copy Paste How To
The explanation in http://waterpigs.co.uk/articles/indiewebcamp-signin-ux/ provides a list of three lengthy descriptions of what you need to set up IndieAuth, which was then subsequently criticized as "this is not a straightforward process" in the post: http://aralbalkan.com/notes/on-evolving-indieauth/

Thus we need a a simple copy paste how to that is not three lengthy descriptions.

Any explanation of how to use IndieAuth needs to start with a 1-2 sentence summary. No more.

Compare with:
 * Introduction to Twitter Sign-in: https://dev.twitter.com/docs/auth/sign-twitter
 * How Facebook Connect works: http://blog.facebook.com/blog.php?post=41735647130

Explanations for IndieAuth need to be at least as simple to understand as those for Twitter Sign-in and Facebook Connect.