Can the signature value contain encapsulated data?

[indrajra]

Is there any design philosophy in the LD-signature suite, that states the original payload must be or must not be encapsulated as part of the signature value? Any views on it is much appreciated.

[dlongley]

LD proofs (include LD signatures) do not mandate that the original payload be included verbatim -- leaving this up to individual signature suites to define. Of course, the original payload must be included in some way (via some lossless transform) or it would not be protected.

The signature suites most commonly in use today (e.g., RsaSignature2017, RsaSignature2018, Ed25519Signature2018) use a canonicalization algorithm to transform the payload (and any additional signature parameters) to a specific byte stream for signing or verifying. Those suites require that 100% of the original payload (and any signature parameters) be included in the canonicalized data that is signed -- but without requiring that exact signed byte stream to then be attached to the output like it must be with, for example, a JWT (JOSE Web Token). This allows for the data to be represented using other syntaxes, provided that, when canonicalized, it always returns to the same form that was signed.

An alternative, compliant signature suite could be created that included the entire original signed byte stream without modification, but there hasn't been a demand for that -- largely because there has been a demand for the opposite as it allows for better composition and more flexible storage options (e.g., in document or graph databases).

[indrajra]

Thanks @dlongley for the detailed explanation; Appreciate it. Marking the issue as resolved with this info.