Provide minimal viable examples

[msporny]

There are a variety of fields in the data model that seem unnecessary. For example, a minimal viable example was provided in PR #29, and then suggestions were made to add fields that are either not required, or whose usage would result in unnecessary ecosystem complexity:

https://github.com/w3c-ccg/verifiable-issuers-verifiers/pull/29/files#r2308310350
https://github.com/w3c-ccg/verifiable-issuers-verifiers/pull/29/files#r2308322829
https://github.com/w3c-ccg/verifiable-issuers-verifiers/pull/29/files#r2308335203

The specification should provide minimum viable examples for each type of class and then a complete example for each type of class.

[David-Chadwick]

I agree that minimum viable examples are very useful. It is perfectly possible to do this using the existing data model without specifying new fields that duplicate the semantics of existing fields in the data model.

[David-Chadwick]

Perhaps we can create a list of the information that is needed in a minimum viable example. However, this depends upon how much of the needed information is in the example itself, and how much is built (i.e. pre-configured) into the implementation that is using the example.

At one end of the spectrum, all the information that is needed in the example is a single ID, and the implementation that is using the example has a whole lot of information pre-configured into it that understands what this ID means, in terms of what VC type is being created and by whom, what its schema is, what the T&Cs are, who should be trusted by users to be given these VCs, who is responsible for any loss that occurs from using this example etc. All the implementation then needs to do is to see if the known ID is published in the example or not, and to reject everything that does not contain this ID. If the ID is the known one, then it must refer to its pre-configured information to see if the issuer is in the pre-configured list of trusted issuers, if the issued VC is of the type(s) that are pre-configured, and if they match the pre-configured schemas, and if the verifier is in the list of trusted verifiers who can be given this VC etc.

At the other end of the spectrum we have the current data model where all the information that is needed is published in the example. The implementation then uses the fields of the example to do the comparison with either the presented VC, or the verifier that is requesting the VC from the user. The code that performs the matching will be the same in both examples. It is just an issue of where you get the trusted values from: either pre-configured information, or dynamic information from the trusted list