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

Re: Simple Page-Owner Token (SPOT) Authentication

From: Sandro Hawke <sandro@w3.org>
Date: Wed, 19 Nov 2014 10:32:36 -0500
Message-ID: <546CB814.8090308@w3.org>
To: Melvin Carvalho <melvincarvalho@gmail.com>
CC: public-webid <public-webid@w3.org>, public-rww <public-rww@w3.org>
On 11/19/2014 09:26 AM, Melvin Carvalho wrote:
>
>
> On 19 November 2014 04:09, Melvin Carvalho <melvincarvalho@gmail.com 
> <mailto:melvincarvalho@gmail.com>> wrote:
>
>
>
>     On 19 November 2014 03:49, Sandro Hawke <sandro@w3.org
>     <mailto:sandro@w3.org>> wrote:
>
>         On 11/12/2014 05:47 AM, Melvin Carvalho wrote:
>>
>>
>>         On 12 November 2014 05:36, Sandro Hawke <sandro@w3.org
>>         <mailto:sandro@w3.org>> 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.
>>
>>
>>         Sando, could you outline which part of certificate support
>>         you feel could be improved?  Is it the UI, or lack or
>>         coverage, or something else?
>>
>
>         UI, as in previous email
>
>>         Surely SPOT would require browser modification to work in the
>>         browser?
>>
>
>         Mostly, no.
>
>>         - How does the browser send header fields?  -- maybe AJAX
>
>         Of course.
>
>>         - How does the browser remember your URI, esp. cross origin?
>>         -- maybe stuff it somewhere like in web crypto
>
>         This bit is tricky, yeah.   Of course it doesn't really need
>         to remember it, but the user experience is much better if it
>         does. Browser support would be nice.  Without it, we can hack
>         it with a tiny bit of code which uses local storage, served up
>         from some neutral domain like w3.org <http://w3.org>. This is
>         what webintents did, I believe.
>
>
>     I like this idea.  How about webizen fused with a w3.org
>     <http://w3.org> cookie?
>
>     There was a semi centalized web 2.0 auth system that did something
>     similar and was popular at one time, anyone recall the name ...
>     something like xauth
>
>
> Here it is:
>
> https://web.archive.org/web/20120521151833/http://xauth.org/info/

Thank you very much for the reference.

Full details on the pros and mostly cons of that approach at (and linked 
from) 
http://hueniverse.com/2010/06/05/xauth-a-terrible-horrible-no-good-very-bad-idea/

Personally I see it as a viable experimentation and transition 
strategy.    Once it's more clear what we really need, browsers can 
implement it.

     -- Sandro

>
> [[
> What is XAuth?
>
> XAuth is an open platform for extending authenticated user services 
> across the web.
>
> Participating services generate a browser token for each of their 
> users. Publishers can then recognize when site visitors are logged in 
> to those online services and present them with meaningful, relevant 
> options.
>
> Users can choose to authenticate directly from the publisher site and 
> use the service to share, interact with friends, or participate in the 
> site's community. The XAuth Token can be anything, so services have 
> the flexibility to define whatever level of access they choose.
>
>
> Benefits
>
> For site publishers, the multiple HTTP requests necessary to recognize 
> every potential online service are slow and inefficient. XAuth 
> provides a central domain (http://xauth.org) with a lightweight 
> JavaScript library that can be accessed via a single HTTP request.
>
> Users are often presented with many social services when browsing a 
> site. They likely only are interested in one or two. XAuth allows the 
> user experience to be immediately relevant, so that they can easily 
> access the services that are useful to them.
>
> Service providers participating in XAuth can reach their existing 
> userbase anywhere on the web without being buried in the deluge of 
> other social services that may be available and competing for space on 
> the publisher site.
>
> The service providers have complete control over the features they 
> enable for the publisher site. The XAuth Token could be a single bit 
> denoting the existence of an authenticated user, or it could be a 
> session ID that passes public profile info via API calls from the 
> publisher.
> ]]
>
>
>     I use the local storage pattern too, but it's not cross origin,
>     and especially painful with subdomains ...
>
>
>>         - How does the browser and your server maintain a shared
>>         secret? -- maybe HTTPS
>
>         That's what the SPOT spec says, yes.
>
>>         Are you not replacing one set of problems with another?
>>
>
>         Not that I can tell, of course I might be missing something.
>
>>         Would it maybe be an idea to focus on mockups and a design
>>         for a better UX with an extension?
>
>         Why don't you talk to the browser vendors and see how willing
>         they are to improve the client cert UI, even if you offered
>         all the necessary code patches or funded their engineers to
>         work on it.   (I'm quite serious about this; others have
>         reported hitting dead ends.   Honestly, I haven't tried it,
>         myself.)
>
>               -- Sandro
>
>
>>
>>                    -- 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 15:32:44 UTC

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