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

On 10/9/12 6:56 PM, Nathan wrote:
> 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.

Yes, but via inference (re. owl:sameAs relationship semantics) you can 
infer that two WebIDs share a common referent i.e., they denote the same 
entity. Of course, the WebID in the x.509 cert. is part of any such claim.

>
>> 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.

Yes, but in an owl:sameAs relationship the URI won't be changing its the 
implications that change :-)

Reasoning and inference context (e.g., in a SPARQL query)  is an issue 
here, ultimately it needs some kind of caution in the specs.

Kingsley

>
> Best,
>
> Nathan
>
>


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen