- From: Sandro Hawke <sandro@w3.org>
- Date: Wed, 19 Nov 2014 10:32:36 -0500
- To: Melvin Carvalho <melvincarvalho@gmail.com>
- CC: public-webid <public-webid@w3.org>, public-rww <public-rww@w3.org>
- Message-ID: <546CB814.8090308@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:45 UTC