Re: Matter of DN and what's possible

On 9 Jan 2012, at 14:30, Kingsley Idehen wrote:

> 
> The question isn't control over the certificate. The question is who controls the claim assertions, and how is that proven?

No, it isn’t. The question is who controls the namespace the WebID URI belongs to if you’re going to use that URI to identify them (and in particular, disambiguate them).

>> Control over the data space is provable by virtue of putting the public key data in material space which corresponds to that private key (which you’ve established by that point he controls).
> 
> Yes, and where have I indicated anything contrary to that bar the location of the URL that serves as the address. a URI in SAN isn't the only place in a cert. for establishing a relation with a Certs. public key.
> 
>> 
>> If the identifier is not unambiguously de-referenceable to a resource providing that proof by a well-defined means, then control over that identifier is unproven.
> 
> What make's de-reference via SAN so special with regards to the public key relation?

It doesn’t have to be SAN, it’s just that SAN is a convenient place to put that identifier (and so is written into the WebID spec as such).

If you want to prove control over a URI, then you you need to dereference that URI and look for something which nobody _else_ has any interest in putting there — and in the case of WebID only the public key material falls into that category.

If you look ELSEWHERE for that relation, then you haven’t proved control over that URI. This is first principles stuff, really.

A further example:

I claim my WebID is urn:uuid:1bb49a11-64ab-48d4-b32b-098ea1baea52 and puts it in the sAN (for the sake of argument).

Because that can't be dereferenced, I include a sIA URL of http://example.com/data/me.ttl, which contains relations about <urn:uuid:1bb49a11-64ab-48d4-b32b-098ea1baea52> and my key.

Somebody else claims their WebID is urn:uuid:1bb49a11-64ab-48d4-b32b-098ea1baea52 and puts it in their sAN.

Because it can't be dereferenced, they include a sIA URL of http://example.org/things/me.ttl, which contains relations about <urn:uuid:1bb49a11-64ab-48d4-b32b-098ea1baea52> and their key.

Who do you believe? How do you disambiguate? What is each holder's WebID URI?


> Anything in the cert is associated with the public key of the cert.

Surprisingly enough, I am familiar with how an X.509 certificate works. 


> Just as the public key is associated with the subject of the cert etc.. Where are you picking up this unique relation bar the existence of cert:key relation in the idp space?

I'm not terribly sure what that sentence is supposed to mean.


>> If the identifier is merely a key used to select data from a *different* resource, then you’ve proved control over that resource, not over the identifier.
> 
> And I prove control over identifier by the semantics discernible from the relation in the idp hosted graph. I can semantically triangulate that fact.

If you're not dereferencing the WebID URI, you're not triangulating anything, you're just demonstrating that the certificate holder has control over the sIA resource.


>> 
>> If I have:
>> 
>> sAN: http://billg.microsoft.com/#me
>> 
>> SAI: http://data.nevali.net/billg.ttl
>> 
>> And billg.ttl says:
>> 
>> <http://billg.microsoft.com/#me>  a foaf:Person ; cert:key [ a cert:RSAPublicKey ; cert:modulus "...."^^xsd:hexBinary ; cert:exponent 65536; ] .
>> 
>> …then all I’ve proved is that I have control over<http://data.nevali.net/billg.ttl>; my claim to be<http://billg.microsoft.com/#me>  remains unproven.
> 
> You've proven that by a predicate in an ontology. You could just as well prove that by having a blob in the idp that is a complete mirror of the cert.


I’ve proved what? The point isn’t what I’ve proved, it’s what remains unproven.


>> If you don’t care what URIs I might have control over, you can skip the whole “check whether there’s a cert:key relation” process and just use whatever data is in that space as though it were typed by them into a form (in fact, you could just not bother with the separate resource if you like — just use whatever claims are embedded in the certificate) — but that’s not WebID.
> 
> You are making a rebuttal about an emerging spec that's fast becoming a prescription devoid of real world practicality or any kind of industry experience.


Then I’m really not sure why you’re bothering?


> At this juncture, we are looping again.
> 
> I have to get sIA integration done, and then you can test, and best of all you see that it will work for you view of verification while also working with others esp. the consumer profile that Peter is trying to get everyone to comprehend.

Or, you could have just explained it and posted a simple example. Do you not think that would be massively more productive than expecting people to tease out from you — at great length — what you think people should be doing and implementing, only to be met with a “you’ll see when I’ve done it!”?

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



http://www.bbc.co.uk/
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

Received on Monday, 9 January 2012 14:57:31 UTC