W3C home > Mailing lists > Public > public-xg-webid@w3.org > January 2012

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

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Tue, 03 Jan 2012 08:52:57 -0500
Message-ID: <4F030839.5080403@openlinksw.com>
To: public-xg-webid@w3.org
On 1/3/12 7:09 AM, Mo McRoberts wrote:
> On 2 Jan 2012, at 19:42, Kingsley Idehen wrote:
>>> It works *IF* you've made those claims in advance of losing access to your “old” URI, but doesn't if you haven't — OWL alone can't help you because you can't mirror the claim.
>> Again, let's not speculate and argue endlessly. Do a real test with a simple resource to which a WebID based ACL is applied.
>> This is about routing and data access exposed via identifiers in a certificate combined with verifiers that understand OWL semantics. A statement doesn't maketh OWL semantics, you have to implement the semantics in a system for the statement to have a modicum of value.
> No. This is not “speculating and arguing endlessly”. It has nothing (besides a tangental relationship) to do with ACLs, and very little to do with OWL.

That's incorrect. If you make statements like that then consider WebID's 
protocol utterly meaningless too. You don't selectively apply semantics. 
The whole deal here boils down to semantically rich relations that are 
machine comprehensible.

> Real-world tests are unhelpful because this is about how things are _supposed_ to behave, not documenting how prototypes actually DO — this is not an exercise in scientific discovery, but in decision-making. (And also, to be honest, it’s a matter of the basic principles of WebID’s operation when it comes to confirming “authority” to the WebID URI).

You don't achieve that goal without semantics, relations, decidability, 
and data structures.
> This boils down to how WebID consumers are SUPPOSED to behave when you lose the ability to publish resources at the URI your certificate bears (and so are unable to mirror the claim), what happens to the data held by those consumers (i.e., your profile/account data, including confirmed relationships with other people), and what end-users are supposed to do to mitigate any of it.

Sorry, but that's an over simplification.

> The answer may to publish a synonym claim, via both OWL and SAN, *before you lose access to the original WebID URI* and then go through every consuming service that you use poking them to pick up the updated document so that they know about your additional URI.

I get thrown out of Blogspot, I make a new certificate, that includes a 
pointer to data (a graph pictorial) in one of my  idp spaces that 
includes an assertion that my new URI based name is in an equivalence 
relation (by name) with my old URI based name.  OWL semantics simply 
provide machine comprehensible relations for equivalence by name. A 
reasoner that's part of a WebID verifier can do this.

Does the above have to be mandatory re. spec? No.
Does the spec need to include comments about the conceptual implications 
of equivalence by name? Yes.

Do I have a verifier that can do this today? Yes, it's been so since we 
implemented our first verifier. In short, we don't even need URIs in SAN 
at all with our verifiers if you have URLs in the CN, as per my earlier 
comments in the thread with Henry.

Ultimately, WebID (the spec) is better off at this stage taking its 
simplistic baby steps. When there are more real applications (beyond 
ours which have been waiting for years) out in the field the realities 
of what Peter and I are going on about will manifest.

Equivalence fidelity always matters. And OWL semantics aren't trivial.

> As the spec stands right now, there is nothing which provides a way for the previous holder of a URI to state that their new URI is elsewhere without doing so *in advance* of losing the ability to publish to that original URI.

Again, users can make many certificates with many Names in SAN. The 
claims in the idp space matter, and they are subject to the processing 
prowess of a verifier. You can't spec the dexterity of a verifier, you 
can only spec what should be the minimum capabilities of a verifier.

>   If you allow them to do it after the fact, then unless you pay attention to something else as the key piece of identifying information (e.g. they have authenticated with the same private key has previously), then there's nothing stopping somebody *else* coming along and presenting a certificate bearing a new URI which uses OWL to claim it's the same as that original one and gaining access to all of your data.

If that were to be true, why would I have also singled out misuse of 
owl:sameAs semantics as the way to break WebID? Of course a verifier 
that is OWL aware also needs to bear in mind the dangers of a union that 
associates a single public key with potentially unrelated WebIDs. Its 
the very reason why I say: you have to sign the claims in the idp space 
or do a blob match etc..

This problem is can be solved, but we shouldn't trivialize the power of 
OWL reasoning and the capabilities implicit in saying exactly what you 
mean via triple based statements courtesy of the the underlying 
semantics of said relations. This is what the Semantic Web (beyond 
Linked Data) is all about.

> M.



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 13:53:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:54 UTC