Re: WebID equivalence

Summary: Kingsley, instead of trying to fix non existent problems because Peter Williams says he has a problem, we need to work out what his problem is. I for one told him that I was looking into this but that I was first resting for the Xmas vacations. Notice how he kept banging on about this all through the holidays irrespective of the holidays, as if an issue could fix itself if he kept speaking about it. So now the holidays are over, I'll look into it. Let's get to the root of his problem before we go on more and more crazy hypothetical solutions to what may not be a problem at all.


On 4 Jan 2012, at 03:30, Kingsley Idehen wrote:

> On 1/3/12 8:22 PM, Mo McRoberts wrote:
>>> It seems that's only the case when it matches your preferences, unfortunately. Once there's deviation you end up distorting first. I still can't believe your interpretation of my suggestion re. Addresses in CN and Names in SAN.
>> That's exactly how I interpreted your suggestion, too. Your description isn't very clear at all.
>> 
>> Please give an example describing exactly what you're proposing goes where in the certificate.
>> 
> 
> I am going to try one last time.
> 
> Problem:
> de-referencable URIs serving as Names is a luxury for all practical intents and purposes.
> de-referencable HTTP URIs introduce a problematic Name/Address ambiguity that makes Linked Data exploitation mercurial due to the httpRange-14 imbroglio.

There is no imbroglio. Just a bunch of people who have nothing to do counting the number of angels on a pin. http-range-14 is a non issue, that people like to pull out when they ran out of other things to speak about, or when they want to detract from some other issue, as it they can always count on some people to get into the discussion. It is used by those who wish to undermine the linked data web, by confusing its participants. If I were you I'd stay clear of this discussion. Certainly this is not the list to go on about it.

> 
> Bearing in mind the realities above,

No reality above, just wasted time. So the below is of extremely fragile theoretical use, with no interesting practical applications, as we will soon see. In fact not only is it of dubious theoretical value, it would make for bad UI.

> and their effects on folks that attempt to develop WebID applications, I was hoping we could see utility in doing the following (as an option not a replacement):
> 
> 1. Use the CN as an option for holding Addresses (HTTP or other Schemes e.g., Email Addresses) -- this means verifier is capable of optionally implementing their own resolver, this is what Webfinger delivers for acct: and mailto: scheme URLs, for instance

Practically a bad idea. Most browsers show the CN to the user . You can see this in the picture here:

  http://www.w3.org/wiki/Foaf%2Bssl/Clients/CertSelection

The only thing that would make sense there would be to put an e-mail looking address there. But why bother opening yourself up to potential spam, when you can just put your name there and some qualifier.

What would be interesting to research would be if other parts of the DN appear in the UIs that we should let people know about.

On the other hand if you put a URI in there then you really have confused the end user, and completely walked into the trap set out by the web finger folk. For they will say the only name people remember is the e-mail address.

> 
> 
> 2. Allow (meaning an option) URI based Names (including those that don't resolve) as WebIDs in SAN -- when the URI isn't of the resolvable kind, it means the subject description is de-referenced via the Address in the CN .

-1. I have no idea why you think this is a good idea. We have 20 implementations that work with SANs. 

So here you have a proposal that gains you nothing we don't already do in order to solve a non existent problem that people who try to undermine Linked Data bring up in order to sow confusion. It's working with you it seems. Watch out.

> 
> This just means you have Addresses as pointers to data objects.
> And Names as Object Identifiers.

To solve some non issue, that you express in a non standard vocabulary that nobody agrees on.

> 
> An HTTP URI based Name combines makes deft us of the Name and Address roles and functionality of URIs, but that comes a the cost of intuition and the introduction of Name/Address disambiguation confusion and arguments as exemplified by httpRange-14.
> 
> The Argument:
> 
> Henry continues to claim that constructs like this are wrong re. X.509:
> 
> 1. Subject: C=MY, ST=STATE, L=CITY, O=ONE INC, OU=IT, CN=www.example.com
> 2. Subject: C=US, ST=Maryland, L=Pasadena, O=Brent Baccala,
>                OU=FreeSoft, CN=www.freesoft.org/emailAddress=baccala@freesoft.org
> 3. Subject: C=US, ST=Maryland, L=Pasadena, O=Brent Baccala,
>                OU=FreeSoft, CN=MyOrganization Literal Label/emailAddress=baccala@freesoft.org .

I am not sure if those are allowed or not, if they parse or what their use is. How does the above look in the UIs of each of the browsers, in the cert selection box?  Have you looked at that?
> 
> 
> My counter:
> 
> They aren't wrong. And they provide a solution to the Name/Address ambiguity problem that comes with Linked Data when using HTTP URI based Names.
> 
> As always, I am bringing attention to options that lower the barrier of entry re. WebID exploitation. Unfortunately, Henry is writing code and thinking about parsers first. That cannot be the prime concern here.

No, I am thinking about User Interface, and standards. By inventing the least possible we can leverage as much work as possible out there. As soon as you invent a way of superposing semantics on other ways of doing things you create confusion - which is bad for linked data - and you create security holes. Watch the video "The science of insecurity" to see how doing that creates security holes

  http://www.youtube.com/watch?v=3kEfedtQVOY

The reason we are working with clear semantics is because this is a foundation of good security. Undermine the semantics and you undermine your security claims with it too. 


> 
> Another way to grok the problem I am trying to resolve is the current state of affairs re. Peter's attempt to simply get consistent verification behavior across all WebID verifiers.

Ah, ok. I see now what is driving you.  But that's a different issue. We have not at all worked out what Peter's problem is. So we first need to locate his problem, then see what the issue was, not fix whatever problem we can think of.


> Sitting at the root of what seems to be a mercurial pursuit is the same old Name/Address ambiguity issue since HTTP URI based Names are implicitly unintuitive albeit extremely powerful.
> 
> I desperately hope this is clearer.

It is clearer. Let us solve Peter Williams' problem first. My suggestion, try to improve your test suite, and keep a log of everything that is going on your server when Peter Williams logs in: keep all the source received and the document sent to him. Then you have all the data locally and you can see where the issue is appearing.


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/

Received on Wednesday, 4 January 2012 11:04:14 UTC