WebID

 WebID  is an authentication mechanism based on browser SSL certificates, as well as a potential name for a future browser API for integration authentication in the browser; no known IndieWeb usage, see IndieAuth.

IndieWeb Examples

 * none currently

WebID/Indieauth integration possibility?
Note: The discussion below appears to be referring to RelMeAuth rather than the protocol IndieAuth. This is likely due to the IndieAuth naming confusion that has been an ongoing issue.



Could/should IndieAuth be expanded to support WebID URLs as inputs? This could instantly expand its usage potential and applicability and mean that authors using only one of the two standards could use IndieAuth with no further work on their part. Because IndieAuth is based on domain names rather than URLs, it'd presumably only be valid where a WebID was based at (or redirected-to from) the root of a domain, but doubtless some are (or would).

Example workflow:


 * 1) Tim wants to log in and provides his personal URL, https://www.w3.org/People/Berners-Lee/ (note that for IndieAuth compatibility, he'd need a domain name of his own as described above)
 * 2) The parser reads the page as usual; it doesn't find any usable rel="me" links but it does find the link to his WebID, identified by the #i suffix to the URL:
 * 3) It requests his WebID via https://www.w3.org/People/Berners-Lee/card#i (with Accepts: text/turtle) and gets the document found at https://www.w3.org/People/Berners-Lee/card.ttl
 * 4) This contains a   block whose   section includes, among other things, , a valid IndieAuth authentication provider, which can be used to verify his identity in the usual way

undefined: What additional use-cases are enabled? (None AFAIK) Sure it seems possible, but lots of different plumbing approaches are possible (see the history of OpenID for example). Possible is insufficient as all code has a cost of implementation and worse, maintenance (something that OpenID itself had problems with, client libraries etc.), and particularly in this case, security concerns. Just look at the additional technologies that the example workflow would require, while providing no additional user functionality: Each of those requires (possibly new) code, testing, maintenance from the consuming code side.
 * 1) WebID discovery "#i"
 * 2) conneg support to retrieve text/turtle hosted sidefile, a known anti-pattern
 * 3) parsing text/turtle
 * 4) turtle auth provider discovery

From the publisher side, it would require: That's a lot of steps/files/data for the publisher, each of which adds confusion and fragility to the setup, which we know even from OpenID requiring *two* publisher links from their home page, is enough to cause non-trivial breakage.
 * 1) publishing a hyperlink to a separate "Data about me" from a home page
 * 2) maintaining a separate "Data about me" HTML page
 * 3) maintaining a sidefile version of that page in another format
 * 4) maintaining additional properties in that sidefile ":account" to link to a OAuth authentication provider profile
 * 5) a link back from that OAuth authentication provider profile to that home page

Whereas IndieAuth at a minimum requires one step for the publisher Most folks with their own website have already done the other half:
 * 1) add rel=me to an existing hyperlink to an OAuth authentication provider profile
 * 1) a link back from that OAuth authentication provider profile to their website

That simplification (to one step in common cases, two if setting up from scratch) makes IndieAuth much easier to setup and maintain (more robust) than OpenID (requires two links instead of one for delegation), and certainly much easier that the WebID card example workflow.

It appears that worse than just not providing any additional use-cases, the example WebID workflow would add unnecessary complexity and fragility to IndieAuth, and for that reason I would highly recommend against it, both for publishers, and identity consumers.