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

On 4 Jan 2012, at 02:09, Kingsley Idehen wrote:

> On 1/3/12 6:43 PM, Henry Story wrote:
>> 
>> 
>> On 3 Jan 2012, at 23:08, Kingsley Idehen wrote:
>> 
>>> 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 onhttp://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. 
>> There are new things to think about since you have introduced another way of verifying an identity.
>> 
>>>  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. 
>> 
>> You may know your IDP, but does a relying party? You are now allowing a signed statement of identity to be made anywhere on the web using your private key. Since you have lost your PersonalProfile page - and this is the case you wish to fix, which is why we are considering it - no Relying Party can access it. They therefore have to take at face value any WebId that claims to be you.
> 
> I don't understand your analysis at all.
> 
> I have a keystore and a cert. I have access to a data space that serves the role of idp and more.

Well you have your profile document and you have this data store. Both produce RDF in some form so there is no way to distinguish them there. So you loose your profile document? How does that differ from the case where you loose your so called IDP? What is the difference?

> I have the ability to make and break relations with alacrity.

Where? In your IDP, which is just a label you put on another server? But what if you loose control of your IDP? there used to be http://openid.sun.com/ which provided open ids for sun. Then they discontinued it. Sun was a large company, and as we have seen recently on numerous occasions the size of a company does not mean much. Even very large companies discontinue products.

> I can use the WebID protocol to verify my claims.

Well this is what the whole discussion was out to prove. You are starting by assuming it is proven here. So of course you can come to the conclusion. But it is this that is in question. And it is not in question because I believe that it cannot be done, but because it is important to work out the HOW. And so making general statements about it being useful does not get us further.

> My identity isn't bound to any piece of network infrastructure. I have a schema that grounded in first order logic and data representation based on a directed graph. In addition, SPARQL delivers all the declarative fidelity I need.  

I don't see what SPARQL has to do with this. But anyway.


>> 
>> Or is it the thou think there should be well known Relying Parties that people trust above all? So that whenever I find a missing key I would go to virtuoso.org because it does a good job of caching keys? 
> 
> I don't what virtuoso.org is. 
> 
> I do know parties can friend, develop verifiable trust, work with WebID secured endpoints, use SSL, secure named graphs, and make signed claims. All using WebID. 

Good. And I mentioned that earlier in the conversation 
http://lists.w3.org/Archives/Public/public-xg-webid/2012Jan/0015.html

[[
But that is just one aspect of how people trust you. The other part is the people who link to that identity. If those people start to unlink to your WebID then the value of that for many services will go down. So one can see that more serious services in the longer term could build up pictures of who someone is that though initially it is based on a WebID, is also then supported by the social network. For example your hoster abandons his service, or your domain lapses, or in a future private key based DNS you loose your private key, then you could create a new profile somewhere saying you were the old Id, and if all your friends link to your new id, then that could be a good way for services to follow up. So I think this is again mostly in trust authorisation step that we are not going into at this point so much, but that we will do as we get our social networks working.
]]

> 
>> 
>>> Or making a new signed statement with your new key about equivalence. 
>> And where would that go?
> 
> In a data space that serves as my idp. The point here is that I have an x.509 cert in a keystore. I have a portable graph (you can     retrieve you graphs from URIBurner anytime for instance and place somehwere else. You can sign the entire graph of make statements about statements that are also signed. 

yes, sounds good. But one needs to solve issues of what happens when one looses one's public key. As I explained a bit more theoretically yesterday.

http://lists.w3.org/Archives/Public/public-xg-webid/2012Jan/0078.html

[[
 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.
]]

>> 
>>> 	Remember, your Idp space should challenge you when making these claims. 
>> 
>> What is an IDP space? Google.com? Or any web site?
> 
> A data space is a place on a network where you read, write, update, and delete data. A place where you can hold claim mirrors. Basically the place where you manage graphs that provide other half of the double entry bookkeeping that drives the whole WebID verification protocol. 

so really you are saying: start off with two webids that mirror each other. Then you are less likely of loosing one or the other.
I think that is what Mo was saying earlier when he said that this mirroring can work if it is done before your loose your private key. Because the service you use can know both ids are owl:sameAs each other. 

That is the issue is if one of them breaks up, which one is the correct one? Social network analysis is probably the way to go as mentioned a couple of days ago in the section above.

The point is that this goes beyond the current webid specification in quite a big way, so I think the best thing is to put up a wiki page first, list the different ways of doing these things, have people implement them see what the issues are then we can spec them out.

> 
>> 
>>> 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. 
>> It is worth describing in precise detail what you wish to do using UML diagrams and precise stamens of what goes where before going to program it. We all need to look at owl reasoning and trust reasoning. It is an interesting field to explore. 
> 
> Again, I haven't asked for anyone to implement this. I have simply asked for the WebID spec to acknowledge issues that arise when dealing with equivalence fidelity. Peter has come at the same issue from a different angle based on the loss of URI control scenario. 

Well I think it's a bit early to put in text on this in the spec yet. But for a future spec it is good to put the foundations out for sure.


> 
> Why are you consistently misrepresenting and pretending to not understand what I am saying? I encourage you to not code and respond to my comments at the same time. 

I am just questioning you to extract the good ideas you have. This is known as the socratic method, or as test driven programming.

> 
>> 
>>> 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.
>> there is a lot to look into there.
> 
> Yes, and again, all ask for re. the spec is cognizance of these matters! 
> 
> The implementation relevance will show up in the Authorization space. In the RWW you'll see what we are on about. Make your apps and then come play ball on the RWW :)

sounds good. But then loosing identity across is the least of my worries for the moment. That seems like an issue that will be worth picking up when we have some other issues sorted out like ACLs, and good applications that interact well, including test suites.


Henry

>> 
>> 
>> Social Web Architect
>> http://bblfish.net/
>> 
> 
> 
> -- 
> 
> 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/