Re: Signature in Wrong Position

On 17 January 2016 at 23:47, Henry Story <henry.story@bblfish.net> wrote:

>
> On 17 Jan 2016, at 22:27, Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>
>
>
> On 17 January 2016 at 22:44, Henry Story <henry.story@bblfish.net> wrote:
>
>>
>> On 17 Jan 2016, at 20:38, Melvin Carvalho <melvincarvalho@gmail.com>
>> wrote:
>>
>>
>>
>> On 17 January 2016 at 13:55, Henry Story <henry.story@bblfish.net> wrote:
>>
>>> I was looking at the Linked Data Signatures document
>>>
>>>   https://web-payments.org/specs/source/ld-signatures/
>>>
>>> I am not sure if this is the right list to discuss this.
>>>
>>> I am really keen to have something like this to work, and I like
>>> most of it off the bat. But looking a bit closer I noticed what
>>> I think is a serious error that has an easy fix though.
>>>
>>> The mistake is to put the signature *inside* the graph.
>>> Take example 1:
>>>
>>> {
>>>   "@context": "https://w3id.org/identity/v1",
>>>   "title": "Hello World!",
>>>   "signature": {
>>>     "type": "LinkedDataSignature2015",
>>>     "creator": "http://example.com/i/pat/keys/5",
>>>     "created": "2011-09-23T20:21:34Z",
>>>     "domain": "example.org",
>>>     "nonce": "2bbgh3dgjg2302d-d2b3gi423d42",
>>>     "signatureValue":
>>> "OGQzNGVkMzVm4NTIyZTkZDYMmMzQzNmExMgoYzI43Q3ODIyOWM32NjI="
>>>   }
>>> }
>>>
>>> In short: Signatures should be external to the graph, since that is the
>>> object
>>> of the signature. By placing it inside the graph as above the problem is
>>>
>>> 1. the algorithm needs to remove elements from the signed graph
>>> 2. The algorithm won't be able to cope with alignement of ontologies
>>> such as
>>>   a different relation being discovered to be owl:sameAs the :signature
>>>   relation above. If another such widely used vocabulary is found, or
>>> perhaps even
>>>   if the current vocabulary is extended then the signature verification
>>> systems won't
>>>   necessarily be able to understand to remove those relations too.
>>>
>>> It is much better to put the signature outside of the graph. Then
>>>
>>> 1. The algorithm won't need to contain any condition about removing any
>>> relation
>>> which will be a lot better for large graphs, and speed up verification.
>>> 2. New relations could be found or the vocabulary could be extended
>>> without changing
>>> the signature verification algorithm.
>>>
>>> Another way to think of this is that a named graph can always be mapped
>>> to a literal.
>>> ( This is why one can think of named graphs as already implicitly
>>> contained in RDF/XML )
>>> Signing documents is always external to the document in those
>>> circumstances.
>>>
>>
>> I think it depends on the use case.
>>
>> For LinkedDataSignature2015 the use case is so sign a canonical form of a
>> graph pointed to by a subject.
>>
>> You could also imagine another algorithm that signed named graphs, I dont
>> think the two are mutually exclusive.
>>
>>
>> There should be no difference in the use cases.
>>
>> Each system has pros and cons, but if you canonicalize things well, the
>> problem goes away, I think.  I think the way things are done currently
>> reduces complexity, which in turn, increases adoption.
>>
>> For example, looking at your webid, you have a key in there, but it is
>> unnamed ie a blank node.  This makes it impossible to do signing.  That is
>> one of the reasons that work on WebID and work on web signatures diverged.
>>
>>
>> You mean you can't refer to the key from outside the graph with a URI
>> because it is a blank node? True, but that's not a problem for
>> signatures. You can for example add the public key in the signature.
>>
>> {
>>   "@context": "https://w3id.org/identity/v1",
>>   "title": "Hello World!",
>>   "signature": {
>>     "type": "LinkedDataSignature2015",
>>     "creator": { "cert:modulus": "DAB9D1E941F6F8...",
>>                       "cert:exponent": 65537 }
>>     "created": "2011-09-23T20:21:34Z",
>>     "domain": "example.org",
>>     "nonce": "2bbgh3dgjg2302d-d2b3gi423d42",
>>     "signatureValue":
>> "OGQzNGVkMzVm4NTIyZTkZDYMmMzQzNmExMgoYzI43Q3ODIyOWM32NjI="
>>   }
>> }
>>
>
> Well that wouldnt work, as you dont know what kind of key it is.  But I
> guess going off topic.
>
>
> you actually do as it is implied by cert:exponent that the blank node is a
> cert:RSAPublicKey.
> See the online documentation https://www.w3.org/ns/auth/cert#exponent
>
> But even if that had not been specified, I am sure you can see that would
> just be a minimal step to
> add the type.
>
>
>
>>
>> Anyway, that's neither here nor there. The question was one of where
>> signatures should go: inside the graph or outside. One can
>> put the signature outside the graph with keys too, just as one can if one
>> uses URIs to identify the key.
>>
>> This is not something that affects any use cases. It's a question of
>> simplicity of algorithms.
>> It was pointed out in private conversation that the reason that this
>> decision may have been made is because the other
>> way around is less easy for beginner coders to get right for some reason.
>>
>
> Makes sense.  I do think the current formulation works, and is not in
> error.  There's just different ways of doing things.
>
>
>>
>> My Json-LD is not so good. In N3 ( https://www.w3.org/2000/10/swap/Primer
>>  )
>> What would it look like with the signature outside of the graph?
>>
>>
>> The convenience of using (which actually you argued for, and manu and
>> others argued against) bnodes comes at a cost.  The cost in this case was
>> to have two different communities working on liked data PKI solutions,
>> neither with really a lot of resources.  So bear in mind there's always a
>> trade off between convenience, utility and generalization.
>>
>>
>> WebID does not disallow URIs for keys, as should be clear from reading
>> the spec, and just from basic RDF principles. That point
>> was made a few times on the webid mailing list.
>>
>
> Not really, using bnodes here is a serious anti pattern.  This is axiom 0
> of the web.  Anything of significance should be given a URI.  This mistake
> was one reason signatures have been developed independently.
>
>
> That's what some folks say. Many who have been working in the LinkedData
> space for a very long time don't agree.
> BNodes are part of RDF, available in JSON-LD, Turtle, Trig, RDF/XML,
> etc... all of which are used in the LinkedData space,
> and there are many use cases where they are very useful.
> But yes, this is completely off topic.
>

Axiom 0a: Universality 2

Any resource of significance should be given a URI.

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


>
>
>
>>
>>
>> Not sure it would be correct to argue this is an error, simply a design
>> decision.
>>
>> Work on signing other structures I think is also welcome, but maybe
>> there's not (yet) enough use cases?
>>
>>
>>>
>>> Henry Story
>>>
>>>
>>>
>>>
>>
>>
>
>