Re: How To Handle WebIDs for (X)HTML based Claim Bearing Resources

On 1/2/12 5:55 PM, Peter Williams wrote:
> I learned DN theory the hard way (from reading the code of an  infamous resolver) that then did authn and authz (using an ACL based (IBAC) model akin to what I see in WAC). And of course, we have the author of "Permis" on the team.
>
>
>
> Remember the Name in the subject of the Cert is more than a DN since it can contain AVAs that are not distinguished (and not part of the composite key). The only way to know which is which (and which was a human hint for DISPLAY) was to de-reference (and no resolver exists, any more).
>
>
>
> The number of folks who do this correctly these days is nil (since even though who could, dont). The correctness issue is irrelevant. The Names/DNs in certs subject don't point to Directory objects any more. As Henry uses them (and everyone else uses them, from Netscape;s quick and dirty coding of certs onwards), its just a bag of strings, with a tag on the front of each. Thats it.

Yes, it doesn't have to be that way. Addresses resolve to resources 
(data object descriptors). Names identify data objects. Thus, we can use 
the DN correctly. That's ultimately the only way to achieve loose 
coupling of data object names and descriptor resources. You've already 
setup the basic showcase:

1. SPARQL URL as part of the combination of components in the DN 
(basically compound sense) -- this is how you also leverage the URL 
shortener without producing a broken description graph

2. URIs in SAN that are described by the SPARQL URL (which can be a 
CONSTRUCT rather than DESCRIBE query).

The Certificate holds the claim: holder of this Certificate has a 
descriptor at an address. This descriptor is comprised of a description 
oriented directed graph where attribute=value or predicate=object pairs 
coalesce around one or more URIs in the certs. SAN, explicitly or 
implicitly (courtesy of inference context).


>
>
>
> About the only place I know that proper identity semantics are retained in X.509 is in the OTHER-NAME "UPC" SAN type, defined by Microsoft, where the formal semantics have to work properly (becuase its tied to the trust model of kerberos, anbd kerberos-protoected identity endpoints). But, such is not the web (being pure enterprise).

Well what's good for the enterprise (local area network based Webs i.e., 
intranets) is also good for extranets and the Internet :-)

> You only see it in advanced security, including SSL used in SIP phone registration (where digest auth over SSL needs to protect against MITM) so the secure RTP tunnels (a variatn of TLS record layer) is not falsey keyed by an spook, wanting to listen in to VOIP/SIP.
>
>
>
> Now, that was unfair of me, as I see US here trying to do "proper identity semantics" in X.509, with the URI form.

Yes, this is the goal. Leverage URI abstraction and ride the X.509 
standard.

Naturally, we have to thread carefully re. goals of WebID spec., which 
is about making a simple base from which higher level innovation can 
blossom following successful bootstrap.


>
>
>
>
>
>
>
>
>
>
>
>
>
>    		 	   		
>


-- 

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