Re: Signature in Wrong Position

On 18 January 2016 at 00:30, Henry Story <henry.story@bblfish.net> wrote:

>
> On 17 Jan 2016, at 22:54, Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>
>
>
> 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
>
>
> A few points:
>
> 1. It says "should" not "must".
>

Yes.  That's what we wanted.  "Should".


> 2. It depends on the circumstances on wether the public key is significant
> (there are use cases where it may not be)
>

I struggle to see a use case.  But for signatures we needed URIs.


> 3. WebID does not disallow URLs for keys: you are free to use them in your
> WebID Profile documents.
>

In theory yes.  But in practice people dont do this.  Yours doesnt for
example.


> 4. I have no problem with URLs for Keys: witness my implementation of
> HTTP-Signature on the client and the server
>     https://github.com/solid/solid-spec/issues/52 for SoLiD.
>     Perhaps you'd care to support that part of SoLiD since I am actually
> supporting a URL for a key there?
>     WebID-RSA which is currently listed in the spec there does not.
>

This is great!  But it took 5 years to get there.  In the mean time a whole
spec was created and implemented.


> 5. This has no bearing on this thread, so perhaps we can continue the
> discussion elsewhere?
>

Apart from the historical aspect, no, it's relevant to why your work on PKI
and this groups work on PKI diverged several years ago, and that bringing
up the concerns you raised, could have been much easier dealt with a few
years ago.  I think we agree, that the current spec is not in error, you
raise an interesting way of doing things tho.  It just may be a little late
now for people to change specs / implementations.

Agreed feel free to change title/list if you'd like to discuss further.


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