rflechtner
commented
8 months ago In our original thread, @dlongley sketched out a possible solution that ticks boxes 1-3 by requiring jcs-based specifications to include the document context at the point of proof generation in the proof object, and using it to override the (possibly altered) document context at the point of verification. The idea, as far as I understood, thus is to replace the document's @context silently and implicitly during proof verification.
From what I can see, in order to make sure we hit requirement 4 as well, we will need additional checks in place. Simply verifying a document with the context replaced instead of the one to which the proof is attached would result in a situation where the @context values visible to the consumer of the secured document (e.g., a credential) are effectively unsecured and could be manipulated (e.g., by the credential holder), changing the semantics of the document in the process. This weakens the guarantees that the data graph as presented to a relying party is equivalent to the one originally signed. My suggestion here is that we additionally require that jcs-based proof schemes verify whether the context retained on the proof object is a subset of the context of the document to be verified. Because the @context property is defined as an ordered set, this means that:
- The document
@contextMUST contain all values contained in the proof@contextin the same order. - The document
@contextMUST NOT have any values preceding the values contained in the proof@contextbut those MAY be followed by additional values not contained in the proof@context.
Because context injection adds additional values to the end of the set, these conditions should always be met for incremental proof generation, failing only for cases where proofs are created independently and then added to a document, thus hitting all design goals 1-4. @msporny & @dlongley is this accurately representing the solution you had in mind? And would you agree that parallel/independent proof generation is out of scope?
Wind4Greg
msporny
After discussing challenges that context injection currently poses for combining with @msporny & @dlongley in a different forum, we've agreed this should be brought to the attention of the broader VCWG community.
The problem
Context injection is the practice of adding proof type related context references to a document's
@contextproperty prior to proof issuance and/or verification and both required by this specification (https://w3c.github.io/vc-data-integrity/#context-injection) as well as routinely done by implementations of other proof types. While this practice works for proof schemes that secure the underlying data graph instead of its JSON-LD representation (such as rdfc-based cryptosuites), it creates problems for schemes that work by securing the JSON representation (the document) instead, including all kinds of jcs based cryptosuites. The reason for this discrepancy is that adding additional values to@contextin this scenario does not alter the resulting document data graph because it only determines the mapping of proof properties and does not appear in the graph itself - but it does obviously change its JSON-LD representation. As a result, there are scenarios in which jcs-based proofs used in a proof set or proof chain become unverifiable.Example case
Consider, for example, a scenario where Signer A and Signer B subsequently add proofs to a document to form a proof chain. Signer A begins by adding a proof of type
DataIntegrityProofusing theeddsa-jcs-2022cryptosuite. As part of this, the URLhttps://w3id.org/security/data-integrity/v2is added to the set of@contextvalues prior to signing. Signer A then passes the modified document including the proof to Signer B, whose signer implementation is a little more dated and uses theEd25519Signature2020proof type. This now adds the URLhttps://w3id.org/security/suites/ed25519-2020/v1to the set of@contextvalues. The resulting document cannot be verified with the proof added by Signer A; removing the@contextvalue added by Signer B on the other hand results in the latter proof not being verifiable, as the terms it uses become undefined.Constraints & Solution(s)
I think it is imperative that such unexpected interference and the resulting brittleness of applications relying on this specification is prevented on the protocol level as far as possible, which calls for a solution to this issue before the current draft advances to a recommendation.
It is not immediately obvious though how this can be achieved if the solution is to realise the following design goals:
My hope is to start a thread here that leads to an agreement on a way forward that realises these goals as good as possible. In order to kick things off, I'll follow up with a suggestion made by @dlongley & @msporny in our original thread.