Re: webid and bnodes

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

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

Been thinking about this a little more:

"Each one tries to do one thing well" -- 100% agree!

I think doing one thing "well" is to obey the axioms of the web.

http://www.w3.org/DesignIssues/Axioms.html

[[
Axiom 0a: Universality 2

Any resource of significance should be given a URI.
]]

1. *If* a public key is a resource of significance then it seems in line
with the axioms to encourage the use of a URI (tho this cannot be forced).
Most WebID+TLS profiles currently do NOT obey this axiom.

2. *If* a public key NOT a resource of significance, it does not matter,
and the spec can stay as is.

But how and why is this determination to be made?


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