What does conformance to the recommendation mean?

[David-Chadwick]

The issue of conformance to the recommendation seems to be at the root of several issues, such as #293 and #282 and in fact all issues about Terms of Use.

So what do we mean by conformance to the VC standard? The W3C QA Framework can be found here:
https://www.w3.org/TR/2005/REC-qaframe-spec-20050817/

Copying from this document we have the following statements:

1. Conformance is the fulfillment of specified requirements by a product, process, or service.
2. A conformance clause is essential.
3. Good Practice 12: Write test assertions. A test assertion is a measurable or testable statement of behavior, action, or condition. It is contained within or derived from the specification's requirements and provides a normative foundation from which one or more test cases can be built.
4. Good Practice 7: Write sample code or tests.

Whether something is testable or not has been the subject of a lot of past debate in W3C and the conclusion is specified here
https://www.w3.org/wiki/TestableOrNot
which states
"A proposition is testable if there is such a procedure that assesses the truth value of a proposition with a high confidence level. Whether the confidence level is measurable and what confidence level is high enough depends on the proposition and its framework."

So when @jandrieu says "The specification should state what VCs can and cannot guarantee" this is not quite correct. It should be "what VCs can show is true with a high confidence level", which is not the same as a guarantee.

So, can we write tests to check if a verifier's code will accept a VC where the subject is the holder, or where the holder is not the subject, when a ToU states "Subject only". The answer in both cases must surely be Yes. In which case we can make conformance to this mandatory.

Can we write a test to check if a verifier will accept or reject a Prescription VC given to it by any holder. The answer is surely Yes. If we want to place constraints on this, for example, by inserting TermsOfUse in the prescription VC, can we still test if the verifier will accept it or not. The answer is surely Yes. Therefore we can make conformance to ToUs mandatory.

[msporny]

Therefore we can make conformance to ToUs mandatory.

Just because we can do something doesn't mean we should. This is the 11th hour and this discussion about ToU is eating up a great deal of time that could be spent on other items in the specification. The specification text is also suffering wrt. the amount of detail we are going into wrt. ToU and authorization.

With specifications, sometimes less is more, and given the current trajectory of the PRs and the text in the specification, I can't say that it's helping the readability of the specification.

I realize all of this is vague, so let me try to be a bit more concrete.

With my Digital Bazaar hat on - we would be a -1 to mandating that VCs are accepted/rejected based on ToU as we view those as advisory pieces of information. If we have a customer that decides that they want to ignore the ToU (for a good reason), then we would be put in the position of having a non-conforming implementation, which we don't want to do. We want to be 100% aligned to the specification and mandating that ToUs must always be adhered to will not allow us to meet our customers needs and be 100% conformant to the specification.

[David-Chadwick]

Terms of Use that are advisory only, are not terms of use. They are pieces of advice only.
Therefore ToUs that are not mandatory should either be removed from the specification, or renamed to something which more accurately reflects what they are, such as AdvisoryNotice.

[jandrieu]

All current terms of use that work today, that I know of, are legally enforced, not technically. Since conformance is technical and not legal, terms of use are--at the technical level--advisory only.

Attempts to create technically enforceable ToU are known as DRM, Digital Rights Management. DRM has proven to be an unsolved problem, potentially unsolvable. I don't think we should make the specification dependent on solving unsolved problems. If the advocacy for ToUs is to embed a DRM framework into VCs, I would formally object to that approach.

Alternatively, we could interpret conformance to the spec a matter of law. That would imply that the test suite actually tests the law, in some appropriate jurisdiction. This can't be done in a test suite and would require potentially years-long litigation on the merits of the ToU and the actual alleged usage. And would only apply in that jurisdiction and would be subject to subsequent case law overturning prior decisions and new legislation and regulation that changes the applicability and underlying legal framework. Hopefully it's clear that requiring a legal test for conformance is unfeasible.

Conformance should be limited to that which can be technical tested, without recourse to the jurisdiction or business rules of the verifier. Using a VC in a legally questionable manner cannot be the grounds for non-conformance as the law itself is an ongoing question.

[David-Chadwick]

@jandrieu Since there are no standardised VCs today, then there are no standardised VC ToUs today. So your argument above is somewhat spurious. Can you please respond directly to the example below, which I believe is a technically enforcable ToU. If you think it is not, then please say why it is not. Thankyou

Can we write conformance tests to check if a verifier's code will accept a VC where the subject is the holder, or where the subject is not the holder, when a ToU states either "The verifier MUST only accept this VC if it presented by the subject", or "the Verifier is prohibited from accepted this VC if it presented by a holder who is not the subject"

[msporny]

The specification only talks about document conformance in a normative fashion (as described in this issue):

#317

This position has achieved consensus in the group and as a result is the resolution to this issue. Closing.