Re: Signature in Wrong Position

On 2016-01-18 01:31, Nate Otto wrote:
> Interesting thoughts, Henry, Melvin, & Anders
>
> One of the advantages of embedding the signature in the object that was signed is that it makes the nesting of multiple signed objects much simpler. When in a signed object, you want to reference another signed object, the structure of the graph is exactly the same as if you were including an unsigned object. There are no additional wrapper layers.

Nate,
that was close to 100% the motivation for JCS (JSON Cleartext Signature).

Anders
https://cyberphone.github.io/openkeystore/resources/docs/jcs.html

>
> Perhaps there's a cleaner way to do this, but I'm expecting signatures outside of the signed content to look something like the second of these two examples, where the current proposed Linked Data Signature spec would look like the first:
>
> {
>     "@type": "OuterDocument",
>     "inner": {
>         "@type": "InnerDocument",
>         "signature": {...}
>     },
>     "signature": {...}
> }
>
> vs something like:
>
> {
>     "@type": "SignedDocument"
>     "signedValue": {
>     "@type": "OuterDocument",
>         "inner": {
>             "@type": "SignedDocument",
> "signedValue": {
> "@type": "InnerDocument" },
> "signature": {...}
>             }
>         }
>     },
>     signature: {...}
> }
>
>
> It seems like 1) new overhead in terms of new class/property just to handle the signature mechanics, and 2) "inner" no longer can be assumed to point to an "InnerDocument", it could now be either an "InnerDocument" or a "SignedDocument". I get the sense that many vocabularies rely on a particular property name pointing to a node of a particular class, and putting another wrapper in between those layers would cause problems with the meaning of the relationship.
>
> At first glance, as a consumer of nested signed documents, I would want to verify the signatures of different pieces as a first step, and then if I trusted the signatures, I would want to work with the document directly as a second step.
>
> Nate
> Badge Alliance

Received on Monday, 18 January 2016 06:08:37 UTC