Open danfinlay opened 4 years ago
For extra context, the JOSE specification proposes a standard way of signing JSON data, but keeps the signature separate from the data.
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.
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?