Re: webid and bnodes

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