Re: Matter of DN and what's possible

On 1/9/12 8:35 AM, Henry Story wrote:
> On 9 Jan 2012, at 14:06, Kingsley Idehen wrote:
>
>> On 1/9/12 7:20 AM, Mo McRoberts wrote:
>>> Kingsley,
>>>
>>> The point of mirroring the claim in a resource which can be retrieved by de-referencing the URI the holder assigns themselves is so that you can be sure they have a reasonable degree of authority over that URI, and so can use it as an identifier for them.
>> That assurance doesn't come solely from the SAN. It comes from the certificate. The SAN simply offers a slot to hold Name(s). The fact that said Names are de-referencable is a Web scale luxury that most publishers simply cannot afford, as already demonstrated by Peter.

Henry,
> Peter Williams does not prove anything. Peter is not mentioned on the Alice and Bob page.
>    http://en.wikipedia.org/wiki/Alice_and_Bob

I did say he did. I am saying: he's efforts demonstrate the point I am 
trying to make. I speak about actual implementation examples. Peter is 
experimenting and showcasing reality.

>
> Peter Williams is a new character there. Instead of breaking an existing protocol, Peter Williams inserts himself into a security protocol creation group and by flattery and pretending to be important makes sure the protocol becomes just complicated enough that he can then rely on it being badly implemented in enough places so that he can then break it.

No, you are really missing the point. Peter is giving the spec QA. He 
has a profile in mind, he is clear about that re. his feedback. Peter is 
testing the viability of the WebID protocol for the Web consumer level 
end-user.

His point is quite simple: can an end-user make and publish a claim 
that's in a semantically rich relation with claims made in a local x.509 
certificate, leveraging:

1. WebID Protocol
2. PKI
3. x.509.


>
>>>   It doesn't matter whether that's an http: or https: URI, or some other kind (acct:, ldap:, whatever) — provided there’s an unambiguous function which can be handed that URI and will de-reference it to a resource which contains the mirrored claims.
>> It does, since not all URIs are de-referencable. Thus, what you need is a slot in the certificate that holds the address of a descriptor (information) resource that describes the cert. subject using the Name(s) in SAN.
> That's why we work with dereferenceable URIs. Those do exist.

And again, my point is that de-referencable URIs are a luxury if you are 
saying that's all that can go in the SAN slot of an x.509 cert. with 
regards to the WebID verification protocol. If you truly hold that 
position then I actually understand why you find Peter problematic.

>
>>> If the resource you’re fetching isn’t de-referenced from the that identifier — i.e., it comes from somewhere else entirely, as you suggested would be the case (see quote below), then the claim over the URI isn’t mirrored any more.
>> The cert. is making a relation between the SAN and the descriptor (information) resource address.
> So the question is can Peter Williams mint a cert that says he is the owner<idehen@openlinksw.com>  and point to a service that he has set up for pirates? If he can then you're bank account will open to him anytime he feels like using it.

How on earth is he going to pull that off in a viable way? The essence 
of Webfinger (even BrowserID) is that you have to prove ownership of the 
mailto: URI. Now that's a practical answer. Your question is impractical 
and unrealistic since my mailto: scheme URI will never be the conduit to 
my bank account, under any circumstances. The technically dumbest bank 
on this planet would never facility such mediocrity.

>
>>>>> 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!
>>> Thus, Peter might have:
>>>
>>> sIA:<http://rdf-translator.appspot.com/parse?url=http%3A%2F%2Fyorkporc2.blogspot.com%2F&of=n3>
>>>
>>> sAN:<http://yorkpc2.blogspot.com/#me>
>>>
>>> (And the data at yorkpc2.blogspot.com might be in some random format, or might not even be published there at all — it’s just used as a key by rdf-translator.appspot.com).
>>>
>>> There’s nothing wrong with this *per se* but you’re changing the landscape somewhat: it reduces the scope of everything in the the resource to 'untrusted, unverified input' — it’s just a self-asserted attribute exchange document, at which point there’s no point in verifying that the key matches any more, because it doesn’t make a jot of difference to anything if it does. What you *can’t* do any more is use the self-asserted identifier of the holder as any sort of confirmed identifier, because the claim isn't mirrored there — it’s mirrored somewhere else entirely.
>> 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.
> Ok so lets look at the claims you have in your certificate. Let us say your cert with extension says something like
>
> -----------------
>   <>  a :Certificate;
>      primaryTopic _:subj .
>
>    _:subj distinguishiedName [ cn "Kingsley Idehen"; ... ];
>        sia<http://pirates.org/makeSaomeCash/Kingsley>  ;
>        owl:sameAs<http://kingsley.idehen.name/dataspace/person/kidehen#this>  .
> -----------------
>
> where sia is some inverse functional property .

