W3C home > Mailing lists > Public > public-xg-webid@w3.org > January 2012

Re: Matter of DN and what's possible

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Mon, 09 Jan 2012 11:40:34 -0500
Message-ID: <4F0B1882.9040807@openlinksw.com>
To: public-xg-webid@w3.org
On 1/9/12 11:03 AM, Henry Story wrote:
> On 9 Jan 2012, at 16:32, Kingsley Idehen wrote:
>
>> On 1/9/12 10:15 AM, Henry Story wrote:
>>> 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.
>> Henry,
>>
>>> He is experimenting reality?
>> Yes, his reality for his use-case scenarios.
> Well one does not experiment reality even in that case.
>
> What we would like to know about is his use-cases then. Or rather your use case, as its better if you speak for yourself.

The use case is simple:
How do commodity / consumer level publisher profiles exploit WebID?

Characteristics of this profile:

1. No control over HTTP server
2. No control over resource mime types
3. Rent space via SaaS model providers such as blogspot, wordpress, 
twitter, linkedin, facebook etc..
4. Cut & Paste is their basic entry point re. Web resource creation 
(which includes info cards and profile documents).

>
>>> As opposed to experimenting with the imaginary worlds?
>> There you go again with counter productive subjective commentary.
>>
>> Do you know how much it would cost to obtain a modicum of the QA that Peter is providing re. WebID. Ah! I forgot, this all about Open Source and free where individual times costs don't matter, right?
> Do you know how much time it takes to read a lot of this?

Again, that's your problem not mine. I read through his documents 
because I value his commentary and experiments.

You might not agree with the  Subject Information Access Address 
extension, but in my world view, it solves a major headache. Thus, no 
more arguments about using CN for addresses when there is an existing 
extension with the appropriate semantics in place. Said semantics are 
reproducable in a idp space hosted directed graph servicing as the 
description of the subject of a certificate using the identifiers in the 
certs SAN.


>   Peter Williams has never implemented WebID at all.

But that's unimportant if this dialogue is about WebID utilization 
experiments and QA.

Is this effort solely about implementing WebID rather than actually 
testing its practical utility via user profiles?

>   So there is very little reason to listen to his always more and more complex ideas.

They might seem complex to your profile. They aren't complex to mine. I 
quickly hone into the practical and pragmatic utility of what Peter is 
seeking. I discern that from his comments and reconcile that with his 
experiments.


> It took him 3 years to even get a working WebId.

No, it took him 3 years to be convinced of many aspects of WebID.

>   There are beginner students who have understood how to do it in less time.

Most of those students more than likely know zilch about PKI, x.509, 
distributed computing, policy based data access etc..


>   I have given 2 hour courses where people got to write their foaf file at the end of it, and I think one could do that with hand written webids in less than 3 hours.

So what though? Why should they be writing a FOAF file at all? The basic 
introduction should be making an info card that holds some basic claims 
about identity.

>
> All I am saying is that peter williams' inability to do something is interesting but proves very little. (Your argument was that his inability to do something proved something)

Yes, his inability to complete QA using the consumer profile ultimately 
surfaces a bootstrap problem for WebID in its current form. Assuming 
WebID is seeking participation of end-users that match the consumer 
profile where "cut and paste" rules.

>
>> [SNIP]
>> The rest of your comments are simply unacceptable. I am not going to be part of threads carrying personal insults (directed at Peter or anyone else).
> The rest of the comments I asked you for a use case for what you want to put forward.
>
> Your arguments seem to be
>   - dereferenceable URLs are a luxury

Yes, they are and that's no secret. It's also the point I wanted @danbri 
to accentuate based on his travels and experience re. the Semantic Web 
Project in general and FOAF.

>   - There is a fundamental Name/Location problem on the web

No, the Name/Address ambiguity problem is specific to Linked Data which 
adds a new interaction and utilization dimension to the WWW. Currently, 
the WWW is generally used as an Information Space. Linked Data unveils a 
Data Space dimension. The fidelity of Linked Data HTTP based URIs as 
Names is a challenge for most commodity / consumer user profiles. They 
aren't in control of:

1. http servers
2. knowledge for making re-write rules
3. knowledge, experience, or interest re. name/address disambiguation.

>
> Neither of those are convincing to me, as stands.

You will find out one way or another, of that I can predict with 100% 
certainty. I've been around the block many times with Linked Data, I 
have many Linked Data customers, designed many products, and I know 
what's coming!

> Then I try to look at what you put forward as a solution, and I try to show that it seems to make an unnecessary triangulation that does not it seems bring much.

Reducing the luxury Linked Data tax is a lot re. de-referencable HTTP 
URI based Names.

> I am not the only person having trouble understanding what you are trying to do.
>
> You may be onto something, but it requires more development and clarity of language.

Fine, as per usual, I'll have it implemented, and then others can 
evaluate etc..

> So please use well defined vocabulary we understand, that is spec based, so that we don't have to guess what you are going on about all the time.

Don't do the "spec based" thing with me. sIA is in a spec. The rest 
boils down to relations and ontologies, and btw - wdrs:describedby has 
clearly defined semantics. It isn't my invention.

>
> Perhaps show us:
>
> 1. What you put exactly in your cert (written as n3, like I did)
> 2. What you put in each of the profiles and documents you are referring to
> 3. what the verification logic is that is being used.
> 4. what the use case is you are solving. Please describe the actors, their needs, and what they are going to do.
>
> Henry
>
>
>>
>>
>> -- 
>>
>> 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/
>
>
>


-- 

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








Received on Monday, 9 January 2012 16:41:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 9 January 2012 16:41:01 GMT