Re: Matter of DN and what's possible

On 1/9/12 2:23 PM, Mo McRoberts wrote:
> On 9 Jan 2012, at 18:42, Kingsley Idehen wrote:
>
>> On 1/9/12 1:35 PM, Henry Story wrote:
>>> Ok. So now you have two URLs where before we had one. That is why the previous talk about URIs being a luxury does not make sense. Your solution requires more of them.
>>>
>>>>>>>   And if it is a URL then why is that not just the place of a WebID then?
>>>>>   >   Because you will ultimately quibble about its complexity.
>>> Why, I have always supported multiple SANs in the certificate. No issue there.
>>>
>> One point re. the above. Imagine the following scenario:
>>
>> I have a sparql construct URL as my address (and compacted using a shortener), and a HTTP URI based Name as the subject Name. Both URIs placed in SAN of my x.509 cert. Would your verifier work? Do you deem this acceptable re. WebID spec as it currently stands?
>>
>> Note: the SPARQL URL resolves to a description graph. The other URI is the Subject described by said graph.
> Unless you crafted your construct in a particular way, then no, it wouldn’t verify. In either case, assuming the HTTP URI based name wasn't dereferenceable itself (as you’ve said), it would simply be discarded. Put one in the DN the other in the sAI; put both in the SAN — it doesn’t change the processes behind it.
>
> Let me put this as simply and straightforwardly as I can manage.
>
> The thing which has made WebID novel is that it marries a certificate and a dereferenceable URI (which isn't necessarily an http: or https: URI) in order for a relying party to be able to definitively say “yes, that URI uniquely identifies the holder of the certificate”.

And this novelty comes from sole use of a specific slot in the x.509 
cert, right?

You also contradict yourself when you say:  ".. (which isn't necessarily 
an http: or https: URI) .." because that's my fundamental point. It 
shouldn't have to be a de-referencable HTTP URI based Name, solely.

It's why I make reference to Webfinger, Fingerpoint etc.. as mechanisms 
for making mailto: scheme URIs resolvable. Thus, you can have them in 
the SAN slot.

And if you don't want to take the Webfinger and Fingerpoint route, could 
achieve the same via:

1. mailto: URI in SAN
2. HTTP scheme URL in SAN -- that resolves to a graph that has a mailto: 
scheme URI for the description subject.

As for SPARQL construct, you would make a HTTP scheme URL that returns a 
graph that describes a subject using another URI (be mailto: or any 
other scheme where resolver implementation is challenging) also in the SAN.

Trouble is, I didn't even bother with the above assuming the default 
response from Henry. Thus, I looked for even easier and less confusing 
solutions which leads to the Subject Information Access slot (sIA) .

>
> If you take that away, but still keep in the “URL of some data somewhere” aspect, then you’ve got a client certificates with stock attribute exchange — which is interesting, but isn’t the same thing, and doesn’t let you use the URI as a unique identifier for the holder (not necessarily a bad thing in itself; I posted about approaches to that back in April last year).
>
> If the URI itself isn't de-referenceable, and the certificate has to bear *another* URL which is used as the location of the data about the URI, then you're eschewing the only mechanism which tells you whether that the holder of that URI is the same as the holder of the certificate. Looking at a different URL for that information amounts to taking the other URL’s word for it, which isn’t the same thing. This is why I posted the various examples which show exactly this.

I can't decipher disambiguation of the Name and Address roles in your 
comment above.
We are dealing with URIs that have different levels of indirection en 
route to resolving data. That's another way of understanding 
Name/Address role disambiguation re. HTTP URIs.

>
> Perhaps it's the case that you don’t care about being able to identify the certificate-holder globally using the URI carried by the certificate. That's fine.

No, that isn't my point. I care about unambiguous identifiers. I also 
care about unambiguous data location names (addresses). I also care 
about descriptor (information) resources accessible from unambiguous 
data locations names (addresses).  I also care about semantics that 
facilitates loose coupling of names and descriptor (information) 
resources which decouples identity claims from network infrastructure.
>
> You can do all the semantic hoop-jumping in the world, but it’s simply impossible to achieve the following:
>
> 1. Certificate C contains identifier I and locator L.
> 2. Identifier I is not resolveable.
> 3. Locator L contains structured data with I as the subject.
> 4. Relying party A wishes to determine whether it can uniquely and definitively identify the subject as I solely by asking L.
>
> This is quite simply because both L and I are of the user’s choosing. Neither are trusted to any extent, and the only relationship they have with one another is that that both are named by the certificate and by L.

A user makes a certificate and stores it to their local keystore. That 
part one. The then make a claim in another place, the idp space, that's 
part two. Relation semantics connect both realms.

>   "I" could be a  UUID, a telephone number, an ISBN, an OID — it really doesn’t matter, the principle is the same. It’s pretty much like you asking for proof of my postal address, and me sitting down with a text editor and typing out “This document is proof that my address is 24 Sycamore Drive, Washington DC., USA”, attaching my photo, printing it out and handing it to you: unless you try to send me some mail there, or knock on the front door, or ask for more concrete proof, the information is of little use beyond forming part of a list of things I have claimed at some point or another.

Not if its placed in a box, at a location, that I possess unique 
privileges over. And the combination of claims, and carbon copy 
constitute proof.

>
> Do you really want proof of my postal address? I don’t know — but WebID as it exists now is built on the concept that relying parties do so that they can do interesting things with it.

At some point we'll connect. At this juncture we are speaking past one 
another. Your comment about de-referencable HTTP scheme URIs not being 
the sole option is the crux of the matter. If you agree with that then 
we agree. Our only minor challenge is how we ultimately find a way 
reconcile that we've different paths to the same destination :-)


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