sia isn't an inverse function property. Its basically the semantic 
equivalent of wdrs:describeby . It points to a resource that describes 
the certificates subject.

>
> Good, so now your bank looks at the certificate, verifies<http://pirates.org/makeSaomeCash/Kingsley>  and of course it does verify (how the verification should be done would still need to be specified). What should they now conclude? That the owl:sameAs in the certificate is true and that they have to do with you?  Of course you won't agree with that.

Nonsense. Where is owl:sameAs in the current narrative re. sIA? I've 
made no reference to an owl:sameAs relation in this context.

What you are missing is triangulation.

Via sIA I end up in the same place as you would with a de-refrencable 
URI in SAN. I end up with an idp space graph comprised of:

1. WebID  -- in SAN
2. Public Key -- from generated Cert.
3. predicate that establishes a relation between #1 and #2
4. predicate that establishes a relation between #1 and the resource 
that describes it via wdrs:describedby -- this relation implies that the 
subject of this certificate is described by this idp space hosted 
resource .

Like the missing use of *isDefinedBy* amongst most ontology and 
vocabulary publishers, wdrs:describedby adds a predicated for relations 
that express subject and descriptor relations. Remember, the effect that 
my addition of rdfs:isDefinedBy made to the Cert. Ontology? I added the 
relation even though you pushed back instinctively prior to seeing the 
profound impact it had on the ontology. Ditto my alerting you to the 
fact that cert:key should be an IFP (by way of relations instead of 
conversational connotation -- btw the ontology is still missing that 
statement as of last time I checked).

I can achieve the very same thing via multiple URIs in SAN btw. I can 
have any of the following in my SAN:

1. HTTP URI for Name and a HTTP URL for the descriptor resource Address
2. maito: URI for Name and a HTTP URL for descriptor resource Address
3. mailto: URI only and Webfinger (or Fingerpoint) protocol for 
resolution to descriptor resource Address .

Instead of pushing back instinctively, for the wrong reasons, do try to 
understand the issue of triangulation that I am trying to get across to 
you re. Linked Data complexity reduction costs for WebID.

A de-referencable URI in SAN should be an option. It isn't the only way 
to get the same result. A Linked Data URI combines the roles of HTTP URI 
based Name and HTTP URL based Address in a manner that places 
Name/Address disambiguation nuance challenges in the hands of the 
publisher. This is a luxury the consumer Web user cannot afford.

BTW - since a HTTP URI based Name and a HTTP URL based address are both 
de-referencable URIs, what URIs do you expect in the SAN slot of an 
x.509 cert. with regards to WebID? I am asking you a nuance laced question.

>
> All they can conclude is that they have to do with some _:💀 where
>
>   _:💀 sia<http://pirates.org/makeSaomeCash/Kingsley>  .
>
> If the document at<http://pirates.org/makeSaomeCash/Kingsley>  then had a primary topic declared owl:sameAs relation to http://kingsley.idehen.name/dataspace/person/kidehen#this and the document there also had a link to
>   http://pirates.org/makeSaomeCash/Kingsley
>
> then the bank could conclude that
> <http://kingsley.idehen.name/dataspace/person/kidehen#this>  sia<http://pirates.org/makeSaomeCash/Kingsley>
>
> But in that case there was no need to go through the indirection of<http://pirates.org/makeSaomeCash/Kingsley>  .
>
> QED.

No!
As already explained to you above, the relation is wdrs;describeby .

Link:

1. http://www.mail-archive.com/public-lod@w3.org/msg06723.html - Tale of 
two missing predicates, an old 2010 mail thread (note: I meant: 
wdrs:descrbedby not isdescribedby )

2. http://www.w3.org/2007/05/powder-s#describedby -- function of the 
wdrs:describedby predicate .


-- 

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