Why is signature part of of the signed blob?

[danfinlay]

One thing that was very counter-intuitive to me upon reading the ocap-ld spec was that the signature proof field was within the blob which is presumably signed.

Obviously each ocap-ld capability isn't achieving some impossible circularly signed state, and so I assume this implies the proof field is appended to the object after signing, and is excluded before verification.

I just had to ask, why not use a parent object instead? Something like { proof, capability }, so that the two never collide?

[danfinlay]

For extra context, the JOSE specification proposes a standard way of signing JSON data, but keeps the signature separate from the data.

[dlongley]

There are a number of reasons for this that should be better explained in the Linked Data Proof specification(s) that OCAP-LD builds on. Some of those reasons include the underlying data model being a dataset (a collection of graphs) as opposed to a tree, whereby the "proof" contents are actually in a separate graph from the rest of the content. Understanding this is more accessible/obvious to those coming from an RDF/JSON-LD background and it should be made more clear in the appropriate spec and referenced from the OCAP-LD spec. Other reasons why Linked Data Proofs do this by default include improved composition support for "sets" of signatures from multiple parties whilst also enabling "chained"/"nested" signatures ...and for improved support with storing documents in document-based databases.

There's definitely a documentation shortcoming here and we should keep this issue open until it is resolved.