Re: webid and bnodes

On 14 May 2013, at 18:19, Melvin Carvalho <melvincarvalho@gmail.com> wrote:

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

It is up to the other specs to make the case for the re-use carefully. 
That's the point of specs. Each one tries to do one thing well. If those specs get wide acceptance, later
versions of WeBID might link to those specs in a note. Currently basing our work on "unexpected reuse" 
could just as well be premature complexitification.
 
> 
> 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?

The remote document is not more likely to be correct, it is _definitive_, ie: it is the _defining_ 
document. That is the core of what the architecture of WebIDs. Some documents are definitive 
others are not - even if both contain exactly the same triples. It is something that many  in 
the semantic web have in  failed to take into account, mostly because they have ignored
the importance of context -  which in the linked data space is related to the position of a 
graph in web space.

In the case of WebID authentication over TLS the authentication is hooked onto the 
WebID, not on the keyId. Somehow the keyid is not important in the verification procedure I think.
But I am not absolutely sure why yet. I think if the keyId were to be used at some later point, then
the definition of the key would need to be checked. 

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

Social Web Architect
http://bblfish.net/