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

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/>

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.

-- 
Mo McRoberts - Technical Lead - The Space,
0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E,
Project Office: Room 7083, BBC Television Centre, London W12 7RJ

Received on Tuesday, 3 January 2012 15:51:45 UTC