Re: Matter of DN and what's possible

On 1/9/12 2:11 AM, Mo McRoberts wrote:
> On 9 Jan 2012, at 01:31, Kingsley Idehen wrote:
>
>> On 1/8/12 6:55 PM, Mo McRoberts wrote:
>>> On 8 Jan 2012, at 23:39, Kingsley Idehen wrote:
>>>
>>>>> If I'm understanding correctly, you're saying (for example), that sIA might contain a URL,
>>>> Yep!
>>>>
>>>> This reference (an Address) resolves to a profile resource bearing claims mirror.
>>>>> while the sAN contains the URI of the certificate holder which appears within the document published at the sIA URL?
>>>> Yep!
>>>>
>>>> Then you completely solve burden problem for publishers re. Linked Data publishing nuances that ultimately introduce control problems, as already demonstrated by Peter's experiments.
>>> You introduce a new problem, however.
>>>
>>> WebID revolves around the fact that the URI you provide in the subjectAltName is (in some fashion or another) dereferenceable and can be processed by verifiers because asserting the key there allows you to demonstrate that you control it — you’re effectively demonstrating “ownership” — and so applications can then use that URI to identify you.
>> No, there isn't a new problem, far from it. We are simply saying the route to proof doesn't have to go through a single URI.
>> Proof lies in the directed graph that mirrors the claims in the cert.
> Proof of authority over a particular URI has to go via that URI, by definition.

No it doesn't. Part of the proof lies in the Cert. claims the other half 
in the idp space.

>
>
>>> This isn't especially different from the “we have e-mailled you a verification link” automated processes which, having been followed, allow you to be identified by an e-mail address, nor terribly different to Google’s Webmaster Tools site verification or Apps CNAME.
>> Yes and No. We'll even get to that proof once we cross this initial bridge re. Name, Addresses, and Descriptor (of Information) Resources.
>>
>>> How does this work when you’re instructed to look somewhere else entirely via a sIA?
>> You are indicating that there is a document, somewhere on a network that describes the certificate subject. It's easier and much more intuitive. It's this part of matters that confuses people re. Linked Data since you have>  1 level of indirection via a single HTTP URI.
> I’m not sure that answers the question.

You should actually look for addresses in the right place. Of course, 
you can stick to SAN if you want re. indirection, but that will not work 
en masse. It just won't.

>
>>> If my sAN says I am<http://billg.microsoft.com/#me>   and my sIA says to look at<http://data.nevali.net/billg>, you’re still none the wiser as to whether I really have any authority over the resource at<http://billg.microsoft.com/>   or not — instead, I’m effectively '<http://data.nevali.net/billg>   {<http://billg.microsoft.com/>   }', which is quite different.
>> The mirrored claim is the key to proof.
> I’m sorry, I may be being dim, but I -really- don’t understand how that’s an answer. Key to the proof of *what*? If a verifier isn't directly dereferencing the sAN URI, how are you providing proof of anything to do with that sAN URI?

Proof is about claims in a certificate matched to claims in the idp 
space. What function does the certificate serve? It provides a 
collection of claims. The idp space also holds claims starting with the 
relation that associates a cert. with a public key.

The SAN URI is one route to the idp space where the claim mirrors reside.
>
> 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