-
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.
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
- periodically tokens can be managed or deleted or have an expiry
- 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
- 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
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.
https://github.com/read-write-web/SoLiD/wiki/Storing-an-Apps-Public-Key
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...