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

hi,

what i can tell from many discussions with customers is that
people are kind of picky about their uris. 
the "cool uri" meme is often the only thing of interest, no matter
what technical advantages there are.

besides that it would be an "if-then" situation in a spec which 
actually should adhere to the "foreach" principal.

i'd personally rather fix the issue parsing or server-setup wise.

@henry : i recommend : http://en.wikipedia.org/wiki/The_Mahabharata_%281989_film%29

wkr http://www.turnguard.com/turnguard

----- Original Message -----
From: "Kingsley Idehen" <kidehen@openlinksw.com>
To: "WebID XG" <public-xg-webid@w3.org>
Sent: Thursday, December 29, 2011 10:59:30 PM
Subject: 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







-- 
| Jürgen Jakobitsch, 
| Software Developer
| Semantic Web Company GmbH
| Mariahilfer Straße 70 / Neubaugasse 1, Top 8
| A - 1070 Wien, Austria
| Mob +43 676 62 12 710 | Fax +43.1.402 12 35 - 22

COMPANY INFORMATION
| http://www.semantic-web.at/

PERSONAL INFORMATION
| web   : http://www.turnguard.com
| foaf  : http://www.turnguard.com/turnguard
| skype : jakobitsch-punkt

Received on Thursday, 29 December 2011 23:27:31 UTC