W3C home > Mailing lists > Public > public-credentials@w3.org > February 2016

Fwd: Authentication Proposal -- Solid Cookies

From: Timothy Holborn <timothy.holborn@gmail.com>
Date: Tue, 09 Feb 2016 10:43:56 +0000
Message-ID: <CAM1Sok3+ZiTRqMYjQTdkunC0srFkgoFEN7D9s7HaVk-8BsX6Ag@mail.gmail.com>
To: W3C Credentials Community Group <public-credentials@w3.org>
FYI.

---------- Forwarded message ---------
From: Melvin Carvalho <melvincarvalho@gmail.com>
Date: Tue, 9 Feb 2016 at 9:39 PM
Subject: Re: Authentication Proposal -- Solid Cookies
To: public-rww <public-rww@w3.org>, public-webid <public-webid@w3.org>


On 5 February 2016 at 12:07, Melvin Carvalho <melvincarvalho@gmail.com>
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?
>

Ive renamed this proposal to WebID Tokens:

<https://gist.github.com/melvincarvalho/423100dcfac9d19677b8#webid-tokens-was-solid-cookies>WebID
Tokens (was Solid Cookies)

After getting a 4xx from https://bob.databox.me/<resource> Alice posts a WebID
token to :

1. https://alice.databox.me/profile/tokens/<random>
  <> a :Token ;
  :origin https://bob.databox.me/ ;
  :value random .

2. Alice sends a request to https://bob.databox.me/<resource>
  Token-Location: https://alice.databox.me/profile/tokens/<random>
  User: https://alice.databox.me/profile/card#me
  token: <random>

3. Bob checks https://alice.databox.me/profile/tokens/<random>
   matches the WebID token of so auth is successful else 4xx

<https://gist.github.com/melvincarvalho/423100dcfac9d19677b8#notes>Notes

   - periodically tokens can be managed or deleted or have an expiry

<https://gist.github.com/melvincarvalho/423100dcfac9d19677b8#extensions>
Extensions

   - tokens could be signed
   - instead of a shared secret PKI could be used
   - additional information can be put in the tokens to be used by both
   parties

<https://gist.github.com/melvincarvalho/423100dcfac9d19677b8#security-considerations>Security
Considerations

   - token directory should not be public readable
   - By delegating verification in this way it produces a largely
   undetectable backdoor where a server can impersonate a WebID
   - It is desirable that the verifier has confidence the token resource is
   only writable by Alice or Mallory could imperonate her. Ideally server
   should verify alice wrote the file, if it's not obvious or signed


https://gist.github.com/melvincarvalho/423100dcfac9d19677b8
Received on Tuesday, 9 February 2016 10:44:41 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 July 2018 21:19:27 UTC