Develop additional authentication mechanisms to run alongside WebID+TLS

[dmitrizagidulin]

Develop an alternative mechanism to the current in-browser-only certificate-based WebID authentication workflow.

Note: This is part of a two-pronged approach - 1) continue to improve the browser's certificate management UI and overall user experience (possibly get in touch with the browser vendors), and 2) (this issue here) develop a short-term alternative to WebID-TLS.

Friction points with current approach

• Firefox bug requiring browser restart when first signing up for a WebID
• User unfamiliarity with certificate management
• Lacking or limited support in several browsers (Internet Explorer, mobile browsers, etc)
• Lack of Log Out capability
• No good story for use on public/shared computers
• Limited or confusing UI for many use cases:
  • no good way of determining which app/browser tab is requesting a certificate (the UI only shows what datastore is being accessed)
  • difficulty in managing multiple identities, once a user has a handful of certificates
  • initial confusion when first using a Solid app, before a user has a WebID
• Current browser-centric focus makes it difficult for non-Javascript programming languages to interact with Solid

Possible Approaches (Proposals so far)

1. Username & Password authentication to a user's pod, and the pod would proxy requests (possibly using parts of the WebID Delegated Requests mechanism) to other pods
   • see "Extending the WebID Protocol with Access Delegation" paper
2. WebID RSA proposal
   • http://caniuse.com/#feat=cryptography
3. Use HTTP-Signature instead of WebID-RSA
   • IETF Draft 5 - Signing HTTP Messages
   • node-http-signature - Joyent's Node.js implementation of HTTP Signatures (see also their http_signing.md doc)
   • solid/spec/issue #5 for more HTTP Signature discussions
4. Sandro's Spot spec.
5. indieauth (see IndieAuthProtocol) / distributed-indieauth

Related / Helpful Reading

The Quest to Replace Passwords: A Framework for Comparative Evaluation of Web Authentication Schemes - a remarkable paper evaluating 20 years' worth of authentication schemes, and rating them on various criteria (security, usability, ease of deployment, etc).

W3C Credential Management Level 1 recommendations

Wikipedia entries: https://en.wikipedia.org/wiki/Single_sign-on and https://en.wikipedia.org/wiki/List_of_single_sign-on_implementations

JSON Web Tokens

W3C FIDO 2.0 Platform Specifications (see W3C Welcomes the FIDO 2.0 Member Submission post)

• FIDO 2.0: Web API for accessing FIDO 2.0 credentials
• FIDO 2.0: Key Attestation Format
• FIDO 2.0: Signature format

W3C Good Practices for Capability URLs

indiecert/auth and Introducing IndieCert blog post

• https://indiewebcamp.com/authorization-endpoint

WebDHT

YouID

[nicola]

Really great @dmitrizagidulin !

[sandhawke]

See my implementation and especially the opening comments on an iframe based solution at https://github.com/sandhawke/crosscloud.js/tree/master/browser

See a proposed simple-as-possible protocol, for third party auth, before I saw indieauth, at https://github.com/sandhawke/spot/blob/master/spec.md

[sandhawke]

If we want to allow authenticated communication between the browser and other people's pods, we should probably just use indieauth. See https://indiewebcamp.com/indieauth-for-login . It's similar to spot (see previous comment on this issue) but

○ requires folks to load and scan/parse users home page (boo!)
○ allows home page to be on static site (yay!)
○ is already in use by a community (yay!)
○ can claim to be oauth2 (yay?)

[sandhawke]

@dmitrizagidulin yesterday I somehow confused myself into thinking we didn't need any of these auth mechanisms during a proxy connection, when we spoke as I was leaving the office, but that's wrong.

However, I don't think delegation is motivated by the login/auth use case. In all four mechanisms on the table, your server can make an http request of another server and "prove" it's really you, no delegation necessary. In the case of webid-tls or webid-rsa it can just generate a keypair and then add the public key to your profile (or pretend it's there for a few seconds). In the case of spot and indieauth it just makes up a token and confirms it.

[melvincarvalho]

I dont think indieauth is a good fit here, there's are a number reasons for this, but primary is that it doesnt support linked data, which is a show stopper for Solid. I like SPOT better.

However along similar lines, I wonder if it would be possible to support something like passportjs

http://passportjs.org/

Or failing that OAuth. Previous iterations supported facebook/yahoo/gmail/persona (persona will now be discontinued) and that worked pretty well, with a decent user base.

@kidehen has also developed YouID which supports quite a number of auth methods, so perhaps an idea to compare notes.

[sandhawke]

@melvincarvalho your issue with IndieAuth is that it primarily uses HTML link elements instead of HTTP link headers or RDF predicates to link from the user's URL to the authentication endpoint? That's listed as an open issue on the spec, and I think if it were resolved as (1) try http header, (2) try media types you know, ... we'd have a compromise solution. Or is there something else I'm missing?

For passportJS and YouID would you mind pointing to protocol specs or instructions for how to implement? Also, if you happen to know their legal status that'd be helpful, lest we waste time looking at something that's encumbered.

I don't know what you mean by "using OAuth", other than basically doing what IndieAuth does, and which presumably YouID and maybe passportJS are doing. OAuth only provides building blocks, as far as I can tell (and I certainly don't claim to understand OAuth2).

[melvincarvalho]

@sandhawke I wasnt aware of the open issue in the spec, thanks for pointing it out. So, if the general pattern of using two way links to an third party provider, was compatible the linked data used by Solid, yes, that would be something to consider, imho.

My suggestions were mainly in the "food for thought category". I'll do some more research. I'll ask kingsley about youid (or maybe he'll chip in here) and try and find out how we hooked up with OAuth in the past.

[deiu]

From @sandhawke:

In all four mechanisms on the table, your server can make an http request of another server and "prove" it's really you, no delegation necessary. In the case of webid-tls or webid-rsa it can just generate a keypair and then add the public key to your profile (or pretend it's there for a few seconds).

How can it prove it is you without using your identity? I am personally against this behavior. Server agents should have their own identities, to allow a clear separation between the agent and user on whose behavior it is making the request.

[dmitrizagidulin]

@deiu Can you expand on why you're against that behavior? (of a Pod using a user's identity?)
We have this behavior already in all apps -- they borrow the user's ID to do stuff. This just adds the ability for Pods to do so.
You seemed on board with the general mechanism before, in discussion. (Specifically, that a user authenticates to a pod using a non-certificate mechanism, and then the pod using the user's certs to inter-operate with other pods using webid+tls as usual).

[deiu]

While client-side apps do have this behavior, a request only takes place if the user is currently using the app.

Indeed, I am very much behind the delegation idea. I'm only against pod agents reusing the same identity as the user's.

I'm OK with: Alice (alice#webid) -> Agent (agent#webid on behalf of alice#webid) -> Resource

I'm not OK with: Alice (alice#webid) -> Agent (alice#webid) -> Resource

[dmitrizagidulin]

What's the alternative? (to agents reusing the same identity as user)?

Is it that agents have their own certificates? Does that mean that in order to share a document, I would have to share it with a user (using their webid), but also share it with all of the user's agents individually?

[dmitrizagidulin]

Ohhh ok, makes sense now.

The Agent (agent#webid on behalf of alice#webid) bit seems perfectly reasonable to me.