W3C home > Mailing lists > Public > public-webid@w3.org > May 2013

Re: webid and bnodes

From: Henry Story <henry.story@bblfish.net>
Date: Tue, 14 May 2013 18:01:46 +0200
Cc: public-webid <public-webid@w3.org>
Message-Id: <B792562F-3CB1-44E1-B82F-4BF15534D39B@bblfish.net>
To: Melvin Carvalho <melvincarvalho@gmail.com>

On 6 May 2013, at 21:12, Melvin Carvalho <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'd say that specs on signing, encryption, payments etc. should if the use case is correct 
make that requirement on keys. WebID over TLS does not need this requirement, so it is not
for us to make it, we'd have not justification to do so.

The issue for WebID over TLS is rather something else which we have not considered, which is if the
key URI is in a different document from the WebID profile. There the question should be if it is a requirement
to dereference the remote URI to get the key.  

We have two cases.

A: The key is in the same document

 <#me> cert:key <#key> .
 <#key> cert:modulus "ae23..."^^xsd:hexBinary;
              cert:exponent 65543 .

B: the key is in a remote document

 <> cert:key <remote#key> .

C. they key is in the remote document but the local document also describes the key.

 <remote#key> cert:modulus "ae23..."^^xsd:hexBinary;
                         cert:exponent 65543 .

Case A is covered by the current spec.
I don't think we mention case B: it clearly would require dereferencing the <remote> document .
But does case C require dereferencing <remote>, and getting the relations there, or can one rely on <> ? Intuitively one can
rely on the information in <> .


Social Web Architect

Received on Tuesday, 14 May 2013 16:02:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:05:51 UTC