Solid Cookies

solidcookies.md

Solid Cookies (aka WebID Tokens)

Introduction

• Solid cookies are a web analogy to browser cookies, which are shared information between a browser and an origin (web site), often used to authenticate or store state information.

• Instead of storing the cookie in your browser, you store it in a trusted and location that only the origin and the user have access to.

• In this way the origin can have confidence that the user of the browser, is verified as the webid, because they have shown that they have permission to write to that space.

Protocol

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

Notes

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

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

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 inferred (eg by following a webid) or signed

Issues

The app still has to know the identity of the user before sending the request. This could be done by :

• typing it in
• having it in the query string
• saving it in localStorage
• auto completing a form, using the upcoming
• Credential Management Level 1
• finger printing.

seeAlso

https://github.com/read-write-web/SoLiD/wiki/Storing-an-Apps-Public-Key

I think at this point "token" is considered a better term for this kind of nonce than "cookie"

Also, yeah, "Location" isn't great. Maybe "Token-Location".

What stops Mallory from pretending to be Alice by find some suitable page on Alice's site, and then sending that as her Token-Location? In other words, what exactly does Bob have to confirm to avoid such attacks? (Probably something like a link from Alice's webid to her folder of these bearer tokens.)

Very good point about Mallory.

This is the same problem as verifying who sent something to an inbox, which one day I think we'll have to solve.

Simplest solution is yes a relation from webid -> profile/cookie/

But equally could be done if signed, if the server confirms the author of the file or if it's in a place only alice can access...

I'd be inclined to call this WebId-Token. It seems to stand next to WebId-TLS and WebID-RSA in functionality, but uses bearer tokens instead of crypto.

Makes sense!

I took the liberty of calling them that in my summary chart https://gist.github.com/sandhawke/bf5f0c7733050fd1b11b

Updated

I find the :origin property a bit confusing here, maybe :audience would be better?