Re: WebID equivalence

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.

Bearing in mind the realities above, 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


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 .

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

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 .


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.

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

-- 

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 Wednesday, 4 January 2012 02:33:46 UTC