- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Thu, 29 Dec 2011 16:59:30 -0500
- To: WebID XG <public-xg-webid@w3.org>
- Message-ID: <4EFCE2C2.9040105@openlinksw.com>
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
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Thursday, 29 December 2011 22:00:06 UTC