Re: Signature in Wrong Position

> 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 <mailto:henry.story@bblfish.net>> wrote:
> 
>> On 17 Jan 2016, at 22:27, Melvin Carvalho <melvincarvalho@gmail.com <mailto:melvincarvalho@gmail.com>> wrote:
>> 
>> 
>> 
>> On 17 January 2016 at 22:44, Henry Story <henry.story@bblfish.net <mailto:henry.story@bblfish.net>> wrote:
>> 
>>> On 17 Jan 2016, at 20:38, Melvin Carvalho <melvincarvalho@gmail.com <mailto:melvincarvalho@gmail.com>> wrote:
>>> 
>>> 
>>> 
>>> On 17 January 2016 at 13:55, Henry Story <henry.story@bblfish.net <mailto:henry.story@bblfish.net>> wrote:
>>> I was looking at the Linked Data Signatures document
>>> 
>>>   https://web-payments.org/specs/source/ld-signatures/ <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 <https://w3id.org/identity/v1>",
>>>   "title": "Hello World!",
>>>   "signature": {
>>>     "type": "LinkedDataSignature2015",
>>>     "creator": "http://example.com/i/pat/keys/5 <http://example.com/i/pat/keys/5>",
>>>     "created": "2011-09-23T20:21:34Z",
>>>     "domain": "example.org <http://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 <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 <http://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 <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 <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 <https://www.w3.org/DesignIssues/Axioms.html>

A few points:

1. It says "should" not "must".
2. It depends on the circumstances on wether the public key is significant (there are use cases where it may not be)
3. WebID does not disallow URLs for keys: you are free to use them in your WebID Profile documents.
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 <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.
5. This has no bearing on this thread, so perhaps we can continue the discussion elsewhere?

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