Add conformance classes to specification.

[msporny]

This PR attempts to address issue #159 by defining the conformance classes that are relevant to the specification.

---

Preview | Diff

[TallTed]

Minor but important

[iherman]

I am bothered by the terminology used around "data models", like:

A conforming secured document is any concrete expression of the data model that follows the relevant normative requirements in Sections 2.1 Proofs, 2.2 Proof Purposes, 2.6 Contexts and Vocabularies, and 3.1 DataIntegrityProof.

Reading the term "data model" may set the expectation of some normative words about what our data model is for this document. However, by going to, say, §2.1 Proofs, there is "just" a set of properties defined for proofs, without any reference to any well-defined data model. The generic introduction to §2 Data Model:

This section specifies the data model that is used for expressing data integrity proofs, controller documents, and verification methods.

is also void of any definition.

I realize, and I agree, that the document purposefully avoids making a reference to VCs or VPs at this point (the relationships are detailed in §2.5) because the DI can be used more generally (e.g., for DID documents). But I wonder whether it is not appropriate to say that the Data Model of DI relies on what is described as "Claims" in the VCDM specification in VCDM §3.1 Claims (which is a simple version of subject-property-values relationships). Whether the DI spec would just simply refer to VCDM §3.1, or take over the same text with diagrams, is an editorial choice. (DRY principle would dictate to use a reference, on the other hand that section of VCDM is set as non-normative, which may not be appropriate here.)

[dmitrizagidulin]

👍 seems like a decent starting point. I agree with Ivan, though, that just saying 'the data model' might be somewhat ambiguous.

[msporny]

@iherman and @dmitrizagidulin wrote:

I am bothered by the terminology used around "data models"

I have raised issue #165 to track this concern. I understand the trepidation, but also didn't want to create a big debate around what the data model is for data integrity. One could argue that it's a version of INFRA that maps cleanly to both JSON-LD and JSON... or, one could argue that it's JSON-LD with special rules if you don't want to use a JSON-LD processor and just operate using JSON tooling. Both of those statements are true, and what we're probably missing is general guidance around "Gaining the benefits of JSON-LD without using JSON-LD Processors."

How useful it is to go into these depths is questionable from an implementer standpoint... do they need an answer to this question to write an implementation that is conformant? No, I don't think they do. :)

Sure, it might be helpful to some implementers to know that the mental model (data model) sticks together... but trying to convey that in the conformance section, or having to repeat it in every specification that uses JSON-LD is probably not helpful. This should probably become a section in the JSON-LD specification (the fact that you can gain many of the benefits of JSON-LD w/o doing full blown JSON-LD (or RDF) processing.

In any case, I don't know what to write/change and need some help doing so. Let's discuss in issue #165 and, if we have a flash of clarity, then we can raise another PR to modify this section. In the meantime, we don't have /any/ conformance classes, so I'm going to merge this PR (since no one is objecting, though there is uneasiness around the "data model"). We can continue the discussion in #165.

[msporny]

Normative, multiple reviews, changes requested and made, #165 raised to track remaining concerns, no objections, merging.