- From: Stéphane Corlosquet <scorlosquet@gmail.com>
- Date: Mon, 6 May 2013 15:30:49 -0400
- To: Melvin Carvalho <melvincarvalho@gmail.com>
- Cc: public-webid <public-webid@w3.org>
- Message-ID: <CAGR+nnFX17twxV7ARCFC4MRm9-XCXCGy7AowXHA5H+uzyvm-jw@mail.gmail.com>
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. -- Steph.
Received on Monday, 6 May 2013 19:31:16 UTC