- From: <henry.story@bblfish.net>
- Date: Fri, 21 Nov 2014 19:06:47 +0100
- To: Anders Rundgren <anders.rundgren.net@gmail.com>
- Cc: Sandro Hawke <sandro@w3.org>, public-webid <public-webid@w3.org>
> On 19 Nov 2014, at 06:27, Anders Rundgren <anders.rundgren.net@gmail.com> wrote: > > On 2014-11-19 03:42, Sandro Hawke 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. > > There are non-US markets where certificates are used for everyday chores > like on-line banking. These services rarely offer a poor UX and that's > because they don't rely on the built-in browser PKI client; they roll their own. > > A problem arises when you mention this (easy to verify fact) to US-based > vendors like Microsoft; they don't see it as their job fixing it. > > Anyway, the custom PKI clients are approaching EOL since the "plugin" > concept is about to be removed from browsers. This is a very good > thing because now this issue will finally get the attention it always > deserved which is proved by this quite recent contribution from Microsoft: > https://www.w3.org/2012/webcrypto/wiki/images/d/dd/CertAndKey_Management_Requirements_for_WebCrypto_microsoft.pdf > > Whatever comes out though I don't think it will have any impacts on > TLS, it will likely operate on a higher level like WebCrypto. Once WebCrypto is shipped with browsers it should be possible do a WebID authentication with it. > > -- Anders > >> >> -- 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 Friday, 21 November 2014 18:07:16 UTC