Re: Matter of DN and what's possible

On 1/9/12 9:57 AM, Mo McRoberts wrote:
> 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).

I disagree.
Control over a name isn't proven by HTTP URI, solely. There are too many 
whole in the rigid claim you are trying to make.
The scope of this game is URIs, not de-referencable HTTP URIs. It just 
so happens that they are cheap, on one front, but really expensive on 
others e.g. intuition and deployment.

Again, you will get my point via utilization. I don't want to argue with 
you about this via email. Imagine how much time I could have burned with 
Bergi over the weekend re. my URI issues if that was left to email 
instead of working with actual implementations etc.. Same even applies 
to your initial tests with my URI.

There are other ways to clarity, and in this case, exercises with 
implementation will be more productive. You will find that whatever I 
suggest is demonstrably non disruptive (bar Henry's preferred work 
patterns that are driven by code, libraries, and parser related work 
first) since we are just working with directed graph based data 
structures endowed with semantic bearing relations that are machine and 
human comprehensible.


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

No, SAN isn't about convenience. The semantics are that of an 
Alternative Name for the certificate subject.

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

Subjectively so, but broken.

You have an Alternative Name for a certificate Subject -- that's one 
relation.
You have an Address for a description document -- that's another relation
You have a Certificate Public Key and other elements of the Certificate 
-- all related to the Cert. Subject by said Subject's Name.

>
> If you look ELSEWHERE for that relation, then you haven’t proved control over that URI.

I disagree.

The semantic relation in play is cert:key in the idp space. That 
relation comes from the Cert. ontology used by the WebID protocol. 
Nothing stops the ontology or an alternative used by more open verifiers 
from adding a relation that associates the descriptor document with the 
same Webid, Public Key composite.


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

The basis of the relation on the idp side is cert:key. Otherwise, what 
is the basis?

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

That the certificate holder is the subject of a description document 
that resides in a place controlled by said certificate holder.

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

<http://billg.microsoft.com/#me>  is an identifier associated with the subject of an x.509 cert. There is a semantic relation that's inherent in the x.509 cert.

de-reference isn't proof. You get proof via relations and their semantics.



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

I've bothered enough to have a massive stack of Linked Data technology 
work, and work in the most pragmatic ways. That's why I bother. I 
actually have a profound understanding of WebID's potential. Of course, 
it might not manifest via this particular effort, but I absolutely 
understand its benefit to the interWeb at large, hence the investment 
we've made so far re. actual tools that actually work.

>
>
>> 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!”?

I think I have one very predicatable characteristic, and that's showing 
rather than telling. Again, I also like to say to the community: here is 
what I am going to implement, I think it would benefit you too..

What I don't enjoy are gut reaction rebuttals esp. from folks that I 
believe should know better when it comes to the pursuit of inclusiveness 
re. spec design and implementation.

Simply reverting to: its not in WebID at the end of an argument doesn't 
work for me. I see WebID as a quite embryonic work in progress, at best.

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