Re: Signature in Wrong Position

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.

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