- From: Henry Story <henry.story@bblfish.net>
- Date: Tue, 3 Jan 2012 20:58:21 +0100
- To: Kingsley Idehen <kidehen@openlinksw.com>
- Cc: public-xg-webid@w3.org
On 3 Jan 2012, at 18:14, Kingsley Idehen wrote: > On 1/3/12 10:51 AM, Mo McRoberts wrote: >> On 3 Jan 2012, at 15:33, Kingsley Idehen wrote: >> >>> 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" . >> Right. So: >> >> You lose access to Blogspot — there is now nothing WebID or Linked Data-shaped published there (or worse, there is, but it says something different to what you'd published). So, you create a new cert pointing at a new profile document which states that<new-URI> owl:sameAs<http://kingsley.blogspot.com/>. >> >> How is that any different from _me_ creating a cert pointing at a new profile document which states that<my-URI> owl:sameAs<http://kingsley.blogspot.com/> > > 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. Ok so if you want RDF claims to be signed then you bring in something completely new that needs to be fleshed out. It is not clear which claims were signed by whome, or how they were signed. Btw, I think this type of thing is going to be user friendly and feasible when the web cryptography working group has done its work. http://www.w3.org/2011/11/webcryptography-charter.html They were looking for use cases, perhaps it is worth developing a use case that is simple enough so that this can be brought to their attention. You should do this quickly. > 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. 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. >> >> What's the differentiating factor between ME doing it falsely (i.e., attempting to hijack your data stored in verifying parties’ systems) and YOU doing it validly (attempting to maintain access to your identity on those systems)? >> >>> 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? >> That's precisely the query I've been posing all along: how *do* you do that? (Although, in reality, it doesn't have to be an ACL, it's any situation where you wish to identify yourself to a verifying party). You claim to have a solution implemented, but I’m struggling to fathom precisely what it is. > > We leverage cache. For added assurance you can sign each equivalence claim using your WebID, and then verify said statements about statements using WebID. A WebID verifier can make use of cache and cache invalidation schemes. Of course, that isn't mandatory, but its an engineering choice that an implementor can make. One we've made. > > You can have an object/entity that has the properties: subject, predicate, object. Said object (a statement object) can also be endowed with other properties that include a signature, statement hash, and a cert. blob. Reification enables you to construct triples about triples. Thus, I can assert that "I" made a claim about my "Identity" via a given statement. You can even embellish further with provenance oriented terms using a provenance ontology. > > Verifiable recall is part of the deal here albeit an WebID verifier engineering choice. > > Remember, when I loose control over my URI (e.g. blogspot) I don't loose control over the local cert. in my keystore that holds the claims vital to WebID based verification. Thus, for a reified statement, I simply need to prove: > > 1. the claim creator had crud privileges in this idp space -- now with our verifier we have a cache of the WebID and Public key relations > 2. the identity of the claim maker was verified when the claim was made -- a little bit of provenance added to the mix > 3. a signature to that effect associated with the claim . ok. those are the details that were needed. As I mentioned above that does need fleshing out. It would be worth putting up a page on the wiki on it, with pointers to reification/named graph signing, write up the possibilities of what gets signed and consider the various issues that do arise. Now I have recently come to the conclusion that the public key should be considered as one identity (in Java Language a Principal) of the user, when he proves his ownership of the private key. This means that you can re-identfy a user using the public key even before you do web id verification. The identity claim when the webid is verified is then webid owl:sameAs [ key pk ] . When ProfileDoc(webid) is lost then the above verification can no longer take place but one can have webid2 owl:sameAs [ key pk ] . if one trusts that the pk did not come into bad hands one can then deduce that webid == webid2 because :key is inverse functional. So once again the question is how does one trust that the private key did not come into the wrong hands. Those are the type of questions that need to be looked at I think. Henry > >> > > > -- > > 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 > > > > > > Social Web Architect http://bblfish.net/
Received on Tuesday, 3 January 2012 19:58:59 UTC