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

All,

When using an (X)HTML resource as the bearer of a claim that associates 
a WebID with a Public Key in some IdP space, we need to use # style of 
URI in the X.509 Cert. SAN. Adopting this approach enables exploitation 
of *implicit* Name / Address disambiguation re. HTTP scheme URIs.

The above assumes that the descriptor (description) resource above 
consists of a machine and human discernible eav/spo based directed graph 
pictorial where entity=value or predicate=object pairs coalesce around a 
subject that's unambiguously named using a # based HTTP scheme URI.

Peter:

I assume, that when you adopt the approach outlined above, you currently 
end up with verification failures when using the verifiers from Henry 
and OpenLink? If true, this is a function of the fragment identifier 
being passed across the wire as part of the HTTP payload generated on 
the Windows platform, a legacy issue from spec confusion.

Solutions:

1. Use slash URIs -- problem is they won't work for your publishing 
model since you don't control the HTTP Server  e.g., when you make you 
claim via a blog post

2. Use hash a hash URI -- but this requires proper handling of # URLs 
(Addresses) on the part of the Linked Data Server (wherever this shows 
up in the processing chain).

Right now, I am unclear as to how you fail while having # URIs in the 
SAN of your X.509 Certificate that resolve to a descriptor resource 
where # URI is used as the descriptor subject, when presented to our 
WebID verifier. I can understand how it would fail if there is a proxy 
in the mix that leads to the # URI being treated as a # URL re. across 
the wire transmission which simply introduces the need for a server rule 
for # URLs (which don't exist typically).

-- 

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 Thursday, 29 December 2011 22:00:06 UTC