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

 IN the OCSP variant of this, the OCSP response representing the findings made by a "Validation Authority" ABOUT a cert-related claim was/is signed. IN some case the signature chained back to the CA issuing the certs, but (in a major IETF victory, and thank Microsoft) its not necessary. This free agents, NOT governed by CA. Each VA applies different criteria, to suite the request ofr the remoted validation service. Said party is typically know as the relying party. This creates a validation.-entric universe (inverting the trust model, and applying reference theory). Its VERY VERY threatening to the social order, as it interferes with some of the costy relationships IDPs have with wider social governance ideas. A certain CA spent a lot of money killing it off, last time around, to aid one of their principal customer project a particular national policy for trust. The particular US government agent was in charge of national policy at the time, and acting properly (through indirectly, through its vendors). IN our world, we want an xml-dsig property to be strored on the web (not in an OCS response message). More likely, its a counter-signed xml-dsign signature, on an existing signature. Xml DSIGN allow REFERENCES to remote signing material, for both signature and counter signatures.   > From: mo.mcroberts@bbc.co.uk
> Date: Tue, 3 Jan 2012 19:48:44 +0000
> CC: public-xg-webid@w3.org
> To: kidehen@openlinksw.com
> Subject: Re: How To Handle WebIDs for (X)HTML based Claim Bearing Resources
> 
> 
> On 3 Jan 2012, at 17:14, Kingsley Idehen wrote:
> 
> > 
> > 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.
> > 
> > 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.
> 
> Sign it with WHAT? You've said the key in the cert has no impact. A newly minted key? Well, I (the attacker) can sign using a key *I* have just generated.
> 
> 
> 
> > 
> > 
> > 
> > 
> > 
> > 
> >> 
> >> 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 .
> > 
> >> 
> > 
> > 
> > -- 
> > 
> > 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
> > 
> > 
> > 
> > 
> > 
> > 
> 
> -- 
> 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
> 
> 
> 
>