Solid Auth

solidauth.md

Options for resolving Issue #22

Scenario: Alice, using her browser, wants to access resources on server bob.example, authenticating herself as the owner of server alice.example (or a specific resource on it, like her WebID graph or profile)

Current solution: use WebID-TLS. But support in the browser has issues (see issue statement), so what are some alternatives?

Basic Approaches

1. Proxy TLS: Alice talks to her pod, while her pod uses WebID-TLS to talk to bob.example. Her secret key remains on her pod.
2. Digital Signatures: Alice signs her request to bob.example using a (non-TLS) private key; bob verifies with public key obtained from alice.example
3. Token Confirmation: A secret bearer token passes through all three parties, confirming to bob.example that the client controls alice.example

Candidates

Candidates	Proxy	Digital Signatures	Token Confirmation
Homegrown Design	TBD	WebID-RSA, HTTP Signatures + ??	SPOT,WebID-Tokens
Community Design	-	-	IndieAuth

Note: I've been unable to find a spec for communicating the public key in http-sig, making it only one component in a solution, not a complete candidate. But I've heard of a demo where Manu used it for logging in, and Henry says he's implemented it, so maybe the spec exists somewhere.

Other:

• EvanP's Dialback I-D, Issues (Abandoned.)
• Wikipedia's list of Single Signon Systems 20-non-proprietary candidates

Comparison

|WebID-RSA|HTTP-Sig|SPOT|WebID-Tokens|IndieAuth ---|---|---|---|---|--- User identifier|WebID|??|Web Page|WebID|Web Page Works in browser with JS off|N|N|N|N|Yes (OAuth Flow) Discovery|GET RDF|??|HTTP Headers|GET RDF|Parse HTML + HTTP Headers Profile can be on static site|Y|Y|N|Y|Y Implementations|-|Digital Bazaar?|-|-|Several in IndieWebCamp Client round trips| Patent Status|

Well, if she owns alice.example she owns every WebID on alice.example, right?

A more typical model is for one server to host multiple webids. For example, facebook own their server, but have repeated stated that users own their own data. Even if we're delegating auth to the server, we should identify as the WebID, right, then let the verifier make that assumption (at their own risk)?

I'm trying to allow for non-WebID-centric solutions (since in all likelihood the industry will settle on a non-WebID solution at some point)

IMHO this is largely speculative, as we cant predict with 100% certainty what will get adopted. The issue with speculation is that we can all do it, we all think we're good at it and most of the time the web surprises us. Facebook implemented WebID quite quickly, and the main auth systems that are commonly used lead to pervasive monitoring and backdoors where servers can impersonate users largely undetected. It seems to me we're in danger of increasing that attack surface with some of these solutions.

However, if there are solutions with widespread adoption right now, we can take them on their merits and see what they add.

"I couldn't log in to Github on my phone. Could someone add as s comment or in the matrix the question as to where the keys are stored, the question of how you stop Mallory building s system which looks just like ours but sends all the secrets to him. Which webid tls solves with browser chrome. " (from timbl)

Fine, I'll refrain from estimating odds. Still I think it's sensible to allow for non-WebID solutions.

What's this about facebook implementing WebID? In what sense?

I've been unable to find a spec for communicating the public key in http-sig

You place the key at the URI of the key the client passes in the HTTPSig header.