Re: Matter of DN and what's possible

On 9 Jan 2012, at 15:20, Kingsley Idehen wrote:

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

He is experimenting reality?  As opposed to experimenting with the imaginary worlds? You make him sound like someone who is on drugs most of the time and is experimenting to see what happens when he stops taking them. This reminds me of an episode of the Freak Brothers, where they did in fact decide to stop taking drugs for a while. The pictures of the Freak Brothers started getting more and more realistic, until they were drawn in photographic like manner. I think that lasted one page before they got bored and lit up another joint. I can't remember which episode that was

  http://en.wikipedia.org/wiki/The_Fabulous_Furry_Freak_Brothers

Anyway, that is what one could call showcasing reality.

But I don't see Pirate Williams showcasing anything, other than an inability to change his mime types, and an unwillingness to wait for the microdata/rdfa debate to settle. I would like to see a real use case clearly written out and without Naked Lunch type inter worlds type language.

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

Yes, please describe the use case.

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

That question is either yes, because we have done this for the past few years, or it is so general it is difficult to understand. A use case is needed.
> 
> 
>> 
>>>>  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.

de-referenceable URIs are a luxury is such nonsense it boggles the mind that you even bother to say something like that.

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

Well I suppose I'll wait for you to lay out some details of the protocol you want to come up with. At present we have nothing to go on. 

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

Ah I see the footnote at the bottom. wdrs is powder http://www.w3.org/2007/05/powder-s#describedby
I'll use powder, because wdrs keeps getting transformed to wars in my editor.

ok, so just substitute powder:describedby if that makes you feel better.

Here:

-----------------
 <>  a :Certificate;
    primaryTopic _:subj .

  _:subj distinguishiedName [ cn "Kingsley Idehen"; ... ];
      powder:describedby <http://pirates.org/makeSaomeCash/Kingsley>  ;
      owl:sameAs <http://kingsley.idehen.name/dataspace/person/kidehen#this>  .
-----------------


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

the owl:sameAs points to the Subject Alternative Name in the certificate I described above.

Perhaps this will make it easier?

-----------------
 <>  a :Certificate;
    primaryTopic _:subj .

  _:subj distinguishiedName [ cn "Kingsley Idehen"; ... ];
      powder:describedby <http://pirates.org/makeSaomeCash/Kingsley>  ;
      cert:SAN <http://kingsley.idehen.name/dataspace/person/kidehen#this>  .
-----------------

SAN is Subject Alternative Name, i.e. owl:sameAs.

> 
> What you are missing is triangulation.

No in the example I give below I show that you have add an additional triangulation that brings no extra benefit. That is what I call making something unnecessarily complex. In any case it requires a use case.

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

(cert:key is done.)


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

Write up a use case for what you want, then we can see if it is a reduction in cost or an increase or what the benefits of what you are proposing are.

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

Luxury!?

> 
> 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;describe by .

That makes no difference. I'll put it in terms of powder:definedby

So all they can conclude is that they have to do with some _:💀 where

 _:💀 powder:definedby <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> powder:definedBy <http://pirates.org/makeSaomeCash/Kingsley>

But in that case there was no need to go through the indirection of<http://pirates.org/makeSaomeCash/Kingsley>  .

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

Social Web Architect
http://bblfish.net/

Received on Monday, 9 January 2012 15:16:00 UTC