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

We are getting to the heart of webid now, and we will now see if the technogy (that we flogged to death) really does anything equivalents failed to do.

For example, this was supposed to be a radically new community, due to using only self signed (and even unsigned for most agents if you test) Certs. It was just a package.

If we do insist on self signed, semantics change, as the signed certverify in sso and the signature on the cert now have a crypto relationship. In short, the public key is an persistent I'd, that the telco/google cannot spoof or suddenly remove from the public space.

It becomes what the canonical xri wanted to be.

Don't forget, after 20 years, folks in Certs land have lots of experience with cert and name lifecycle management. I seem to recall a certain ca buying a certain .com name registrar, a while ago.

In rfc1422, you will see that 1 key can be in multiple Certs. Furthermore, an old cert or a self signed cert is acceptable as a csr -cert signing request. Thus little webid (aiming to liberate the pleb in all of us) can yet integrate with the world of ttps (adding assurance, like insurance or records) - without ceding control over the persistent name.

I'm going to owl:sameas to a data uri (with my self signed cert blob in the body). Let's see what happens, now. Beyond owl mgt of equivalence relations/classes, there will be a crypto assurance, since on subgroup will be distinguished as bearing the mark of the private key.

I like this. It radically changes the nation of signing - finally getting passed the failed rivest digital signature concept. Kingsley is spot on, that an owl-enforced equivalency by a validating part is a signature - semantic web style. Something original has actually occurred.

Sent from my iPhon

On Dec 30, 2011, at 4:21 PM, "Mo McRoberts" <mo.mcroberts@bbc.co.uk> 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? Does the same apply when you lose all access to the old URI? How do you do 'rollover'? What happens when you can't re-use the key to generate a new cert with the new URI? 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. (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…)
> 
>> 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)
> 
> M.
> 
> -- 
> 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
> 
> 
>

Received on Saturday, 31 December 2011 00:42:12 UTC