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

On 1/4/12 5:57 AM, Henry Story wrote:
>
> 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 athttp://bblfish.net/and remove it from 
>>>> there, but the thief of my private key goes and puts in 
>>>> onhttp://surpeticious.com/#meand 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?

You are moving the post here.

The problem: you loose control of a URI. Peter gave you a nice example 
re. Sun to Oracle transition.

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

You loose control over the URI in the SAN of an erstwhile functional 
certificate. That's the point.

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

SPARQL is:

1. Query Language
2. Protocol
3. Results Serialization Formats -- tables and graphs.

You can make a SPARQL Protocol URL that returns whatever you seek, data 
representation wise, dynamically.
>
>
>>>
>>> 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 <http://virtuoso.org/> because it does a 
>>> good job of caching keys?
>>
>> I don't what virtuoso.org <http://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.
> ]]

Yes, this is ultimately in the Authorization realm. Which is why I am 
veering more towards RWW for discussing these matters (Peter: please 
take note, I believe RWW is a better place for these matters).

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

Fine re. the above, but note, the ontology doesn't currently describe 
:key as being IFP. Thus, the ontology needs this relation added. At 
least that was the case when I last looked it up.


>>>
>>>> 	Remember, your Idp space should challenge you when making these claims.
>>>
>>> What is an IDP space? Google.com <http://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.

Put slightly differently. Your graphs (the holder of one side of your 
claims) should be portable. AWWW facilitates said portability via cache 
and cache invalidation schemes (which you can override for you own 
specific purposes if need be). A verifier can act as a portable graph 
mechanism, this is what you see Peter exploiting via the public 
URIBurner instance.

When you have a portable graph and a functional local certificate you 
have the ability to move your claims to wherever as along as you make a 
new certificate that holds references to the graph in question. This is 
where multiple WebIDs in SAN can be very useful.

Depending on where you next place your portable graph, you also have the 
ability to sign, counter sign, or overwrite the signatures associated 
with your entire claims graph or specific statements in it. This 
provides additional assurance levels to more discerning verifiers (once 
these matters are understood and deemed relevant to verifiers).

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

I am assuming that the local cert. is still functional and in your 
possession. If lost, you can overwrite the signed claims or signed 
graph. Remember, the portable graph is decoupled from the network. You 
can move it from place to place.

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

This is social network analysis by way of graph portability and 
traversal. The graph needs to be portable.

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

I also said that this goes beyond the WebID spec. Thus, its a discussion 
note with regards to options for dealing with challenges.


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

At this point, we are looking a Wiki and knowledgebase type notes. Maybe 
even FAQ items.

>
>
>>
>> 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, but since you know me better, those kind of responses spook me. 
Next time, you can state at the start: In Socratic mode :-)


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

Fine.

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


-- 

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