Re: How To Handle WebIDs for (X)HTML based Claim Bearing Resources

On 1/3/12 5:37 PM, Mo McRoberts wrote:
> On 3 Jan 2012, at 22:08, Kingsley Idehen wrote:
>
>> On 1/3/12 2:48 PM, Mo McRoberts wrote:
>>>> When you sign the claim a verifier can apply WebID logic to it. Especially, when it already has record of your prior claim. This is what a proxy URI enables i.e., cache of prior claims (URI and Public Key relations) in an Idp space to which you have CRUD privileges.
>>>>
>>>>> <my-URI>   owl:sameAs<http://kingsley.blogspot.com/>
>>>>>
>>>>>
>>>> Will not work in this scenario. Where is the proof? The relation is<my-URI>   and a Public Key equivalent to<my-New-URI>   and a Public Key, in my idp space. It isn't just about the statement. There is a context to which these equivalence semantics are being applied.
>>>>
>>>>>
>>>> Again, I am not mandating owl:sameAs without context of WebID. I am saying, in a nutshell, sign the owl:sameAs claim when its made in idp space. WebID lets you verify claims.
>>>>
>>> Sign it with WHAT? You've said the key in the cert has no impact. A newly minted key? Well, I (the attacker) can sign using a key *I*
>>>   have just generated.
>>>
>>>
>>>
>>>
>> I am saying the key is not the be all and end all. It the relations that matter. Your question is akin to asking: why do you need a composite key when each component of the key has unique identity and functionality in its own right.
> RIGHT, so you do in fact sign the new claim (the owl:sameAs) with the key that you used previously.

Yes.

>
> Which is what I said previously. And a multitude of times subsequently. Each time to be met with a different obfuscated answer.
>
> This is like pulling teeth.

Why I prefer live demos re. these kinds of fiddly matters. Peter is 
exposing issues and contexts that make it a little easier for me. 
Imagine trying to articulate the power of a SPARQL CONSTRUCT URL 
(shortened via a URL shortener too)  in the CN of a cert. modulo his 
experiments, it would be worse that pulling teeth :-)

Peter has created context for killing one of the biggest problems of all 
re. WebID as Linked Data exploitation vehicle via his experiments which 
set context for understanding why SAN can have Names that do not resolve 
if the CN holds the profile address (which leverages URL abstraction).  
There is nothing more problematic to any kind of Linked Data 
exploitation than the Name / Address disambiguation matter that arises 
with HTTP URIs re. httpRange-14 imbroglio.

>

-- 

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

Received on Tuesday, 3 January 2012 22:52:31 UTC