- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Tue, 5 May 2020 09:34:44 +0200
- To: Martynas Jusevičius <martynas@atomgraph.com>
- Cc: public-webid <public-webid@w3.org>
- Message-ID: <CAKaEYhJYLTjyOt8zmGBqEH0jZL-NRCFgEyWNdP+L8Yc0Li_HWw@mail.gmail.com>
On Tue, 5 May 2020 at 00:48, Martynas Jusevičius <martynas@atomgraph.com> wrote: > WebID-TLS does not require a cookie. > It doesnt. But it can give you a cookie. Just like TLS doesnt require a shared secret, but it can give you one after the public/private key hand shake. > > On Tue, 5 May 2020 at 00.14, Melvin Carvalho <melvincarvalho@gmail.com> > wrote: > >> Was chatting to Kingsley and Dmitri lately and I realized that quite >> often WebID over HTTP is authenticated via a shared secret. Namely a >> cookie. >> >> We realized that this is not documented anywhere. And I asked dmitri >> about it usage. Im just capturing the responses here. >> >> "I think all Solid servers use cookies (and store the WebID in the cookie >> session) as a local authentication method, in addition to TLS and OIDC. >> It's very convenient; the only reason it's not the main mechanism is of >> course, it's domain-specific." >> >> and >> >> "I don't think it's written up anywhere. I think it's because each >> implementation's cookie session mechanism is slightly different. >> But usually, it goes like: >> >> 1. When a user logs in (via username and password, or TLS, or OIDC >> token), you put their WebID in your session. (request.session.webId = >> <user's authenticated webId>) >> 2. In all the other requests, you just use request.session.webId directly. >> >> And the server's (Express.js, or whatever the other ones are using) >> session cookie store takes care of it." >> >> This actually might be one of the more common types of WebID auth. >> >> Would it be worth writing up, and should it be called: >> >> WebID + Cookie or >> WebID + Shared Secret? >> >
Received on Tuesday, 5 May 2020 07:35:08 UTC