Re: Authentication Proposal -- Solid Cookies

does the proposal provide a verifiable claim?

can the cookie be copied?

why not use a http-signature?

where is the data about alice? is it on a 'server' or 'client'?

or is the identity provided by alice to bob stored on alices client?

if client, i'm not sure whether NAT/dynamic IP's or similar confuses things
further?

or does is the cookie for the session rather than the client?

also, multi-device considerations with respect to user experience?

On Fri, 5 Feb 2016 10:54 PM Melvin Carvalho <melvincarvalho@gmail.com>
wrote:

> On 5 February 2016 at 12:49, Kingsley Idehen <kidehen@openlinksw.com>
> wrote:
>
>> On 2/5/16 6:07 AM, Melvin Carvalho wrote:
>>
>> Alice wishes to authenticate on Bobs server.
>>
>>    1. Alice sends her User: identity, and (optionally) a path to a
>>    "cookie". The cookie is a resource that only Bobs server and Alice have
>>    access to. The contents of the resource are a typical cookie with
>>    unguessable string and expiry.
>>    2. Bob's server compares the string sent from the browser and the
>>    string in the file. If they match access is granted.
>>
>>
>> Any comments on this idea?
>>
>>
>> How do Alice and Bob create this cookie?
>>
>
> Alice creates it.  Using HTTP PUT of a random string in JavaScript.
>
>
>> How do that control access to said cookie?
>>
>
> Same way as usual using WebAccessControl.
>
>
>> How many cookies come into existence as the contact network membership of
>> both individuals grows?
>>
>
> One per origin, but they can be deleted.  Just like your cookies folder in
> the browser.
>
>
>>
>> --
>> Regards,
>>
>> Kingsley Idehen 
>> Founder & CEO
>> OpenLink Software
>> Company Web: http://www.openlinksw.com
>> Personal Weblog 1: http://kidehen.blogspot.com
>> Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
>> Twitter Profile: https://twitter.com/kidehen
>> Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
>> LinkedIn Profile: http://www.linkedin.com/in/kidehen
>> Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this
>>
>>

Received on Friday, 5 February 2016 12:05:45 UTC