- From: Nathan <nathan@webr3.org>
- Date: Tue, 09 Oct 2012 23:56:44 +0100
- To: Henry Story <henry.story@bblfish.net>
- CC: Kingsley Idehen <kidehen@openlinksw.com>, public-xg-webid@w3.org
Henry Story wrote: > On 9 Oct 2012, at 20:28, Kingsley Idehen <kidehen@openlinksw.com> wrote: > >> On 10/9/12 1:58 PM, Henry Story wrote: >>> I opened this issue now: >>> https://www.w3.org/2005/Incubator/webid/track/issues/64 >>> >>> Please come up with some text, and help along. It's a difficult issue. >>> >>> We need text for >>> >>> a- what happens when a redirect moves from http to https (security section) >>> b- how to resolve urls in remote documents that were reached by redirects >>> c- whether the WebID itself changes if redirected??? >>> d- a note on reasonable numbers of redirects to follow and pointer to http spec >>> >>> I am not sure I have an answer for c. >> If the WebID changes, and there's no inference in play (e.g., owl:sameAS), it has to be invalid. That's the nature of the underlying semantics of this identity verification protocol. Even with inference, or explicit statements, it has to be invalid. The core protocol consists of a two part key, each part is mathematically tied to the other, and the WebID protocol ties both parts to a URI identifier (private part is tied to the webid-uri via the cert, public part is tied to the webid-uri via dereferencing). Any URI to be used as an identifier for the agent involved in the protocol, must be present at each side, for the protocol to work. That is to say, it must be tied to both key parts, especially the private part. > What would be useful would be some justfication for that statement. > An example would help. Take a WebID > > http://joe.example/#me > > > We dereference > http://joe.example/ > which redirects with 303 to > http://joe.example/people/card > which redirects with 301 to > http://joe.org/people/card > > Does that now mean that > > http://joe.example/#me owl:sameAs http://joe.org/people/card#me ? No such inference is specified anywhere, but anybody is free to infer whatever they want from anything, including a trail of HTTP Requests and Responses, or a set of RDF statements. From a security standpoint, TLS and certificate presentation ties the webid-uri(s) present in the certificate to a private key. To then verify that they are authorised to use a different URI <http://joe.org/people/card#me> (via 30x redirects and/or RDF statements) we would need something returned from that URI to prove the owner of that URI held the private key - something traditionally done by the certificate presentation part of the protocol - and not just the public key, so some hash or signature in the RDF or headers of <http://joe.org/people/card> would help this assertion. Although, without it being a nonce, it'd be open to replay attacks, and of very limited value. Succinctly, as soon as the webid-uri changes, it is no longer bound to the private part, and the webid-protocol is no longer in effect, or proving anything. Best, Nathan
Received on Tuesday, 9 October 2012 22:57:49 UTC