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

On 1/2/12 12:04 PM, Mo McRoberts wrote:
> On 2 Jan 2012, at 02:56, Kingsley Idehen wrote:
>
>> On 1/1/12 11:46 AM, Mo McRoberts wrote:
>>> On 31 Dec 2011, at 17:24, Kingsley Idehen wrote:
>>>
>>>> Peter gave an example a while back where he loses his Blog space URIs (since he doesn't control Blogspot or WordPress) but still needs to be able access resources where his old Blog space (the IdP)  URI is remains the focus of  ACL list by those granting him access to resources (e.g., photos). In this case, he can present a Cert. that has his old URI and his new URI in the certs. SAN. The ACLs don't have to change, assuming the verifiers comprehend coreference claims.
>>> There are a very limited number of ways in which that can work if the old URI no longer resolves to linked data matching up the with cert (as would be the case if the account at Blogspot was suspended, or Google shut it down, or whatever — including it now reflecting *somebody else's* claims) without making it trivially easy for hijacking to occur.
>> Hijacking doesn't work if you are leveraging signed equivalence claims. This is why OWL is important. The semantics matter, the channel is secure, and the claim is signed.
> The claim is only signed for one of the two URIs, hence you can't accept the claim of equivalence.

You can do whatever you want, subject to the system in use.

The fundamental point here is that semantics are ultimately controlled 
by an ontology which basically defines the workspace of a system re. 
entities and their relations.

The SAN of an X.509 certificate is a place holder that accepts composite 
keys. Yes, when you have multiple URIs (Unique Resource Identifiers) in 
SAN you are saying I have a Key comprised of individually unique keys.

The DN of an X.509 certificate is a place holder for compound keys. 
Meaning: the combination of the entries gives you a Unique Key.

The DN deals with Addresses. and the SAN actually deals with Names.

You can make claims in the X.509 cert solely, or go one step further and 
mirror them in an Idp space (what WebID does using a splice of an X.509 
cert). You can also go beyond a specific splice and mirror more claims 
en route to richer assurances.

It all depends on what the system is seeking to deliver.

If a system seeks to handle identity in such a way agents are protected 
from corrupt practices on the InterWeb (as Peter's example try to 
demonstrate) you will need to leverage the semantics of equivalence 
applied to Linked Data as delivered by OWL. You will also need to signed 
the claims in Idp space also.

There is not notion of "you can or cannot do" anything re. what goes 
into an X.509 certificate, bar deviating from its actual semantics as 
specified by the standard.

As I've stated repeatedly, these matters are much easier to understand 
with real world examples e.g., ACLs applied to shared resources.


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



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