- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Sun, 08 Jan 2012 18:07:20 -0500
- To: public-xg-webid@w3.org
- Message-ID: <4F0A21A8.8020007@openlinksw.com>
On 1/8/12 5:52 PM, Mo McRoberts wrote: >> What we need to get people to understand somehow is the fact that you can have a URL (a Locator) and a generic URI (Name) in a cert such that publishers can make descriptor resources for cert. subjects -- using URIs as subject names -- and then publish to network resources addresses identified using URLs. Doing this reduces publisher tedium inevitably introduced by Linked Data nuances re., de-referencable URI based names. > I asked previously that you post an example cert (don't worry about the key material, obviously) which shows what you mean — i.e., what things you'd put where and how you believe they should be processed. > Based on my reply to Peter, we will make a cert that just uses the less controversial Subject Information Access extension. The semantics of this cert. element covers exactly what I need i.e., a place for URLs that resolve to resources bearing directed graphs where attribute=value or predicate=object pairs coalesce around identifiers for the cert. subject, as placed in SAN . All this means is this: A publisher doesn't have to control an HTTP server en route to making a descriptor for the subject of an x.509 certificate. It means consumers can do exactly what Peter continues to try to demonstrate re. WebID and its compatibility with the basic consumer profile. Full Linked Data fidelity won't work for consumer adoption and exploitation of WebID. This is a fact for which I await (even challenge!) someone to refute in a demonstrable way. -- 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 Sunday, 8 January 2012 23:07:51 UTC