Re: WebIDRealm

On 1/2/12 12:48 PM, Peter Williams wrote:
> If you want the subject field of a cert to associate (correctly) with a UI-representation, use the correct type in the SAN. One type someone defined yonkjs ago (albeit in microsoft-land only, and in the days before 2000 and X.509 got SANs formally) has an HTML in the cert, so its web friendly. Then, this cert extension provides the bit of HTML that makes the UI behave correctly. I've been using it to convey a bit of signed RDFa for a while now (in MSFT land, only)

Yes!

DN isA compound Key based on Object Addresses (URLs or Email Addresses 
courtesy of Hamer Stack patterns).

SAN isA composite Key based on Object Names.

Name / Address ambiguity remains eternally confusing.

As I stated earlier, the descriptor resource URL(s) could ultimately be 
in DN.
The descriptor subject Names in SAN.

Then we can play serious ball re. sophisticated policy based data access 
and controls i.e., assurances.

As is crystal clear to me, WebID is just a much simpler base, nothing 
wrong with that per se., as long as it isn't pushed as the nirvana for 
this deep subject matter.

As I said in earlier posts, as we move from simple to the more complex 
re. SPARQL, you should notice (if not obvious already) how SPARQL URLs 
can be used in DNs to expose the Idp space addresses for descriptor 
resources that describe one or more names in SAN. Basically you can 
construct a data space based on your knowledge of URIs in SAN via 
SPARQL. This includes making a mirrored claim. It could even go as far 
as making the claim mirror and signing said claim too, leaving you with 
signed claims in two places that are verifiable :-)

-- 

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