- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Wed, 19 Nov 2014 06:27:44 +0100
- To: Sandro Hawke <sandro@w3.org>, public-webid <public-webid@w3.org>
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. -- 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. >>>> >>>> >>> >> >> >
Received on Wednesday, 19 November 2014 05:28:18 UTC