Re: Matter of DN and what's possible

On 1/9/12 12:11 PM, Henry Story wrote:
> On 9 Jan 2012, at 17:40, Kingsley Idehen wrote:
>
>> 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).
> But people with those profiles will never be bothered about WebID at all in a technical way.

But that's where you are mistaken.

People are always interested in managing their identity.

WebID already simplifies the process of x.509 certificate generation 
(the hurdle of yore due to CA network dependency).

>   They will only be interested if Wordpress, BlogSpot, etc offers it to them in a nicely integrated way.

And who are we going to convince the companies behind those products to 
adopt WebID?


>   Everyone who at this stage is interested in WebID will be people with a modicum of technical know how.

No, and it doesn't have to be so.

This is why you find Peter's experiments problematic. You assume the 
profile doesn't exist, but it does. People do plumbing on the Web. Its 
the basis of the Blogosphere, for instance.

>   Such as people who have their own blog and people who are developers for BlogSpot or WordPress or Identica, and so who know how to do things technically and who do control an http server.

HTTP server control is a point of weakness in the system. The info card 
should be decoupled from critical control points of that nature. This is 
another fundamental aspect of Peter's experiments.

>
> There will be some users such as  bloggers that will be able to add html to a blog to put their webid there. In a few months when clarity as to microdata/rdfa is made, they won't even have to have problems with mime types.

There are billions of blog pages on the Web made by people that cut and 
past HTML into the editors of these tools. They are renting idp space 
from these platforms. It doesn't just apply to blogs, it applies to all 
aspects of Web 2.0 and its SaaS deployment model.

>
> There is some cut and paste these people will do, but those are early adopters.

Yes, and their profile is consumer. They are the same early adopters 
that bootstrapped the Web, Blogosphere, and what potentially comes next 
re. portable info cards that facilitate verifiable identity .

>   We can make life a bit easier for those early adopters, but I don't see your proposals doing that. Or at least I don't see how it does, and whatever you seem to be saying seems to be done more easily some other way.

Please give me an example of an easier way.

>
>>>>> 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,
> Well  I prefer your use of Subject Information Address extension to your previous attempts to put that information in the DN.
> So there is progress here.

But haven't established the fact that sIA is already about veering away 
from the more controversial (but valid) DN suggestion.

>
>> 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.
> yes, good that  we moved away from trying to put this in the CN. But remember how adamant you were about this a few weeks ago.
Yes, and there's the point you miss about me. Nothing is cast in stone. 
As I receive feedback, I process, experiment, and arrive at new 
conclusions. My only constant is the pursuit of pragmatic solutions to 
real problems. I don't do dogma.

I want to fix the LInked Data luxury tax, and I don't really care how 
many ways it can be achieved as long as it is addressed. That's what I 
do. I want to solve problems and kill off bootstrap hurdles.


>
>> 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.
> The QA he has done recently is good. If one looks at his attempts as attempts to break WebID then they are interesting.

He isn't trying to break WebID. He is giving the spec QA with a specific 
profile in mind.

>   It's just that I would not go from that to trying to jump to conclusions about us needing to change the protocol. He is just looking for corner cases.

"deceptively simple" architecture is resilient to corner cases. That's 
the essence of the aforementioned principle. If AWWW wasn't "deceptively 
simple" WebID wouldn't even have a chance in hell of happening.

>
>> Is this effort solely about implementing WebID rather than actually testing its practical utility via user profiles?
> I don't have a problem with testing.
>
>
>>>   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.
> Well he has shown that many blogging services make it difficult to add any type of markup.

He is showcasing the problem that will befall early adopters that live 
in the world of "cut and paste" .

>   Part of the reason for that is because of javascript's ability to take any freedom given to users and make use of that to create security holes. That is because javascript is a turing complete language of course and so makes security analysis impossible.

JS shouldn't be in the conversation. We are talking about the WWW of 
Linked Data. This is about self-describing data objects and their 
descriptor resources.

>
> [snip: enough speaking about Peter Williams, right? he manages to put himself in the headline of most threads here]
> [snip: on the name/uri so called ambiguity which is too general to be of interest here]
>
> Anyway, there is some kind of use case you seem to want to put forward about people who can't get URIs. Why not just offer them a service to give them a URL then on Virtuoso?

That's back to Peter's analogy about the groom in church waiting for the 
bride. That side of the equation has been solved eons ago. This is not 
about that at all. This is about a solution that is truly open, period!

>   All you need to do is make a service with a nice and very easy UI.

See my comments above. What we are doing commercially is really 
irrelevant to the WebID spec.
>
> And otherwise you still would need to answer 1,2,3 below.
>
>>> 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.

Why bother with all of that when I can dump a resource at an address and 
ACL protect it using the WebID verification protocol. Then demonstrate 
how others can simply attain access to the said resource via "cut and 
paste" driven info card construction etc..

Of course you can de-reference the graphs in my cert and explore the 
semantic fidelity of relations in the descriptor resource. And when 
there isn't a de-referencable URI in SAN, you can follow the URL in sIA 
and see what the graph offers.

FWIW -- all of this works with Webfinger support in our verifier 
already. The sIA just introduces yet another result  to the same result 
re. removing dependency on HTTP URI based Names re. WebID and its 
verification protocol.

>>>
>
>


-- 

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