Re: WebID-ISSUE-64 (redirects): Redirects [WebID Spec]

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