Re: Simple Page-Owner Token (SPOT) Authentication

On 19 November 2014 04:09, Melvin Carvalho <melvincarvalho@gmail.com> wrote:

>
>
> On 19 November 2014 03:49, Sandro Hawke <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> 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.
>> This is what webintents did, I believe.
>>
>
> I like this idea.  How about webizen fused with a 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/

[[
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.
>>>
>>>
>>>
>>
>>
>