- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Mon, 06 May 2013 15:45:44 -0400
- To: public-webid@w3.org
- Message-ID: <51880868.70208@openlinksw.com>
On 5/6/13 3:30 PM, Stéphane Corlosquet wrote: > > > On Mon, May 6, 2013 at 3:12 PM, Melvin Carvalho > <melvincarvalho@gmail.com <mailto:melvincarvalho@gmail.com>> wrote: > > I was going thru a few webid and I noticed that many public keys > are bnodes. > > Some consider this not best practice, and it also makes it harder > to reuse keys for signing, encryption, payments etc. > > Do you think there should be a line in the WebID+TLS spec saying > that the key SHOULD NOT be a bnode? > > > I think it would be nice to definitely consider this. The downside of > making them "SHOULD NOT be a bnode" is that we have to ensure these > URIs are dereferenceable if people are expecting to request these keys > directly. The WebID profile is no longer self-contained into one > single document. The question is, should each URI dereference to an > RDF document describing the key, or to the key itself. The key itself i.e, a URI should denote a public in a manner that distinguishes it from RDF documents that describe said key. > If it's the former, then we can simply use the WebID profile as is and > simply give then bnodes identifier. My feeling is that what we want is > the later, in which case we have to offer each key as a separate URI. Yes. > The profile document would then no longer have to include the keys > themselves, but their URIs. Yes, as an option. > The verifier would have to request the WebID profile and all the keys > (more HTTP requests and slower performance). Unless we find a way to > also bundle all the keys together in one document like the WebID > profile, but then one would need to logic to always keep that "bundle" > document in sync with the keys behind the URIs. > > Just thinking out loud at the moment, not leaning towards any > particular approach for now. If we keep this optional, we keep SPARQL crawling heuristics in the implementation details box. One immediate benefit of a an HTTP URI for a public key associated with a personal profile graph is that it enables binding of WebID and HTTP Signatures [1] (draft). Basically, you can then use the URI of a Public Key as the KeyID when working with HTTP Signatures. You could also do the same (re. HTTP Signatures) with a WebID but that adds a little intuition and entity relationship semantics cost to certain implementor profiles e.g., those with R-D-F reflux :-) Links: 1. http://tools.ietf.org/html/draft-cavage-http-signatures-00 -- HTTP Signatures Draft . > > -- > Steph. -- 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 Monday, 6 May 2013 19:46:11 UTC