W3C home > Mailing lists > Public > public-webid@w3.org > November 2014

Re: Cert-UX for the n:th time. Was: Simple Page-Owner Token (SPOT) Authentication

From: <henry.story@bblfish.net>
Date: Fri, 21 Nov 2014 19:06:47 +0100
Cc: Sandro Hawke <sandro@w3.org>, public-webid <public-webid@w3.org>
Message-Id: <EB19FEAB-CBDC-45AE-907D-B61F059342A7@bblfish.net>
To: Anders Rundgren <anders.rundgren.net@gmail.com>

> 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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:54:50 UTC