IndieAuth-brainstorming

From IndieWeb
Main article: IndieAuth

Brainstorming

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

Resolved Discussions

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.
  • 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. Aaron Parecki
    • 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
      • Martijn van der Ven: I think renaming the protocol is your call, Aaron Parecki 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.
        • Sven Knebel: +1, I think that'd lead to even more confusion
    • Martijn van der Ven: Note that no implementers have made the mistake. Acquiescence, commentpara.de, Known, selfauth all talk about IndieAuth as the protocol.
      • Aaron Parecki: This is a great point, and convinces me the name of the spec is fine.

    • Martijn van der Ven: 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:

      • Sven Knebel 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)
    • Sven Knebel 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.
      • Sven Knebel +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 discussion has been resolved by updating the example on the IndieAuth page.

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 rel="me" links, but some services needed me to declare IndieAuth as my authorization endpoint; […]

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 Tantek Çelik wondered why an extra step was needed.

  • I say this is a mistake in the How-to that needs to be addressed. — Martijn van der Ven
  • agreed, instructions about IndieAuth should explicitly include the endpoint —sknebel
  • -1 disagreed. Don't make more work for the >99% to satisfy the <1% who want to install their own IndieAuth providers. IndieAuth authentication services should handle rel=me without needing an explicitly specified endpoint. - Tantek Çelik
    • 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. Aaron Parecki

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 — 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 -- Kartik Prabhu 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:

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

See Also

Retrieved from "https://indieweb.org/wiki/index.php?title=IndieAuth-brainstorming&oldid=88464"