- From: <henry.story@bblfish.net>
- Date: Wed, 19 Nov 2014 09:29:23 +0100
- To: Sandro Hawke <sandro@w3.org>
- Cc: Anders Rundgren <anders.rundgren.net@gmail.com>, public-webid <public-webid@w3.org>
> On 19 Nov 2014, at 03:42, Sandro Hawke <sandro@w3.org> wrote: > > On 11/12/2014 01:01 AM, Anders Rundgren wrote: >> On 2014-11-12 05:36, Sandro Hawke wrote: >>> On 11/10/2014 06:39 AM, Melvin Carvalho wrote: >>>> Just wanted to highlight this interesting work from sandro >>> >>> Thanks. I should say the design came out of discussions with Andrei Sambra, >> > trying to avoid the problems with poor browser support of client certificates. >> >> Sandro, that's a very interesting statement since the W3C is just about to launch >> a continuation of WebCrypto which indeed may be focused on certificates and browsers! >> > > I'm just speaking for myself as a user and software developer; I'm not involved in that W3C work. My feeling is the UX is terrible. My understanding is the only people who ever use it are people without a choice, like enterprise employees and university students. What fraction of consumer websites use client certs for user authentication? I've never seen one. I think that's because the UX is so bad. Are you using Firefox, or are you on Unix? The UIs suck really bad there on the whole. But on commercial OS' the situation is pretty reasonable. ( OSX is too minimalistic, and this creates a problem of privacy.) We have a bunch of screenshots for the selection box on other OSs here: http://www.w3.org/wiki/Foaf%2Bssl/Clients/CertSelection Don't get mislead by your choice of OS. Henry > > -- Sandro > >> Anders >> >> >>> >>> -- Sandro >>> >>>> >>>> https://github.com/sandhawke/spot/blob/master/spec.md >>>> >>>> This document specifies an HTTP authentication mechanism suitable for use in situations where the HTTP client is tightly coupled with another HTTP server. It is very easy to implement and requires no extra crypto. >>>> >>>> For illustration purposes, we'll say Alice is a process which serves the web resource at http://alice.example/alice and wants to act as a client to access a protected resource http://bob.example/bob, which is served by a different process, Bob. >>>> >>>> For non-trivial use, to provide some resistance against attackers who can view or intercept network traffic or subvert the DNS, HTTPS URIs should be used, and clients should check that the server DNS name matches the certificate. >>>> >>>> >>>> Status >>>> >>>> Not yet implemented. >>>> >>>> Before wide deployment, the new authentication type Page-Owner-Token and the two new HTTP headers (Page-Owner-Token-Check and Page-Owner-Token-OK) should be registered with the IETF. >>>> >>>> >>>> Walkthrough >>>> >>>> *Step 1.* Alice performs an HTTP GET on an access-controlled page served by Bob, but does not authenticate herself, so Bob returns a 401 error. The response includes a header telling Alice she can authenticate using this protocol and try again. >>>> >>>> |> GET /bob HTTP/1.1 >>>> > Host: bob.example >>>> ... >>>> < HTTP/1.1 401 Authorization Required >>>> < WWW-Authenticate: Page-Owner-Token >>>> ... >>>> | >>>> >>>> This uses the standard WWW-Authenticate HTTP header with a new keyword for this new authentication type. >>>> >>>> *Step 2.* Alice generates a cryptographicly random token, a nonce. In this example, I'll write it as xyz123. It should use only the Base64 characters. >>>> >>>> *Step 3.* Alice repeats the GET, this time including a header which identifies her via a web page and includes the nonce: >>>> >>>> |> GET /bob HTTP/1.1 >>>> > Host: bob.example >>>> > Authorization: Page-Owner-Token client="http://alice.example/alice" token="xyz123" >>>> ... >>>> | >>>> >>>> ISSUE: Should it just be http://alice.example/ ? What does it mean to include the /alice? >>>> >>>> Alice can include multiple headers like this, since it might be that only one of her multiple identies actually has access to /bob and she doesn't now which. The identity strings must be dereferenceable. They can be either an Information resource IRI (returning 200 OK) or a non-information resource IRI (returning 303, or having a hash). Either works fine for this protocol. >>>> >>>> Note that sending identity strings like this may reveal more to Bob than desirable. >>>> >>>> *Step 4.* Bob checks to see if the request provides a valid token: >>>> >>>> |> HEAD /alice HTTP/1.1 >>>> > Host: alice.example >>>> > Page-Owner-Token-Check: token="xyz123" relying-party="http://bob.example/bob" >>>> ... >>>> | >>>> >>>> The verb could be GET (instead of HEAD) if the Bob is interested in the content of /alice. >>>> >>>> *Step 5.* Alice confirms: >>>> >>>> |< HTTP/1.1 200 OK >>>> < Page-Owner-Token-OK: true >>>> < Set-Cookie: [whatever, optional] >>>> ... >>>> | >>>> >>>> Alice only does this if the token was in fact the one she generated for her GET to Bob. >>>> >>>> Only a response containing the header "Page-Owner-Token-OK: true" is taken as confirmation. >>>> >>>> The Set-Cookie is an optional shortcut. With this cookie, Alice can give Bob some secret to use in future communications, so that Bob can act as an HTTP client accessing alice.example in the future without needing to go through his own SPOT handshake. >>>> >>>> *Step 6.* Bob returns the protected content requested in Step 3 >>>> >>>> |< HTTP/1.1 200 OK >>>> < Set-Cookie: [whatever, optional] >>>> ... content ... >>>> | >>>> >>>> The Set-Cookie is an optional shortcut. With this cookie, Bob can give Alice some secret to use in future communications, so that Alice and Bob do not have to repeat this handshake every time. >>>> >>>> >>> >> >> > > Social Web Architect http://bblfish.net/
Received on Wednesday, 19 November 2014 08:29:53 UTC