Linked data security of non-core proof types

[clehner]

VC Data Model 1.0 requires a specific JSON-LD context (the Credentials v1 base context) as the base JSON-LD context for Verifiable Credentials and Verifiable Presentations. This base context defines the common terms expected to be used for VCs and VPs, and for certain types of proof objects. The proof types defined in the base context are: EcdsaSecp256k1Signature2019 (https://w3c-ccg.github.io/lds-ecdsa-secp256k1-2019/), EcdsaSecp256r1Signature2019, Ed25519Signature2018 (https://github.com/w3c-ccg/lds-ed25519-2018/), and RsaSignature2018 (https://github.com/w3c-ccg/lds-rsa2018). Because of the use of the @protected JSON-LD feature in the base context, the terms defined in the base context cannot be redefined later. This allows non-JSON-LD processors to use VCs/VPs with those four proof types, with confidence that terms such as issuer and verificationMethod expand to the expected IRIs. ssi relies on this feature for serializing and deserializing credentials and presentations, as it does not currently do JSON-LD processing except when signing and verifying the linked data proofs that use RDF canonicalization.

With proof types not defined in the credentials base context, such as JsonWebSignature2020 (https://github.com/w3c-ccg/lds-jws2020/) and EthereumEip712Signature2021 (https://github.com/w3c-ccg/ethereum-eip712-signature-2021-spec), VC issuers and verifiers cannot necessarily rely on the JSON terms expanding to the correct IRIs, but may need to do additional processing. The VC Data Model specification recommends for extensibility and semantic interoperability that new terms be defined in JSON-LD context that is published, so that it can be referenced with a URI in the @context property; that the expected ordering of the context URIs be specified, and that @protected be used. This should enable non-JSON-LD processors to safely use the extensions, including proof types: the signature suite could specify a context URI, and say the that the specified context URI must be used; then verifiers would not need to process the credential/document as JSON-LD, but could simply validate the correct presence and ordering of URIs in the @context array, and then could safely use the defined properties in the JSON credential/document and proof object.

Some proof suites have well-known context URIs defined via w3id.org. But they don't necessarily specify that implementations must use those context URIs. So requiring well-known context URIs for those would constitute limitating verifiability to a subset of possible uses.

ssi's current implementations of custom proof types don't require specific context URIs, and they are using JSON processing. This means it may be possible for proof property term definitions to be re-defined in JSON-LD context, or defined differently than the proof suite expects. This should be changed so that the JSON use of the terms is consistent with their meaning in JSON-LD. Possible solutions:

1. Require specific context URIs in the credentials/presentations/zcaps and/or proof objects, for the respective proof suites.
2. When verifying the custom proofs, after JSON-LD to RDF conversion, verify that the terms used in the proof object correspond with expected IRIs in the RDF. If the proof type does not already involve JSON-LD to RDF conversion (e.g. EthereumEip712Signature2021), the conversion could be added as an additional step, unless/until the proof type requires a specific context URI.

Option 1 may be simpler, but it depends on the respective signature suite specification to specify the context URI to use. As many do not, we currently have been using inline context definitions, which would not be compatible with requiring a specific context URI. Option 2 is the more general solution; it relies on JSON-LD processing, but the proof types mostly do so already, for RDF canonicalization.

A third option would be to do the struct serialization and deserialization with JSON-LD context; that would probably be a larger change.

[clehner]

Implemented "Option 2" in #241