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

On 12/29/11 6:26 PM, Jürgen Jakobitsch wrote:
> 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.

What does "Cool URIs" actually mean? It means: > 1 level of indirection 
that abstracts you from changes to:

1. data location
2. data representation.

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

We just need to nail down the implications associated with the thorny 
issue of Name/Address disambiguation when using HTTP scheme URIs :-)

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

Servers should implement Linked Data axioms if they are Linked Data 
Servers. Clients do the same i.e., de-reference names and expect 
descriptor resources that are machine and/or human readable.

Kingsley
>
> @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