Re: webid and bnodes

On 14 May 2013 18:01, Henry Story <henry.story@bblfish.net> wrote:

>
> 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.
>

Yes I understand this, but it limits unexpected reuse, which is one of the
attractions of linked data (and webid).  I wasnt saying to disallow bnodes,
just put a note in the spec to let people know there are disadvantages.  I
had a hope that webid could be used for payments, but this is in practice a
show stopper, because almost every WebID that I know (except Toby) uses
bnodes.


>
> 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 .
>

Seems an edge case, but I think the remote document is more likely to be
correct here?

Or does this come down to mirror claims and you have to decide which
document to trust?


>
>
> 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 <> .
>
> Henry
>
> Social Web Architect
> http://bblfish.net/
>
>