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

Re: webid and bnodes

From: Stéphane Corlosquet <scorlosquet@gmail.com>
Date: Mon, 6 May 2013 15:30:49 -0400
Message-ID: <CAGR+nnFX17twxV7ARCFC4MRm9-XCXCGy7AowXHA5H+uzyvm-jw@mail.gmail.com>
To: Melvin Carvalho <melvincarvalho@gmail.com>
Cc: public-webid <public-webid@w3.org>
On Mon, May 6, 2013 at 3:12 PM, 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 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. 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. The profile document would then no longer have to include
the keys themselves, but their URIs. 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.

Received on Monday, 6 May 2013 19:31:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:54:43 UTC