Requirements around the @context proof property

[PatStLouis]

It was highlighted in #102 that the test vectors did not match the specification's algorithms.

Following the thread, I would like to raise an issue around the specific step which instructs issuers to include the @context property in their proof for the eddsa-jcs-2022 cryptosuite.

The test step in question reads
If unsecuredDocument.@context is present, set proof.@context to unsecuredDocument.@context.

I would like to discuss why was this step included as I understand there is a significant reason in relation with the ActivityPub work.

I understand it's a feature required when an issuer wants to add a proof set to an already secured document and wants to alter the @context value. I'm questioning why should this be a mandatory step for all issuers.

Following my comment:

I'm a bit torn on this requirement from the spec. Its a feature to support a very specific use case where an issuer might want to add it's own context to the proof in the case of a proof set. Its not normative and a vc without this step can verify perfectly well with the verification algorithm. I've implemented this cryptosuite without this step and I should be able to, as it meets all normative statements of the specification. A verifier shouldn't fail the verification because the base document has a context but the proof doesn't.

@titusz has replied:

I am confused. How is it not normative. I understand that section 3.3.1 clause 2 doesn't use RFC 2119 keywords (MUST, SHOULD, MAY, etc.). But it's part of a numbered algorithm in Section 3 which is explicitly defined as normative in Section 1.2 Conformance. If clause 2 is not normative then that would mean I could skip any of the algorithm steps an still conform?

Don´t get me wrong. I am agnostic on whether this step is meant to be normative or not but I think the spec should be clear about whether it is normative or not.

The conformance section reads:

Specifically, all relevant normative statements in Sections 2. Data Model and 3. Algorithms of this document MUST be enforced.

Some algorithms have normative statements, treating the whole algorithm as normative would defy the purpose of those normative statements. The create proof algorithm reads:

The following algorithm specifies how to create a data integrity proof given an unsecured data document. Required inputs are an unsecured data document (map unsecuredDocument), and a set of proof options (map options).

By omitting this step, a valid data integrity proof is still produced which can be verified using the Verify Proof algorithm.
It also doesn't prevent other issuers from leveraging this feature in subsequent proofs from my understanding.

I've not heard a compelling reason why this is a requirement, as including this step or omitting it both results in a valid data integrity proof. I would rather clarify this statement with something along the lines of:
If unsecuredDocument.@context is present, implementations MAY set proof.@context to unsecuredDocument.@context.

The inclusion or not of this step won't affect the verification algorithm, and is based on a specific requirement. If any of my understanding of the purpose of these algorithms is wrong, I would like for someone to point it out to me so I can correct my software. There is no verification step that warrants verifying that if the securedDocument has an @context, the proof must also have an @context.