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

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.

Can you not already see that via proxy URIs the description graphs are 
completely mobile? Peter can yank his claim graph out of URIBurner and 
put it somewhere else knowing the public key to WebID association is 
intact. He can put it wherever he seeks as long as he has CRUD rights in 
the new space. If a claim is signed and its matching X.509 cert. is 
still in Peter's possession, what's the problem? The graph that carries 
the mirror of his X.509 cert. goes wherever he next situates it.

Maybe I am not being clear about the proxy role of our particular 
verifier or the abilities of our middleware as demonstrated by the 
URIBurner instance (should someone else seek to leverage this 
functionality). Also, I've also made clear the fact that SPARQL 
endpoints can themselves be WebID secured since the endpoint is a 
facilitator for URL construction.

At this juncture I am going to let someone else attempt to explain what 
I am trying to articulate, or just wait until I can just setup a life 
cycle demo using our technology at each stop due to limitations in other 
verifiers re. owl reasoning and signed claims. Also note you cn or even 
sign entire graphs,  or sign graphs that are themselves ACL constrained 
by the WebID verification protocol.

Since what I am referring to doesn't stand a chance in hell of making 
the spec (not that I've requested this), I am better served making a 
demo with Peter or I end up knocking one up myself.

In response to Henry's comment:

  "yes. There is something there but it clearly needs to be fleshed out, 
as there are so many ways it can be done badly. For example say I loose 
my key, in at http://bblfish.net/ and remove it from there, but the 
thief of my private key goes and puts in on http://surpeticious.com/#me 
and signs the claim there. " .

How is that different from losing any device that holds you key re. WebID? You fix the relation. Remember, you are anticipating that the following happen in tandem:

1. You lose control of a URI (booted out of some system)
2. You also lose your private key or a .p12 with your cert and key
3. Thief then imports .p12, masquerades as you.

In the scenario above, your cost-benefit analysis will lead you to nuking the relations in your Idp space. Or making a new signed statement with your new key about equivalence. 	Remember, your Idp space should challenge you when making these claims.


Bottom line here, we either have a WebID exploit via owl:sameAs or powerful lock-down. I know we have powerful lock down when you leverage refification and WebID based verifications of claims made in idp space. Thus, it still ultimately boils down to a life cycle demo, one that will emerge from Peter's exploits or one I'll knock up myself in the very worst case.

Yes, it needs to be fleshed out for broader clarity, which I guess is what Mo is seeking too. Thus, we have an action item along those lines re. effects of OWL reasoning, statement reification (which includes statement signing), and graph signing on the WebID verification protocol.


-- 

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