Re: Matter of DN and what's possible

On 1/9/12 9:11 AM, Mo McRoberts wrote:
> On 9 Jan 2012, at 13:06, Kingsley Idehen wrote:
>
>> You have a claim in a certificate. Another in a descriptor (information) resource at an Address.
>>
>> You can achieve this via de-referencable Names i.e.,>  1 level of indirection (a luxury to a majority of claim publishers).
>> You can achieve this via a de-referencable Address with 1 level of indirection via an URL in sIA.
>>
>> The existence of the following in his x.509 cert is a claim. Control over the cert is provable by virtue of him placing the modulus, exponent, and even other splices of the local cert. in an idp space over which he has CRUD privileges e.g. a blog post in a space offered to him by Blogspot.com. The same proof applies to email addresses as long exploited by S/MIME .
> Control over the certificate is provable by virtue of him HAVING THE PRIVATE KEY.
Yes, and where have I indicated otherwise?

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

>
> 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? Anything in the cert is associated with the public key of 
the cert. 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?

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


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.

>
>>> In the above example, Peter has no confirmed claim over<http://yorkpc2.blogspot.com/#me>   because the data which would otherwise mirror that claim and confirm it is retrieved from<http://rdf-translator.appspot.com/parse?url=http%3A%2F%2Fyorkporc2.blogspot.com%2F&of=n3>   without ever touching the resources retrieved when de-referencing the sAN URI.
>>> At this point, the only piece of actual confirmed information you have (and so the only thing you can use as an identifier) is the public key itself, the content of the profile document is no different from presenting a form and asking the user to fill it in.
>> You are signing and exchanging the claims in the cert when you perform a SSL/TLS handshake. WebID proof is not about what's in the SAN. It's
>> about the relations inferred from the Cert. with the de-referencable URI in the SAN serving as the conduit to the idp space that holds the mirror of claims in the cert.
>>
>> As you'll eventually realize, we could just as well lookup the entire cert blob in the idp space. In that case you are looking up a complete carbon copy across the local cert. and what's been placed by the certificate subject in an idp space. Again, this is also an old point made by Peter and others in the early days of this endeavor. There's nothing that special about the public key per se. It the fact that we have claims in two places that matters, ultimately.
>>
>>> 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