Re: Matter of DN and what's possible

On 9 Jan 2012, at 18:44, Kingsley Idehen wrote:

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

yes. it removes the CA trust issue, and the limitation in the number of client CAs available. Now every web site can be a
CA.

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

If you read a bit further you'll see that I say people with a modicum of technical knowledge.

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

Peter Williams who claims to have been working for Verisign, and been in the tech industry for 20 years at least, who like XRI and finds ASN.1 better than XML is now put forward as someone with no technical know how?

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

He ended up being able to publish his card. The restrictions we have are the same as the restrictions webid had. And see how far they got with technology that was a lot less user friendly!



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

yes. those are early adopters with usually a bit of technical knowledge as I said above. They are not the mass market.

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

How can I give an easier way than what you propose, since I don't understand what you propose, and you refuse to write it out clearly, by showing what information goes where?

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

well you are improving.

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

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

IF he could break webid that would be good to know. The job of a QA is to try to break things.

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

so...

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

And yes. Ok so we need to look more at these early adopters. 

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

I am telling you why there are these restrictions on what you can do in html. It helps to understand where the restrictions come from.
> 
>> 
>> [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.

Well what does the SIA point to? A URN perhaps? Otherwise how do you solve the problem of the "luxury of URIs"?
And if it is a URL then why is that not just the place of a WebID then?


> 
>>>> 
>> 
>> 
> 
> 
> -- 
> 
> 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 18:11:12 UTC