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

I'm convinced that webid without owl (for synonym mgt) is not worth pursuing.

Im less clear about the value of what rdfs defines here.

Dave x of smtp fame (a variant of mtp) commented on my book that it was not clear how key management vs key distribution were different (missing the whole point of the book).

One is close to the master: the other close to the slave because the individual (former flavor) made a choice. 

This very idea bugs a lot of Hamiltonian federalists. 

Great.

(Peter being not loyal , but not disloyal )


Sent from my iPhone

On Dec 31, 2011, at 9:24 AM, "Kingsley Idehen" <kidehen@openlinksw.com> wrote:

> On 12/30/11 7:21 PM, Mo McRoberts wrote:
>> On 30 Dec 2011, at 22:28, Peter Williams wrote:
>> 
>>> The foreseeable future is the caveat - and is fine (and traditional) in identity for content class resources
>> Ah, perhaps, but the semantics of “your WebID URI changing” haven't really been defined yet — if your key persists but your URI changes, what happens?
> 
> They key is useless. The net effect is the same as your keystore computer (desktop, notebook, tablet, phone, USB cryto device) being stolen. A URI changing in manner that breaks its relation with a Public Key is implicitly handled by the semantics of the WebID protocol.
> 
> 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.
> 
>> Does the same apply when you lose all access to the old URI?
> 
> See comment above.
> 
>> How do you do 'rollover'? What happens when you can't re-use the key to generate a new cert with the new URI?
> 
> See comment above.
> 
>> For some classes of application none of this poses much of a problem, but as soon as you start associating persistent information within those applications with those identities, there's something which has to be figured out.
> 
> This is what OWL handles. The reality is that Linked Data without OWL has serious utility limitations.
> 
> The good thing here, as I've stated before, is that the WebID spec doesn't have to mandate relation semantics covered by OWL, but it shouldn't totally ignore them either. We have base assurance levels that should provide a common foundation for implementors, and more sophisticated assurances that leverage other aspects of the Semantic Web technology stack e.g. OWL.
> 
>> (Of course, there are situations where you *want* to have a completely distinct digital identity, but that doesn't mean you should be forced to…)
> 
> Correct.
> 
> That's the "Clark Kent" and "Superman" paradox. It's covered by OWL semantics.
> 
>>> The uk does better than others in official naming. You can go to court and be referred to as your pseudo official nom de plume, street alias, customary monicker.
>> You don’t even have to go to court.  Scottish law is slightly different to the rest, but in Scotland you just pick a name and start using it — the law covers “intent to defraud”, but that’s about it. In the rest of the UK, I believe there’s a bit of paperwork and then much the same.
>> 
>> (This was one of my big bugbears with Google+'s real name policy, aside from being clearly impractical to enforce -- http://nevali.net/post/11711699214/in-which-i-discuss-google-and-identity)
> 
> G+ real name policy and the ensuing imbroglio brought the matter of identity to the fore, courtesy of Google's might. That might end up being the greatest piece of WebID bootstrap ever :-)
> 
>> 
>> 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

> 
> 
> 
> 
> 
>

Received on Sunday, 1 January 2012 00:23:47 UTC