W3C home > Mailing lists > Public > public-webid@w3.org > June 2017

Re: WebKey - was: WebID-protected WebID document

From: Henry Story <henry.story@bblfish.net>
Date: Wed, 21 Jun 2017 20:54:56 +0200
Cc: public-webid <public-webid@w3.org>
Message-Id: <182D6FFF-F420-4C6D-A729-AA4650A76C7E@bblfish.net>
To: Martynas Jusevičius <martynas@atomgraph.com>

> On 21 Jun 2017, at 19:02, Martynas Jusevičius <martynas@atomgraph.com> wrote:
> 
> Thans for the reply. I think the protocol is quite clear as it is, but it should avoid adding any extra lookups or requests, which would impact performance negatively.
> 
> I saw the requirement for WebID document to be 'public'. But I think there are 2 types of 'publicness' here that could be clarified.
> 
> Making the document public in ACL is easy, but it's not enough.
> 
> Because on the SSL level, the client must not authenticate with a (WebID) certificate when requesting an internal WebID, otherwise it will get into a loop.

You mean the server must not authenticate....
I am not sure what you mean by "an internal WebID" 

> 
> Which has the implications that for internal requests: 1) 2 types of HTTPS clients need to be available, one that sends a WebID certificate and one that doesn't 2) the server (or at least the URI space of WebID documents) has to 'want' a certificate and not 'need' it.

Section 4.2.4 does have some text on WANT vs NEED
https://www.w3.org/2005/Incubator/webid/spec/tls/#requesting-the-client-certificate
[[
As much as possible it is important for the server to request the client certificate in WANT mode, not in NEED mode. If the request is made in NEED mode then connections will be broken off if the client does not send a certificate. This will break the connection at the application protocol layer, and so will lead to a very bad user experience. The server should therefore avoid doing this unless it can be confident that the client has a certificate - which it may be because the client advertised that in some other way to the server.
]]

> 
> This was a concern for us because the system is doing a lot of internal loopback requests. Did I manage to explain it? :)

You need to explain what you mean by internal WebID request and internal loopback request

> On Wed, 21 Jun 2017 at 17.58, Henry Story <henry.story@bblfish.net> wrote:
> 
>> On 21 Jun 2017, at 10:55, Martynas Jusevičius <martynas@atomgraph.com> wrote:
>> 
>> Hi,
>> 
>> I've started implementing the WebID Authentication Protocol.
>> 
>> I extract the WebID URIs from certificates and try to look them up and verify -- so far so good.
>> 
>> But, since the WebID URIs are local to my system, and the whole system is protected by WebID, it means that WebID URIs themselves are protected by WebID. This leads the Guard/Verifier into an eternal loopback.
>> 
>> WebID 1.0 says both that WebID documents should be public and served over HTTPS.
>> 
>> The only way to achieve that that I can see is for the Verifier to dereference WebID document over HTTPS but without sending a client certificate. Which also means that the server's clientAuth has to be configured as 'want' rather than 'need' (and naturally the ACL has to be configured to allow public access to WebID).
>> 
>> Are my assumptions correct? Maybe this should be clarified in the protocol spec?
> 
> yes, the WebID Profile document should be public to avoid the problem - as specified in the spec.
> 
> One could place the key in another document, and have a URL point from the WebID profile to the other key. 
> 
> <#me> cert:key <key#>
> 
> But then we would also need to change some other things to the protocol. Firstly of course because the 
> Subject Alternative Name in the X509 certificate contains the WebID, not a Key URL. And there would
> be no way for the client to find out the key URL unless that is also added to the certificate - which would
> be a not insubstantial piece of work to standardization work.
> 
> On the other hand it would make sense to work on a new spec to incorporate HTTP-Signature to WebID.
> I implemented this in Scala-JS (Scala compiling to JS) 1 and a half years ago and left some notes 
> on my experience and pointers to the code here
>   https://github.com/solid/solid-spec/issues/52
> 
> This protocol works by giving the key a URL, and it works at the HTTP level, which is good.
> But one would need to work out the details of how one can tie it to a WebID, to allow social
> networking information to be shared. ( I think I wrote some thoughts down on that topic there)
> 
> Henry
> 
>> 
>> 
>> Martynas
>> atomgraph.com
> 
Received on Wednesday, 21 June 2017 18:55:32 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 21 June 2017 18:55:33 UTC