Re: Simple Page-Owner Token (SPOT) Authentication

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

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