- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Tue, 03 Jan 2012 10:33:16 -0500
- To: Mo McRoberts <mo.mcroberts@bbc.co.uk>
- CC: public-xg-webid@w3.org
On 1/3/12 10:18 AM, Mo McRoberts wrote: > On 3 Jan 2012, at 15:12, Kingsley Idehen wrote: > >> On 1/3/12 10:06 AM, Mo McRoberts wrote: >>> On 3 Jan 2012, at 14:32, Kingsley Idehen wrote: >>> >>>> On 1/3/12 9:21 AM, Mo McRoberts wrote: >>>>> I can't actually parse most of this e-mail. Sorry. >>>>> >>>>> Kingsley, can you provide some pseudocode or _something_ which explains in a step-by-step fashion how you think an end-user and verifier should deal with this? >>>> End-user: make a new certificate and update the WebID idp space. >>> The point was: you don't have access to that space. Now what? >> The point is: it doesn't matter. You have lost access to Blgospot or some other place to which a URI resolves, so what? You make a new certificate with pointers to a new idp space. In said space you make your claims. You visit a protected resource scoped to you old name, the verifier de-references pointers, and if smart, with comprehend the equivalence claim in the graph and understand this is the same referent. > You need to be a little more clear about “with comprehend the equivalence claim in the graph and understand this is the same referent”. Are you assuming the new certificate is signed by the same key as the original was (which I suggested right at the beginning of this thread as a solution)? No I am making no assumption about private keys. The only thing that's pivotal to WebID are the "mirrored claims" . Remember, losing a computing device that holds my private key has no impact on WebID verification since a relation deletion (in idp space) nullifies its effects. Everything is about the Names and their relations, mirrored across the Cert. in the local key store and the relations graph in the idp space. > This does come with the caveat that the verifier stored the key in the first place. Caching and invalidation schemes are part of the deal re. AWWW. Our proxy URIs are cached and subject to cache invalidation rules when used in SPARQL queries, for instance. I believe the easy path to understanding my point is to think about accessing a protected resource where the ACLs are based on a URI you no longer control. How do you make the claim: I am the same referent albeit for a URI based Name for which I've lost control? Kingsley > >> You make a certificate with a WebID watermark. That's part one. You persist your claims to an Idp space. That's part two. A verifier de-references pointers into a graph that describes subjects by name. This space can also have relations for expressing equivalence by Name or Values. Its up to a verifier to handle this semantic fidelity. >> Kingsley >> >>>> Verifier: understand the semantics of owl:sameAs relations. Implement with an understanding of implications by having the option to only process such claims when they are signed. >>>> >>>> Note: >>>>> 1 URI based Name in the subjectAlternativeName slot implies (semantically) that all the Names have the certificate's Subject as their a co-referent . >>>> The WebID protocol is driven by looking up the existence of "mirrored relations" across a certificate in a local keystore and a description graph in an idp space. >>>> >>>> The *meaning* of a relation is determined by the semantics of the predicate (attribute) that associates a subject (entity) with an object (value). OWL is a powerful vehicle for expressing and exploiting relation semantics . >>>> >>>> >>>> Kingsley >>>> >>>> >>>>> On 3 Jan 2012, at 13:52, Kingsley Idehen wrote: >>>>> >>>>>> 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. >>>>>>> >>>>>> -- >>>>>> >>>>>> 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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> -- >>>> >>>> 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 >>>> >>>> >>>> >>>> >>>> >>>> >> >> -- >> >> 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 >> >> >> >> >> -- 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 15:36:08 UTC