CC schema/example update proposal

[PatStLouis]

Addresses issues:

100 #91 #47

Changes:

• Move issuedBy to issuer field of VC
• Remove issuedTo and instead have the credentialSubject be the issued to entity and shift the attestation into a hasAttestation property, similar to https://schema.org/hasCertification.
• Move the evidence field of the ConformityAttestation to the evidence field of the VC, defining an evidence type of ConformityAttestationEvidence.
• Delegate the status field of the ConformityAttestation to the credentialStatus component of the VCDM (BitstringStatusList).
• Replace the concept of the facility of the assessment with a location.
• Replace terms subjectProducts and subjectFacilities with attestedProducts and attestedLocations
• Add new UNTP context file

I will keep this PR scoped to this, most of it addresses the alignment with the core data model and some of it addresses some conceptual changes.

Looking for comments and feedback here please! Most of these changes came from our exploration with the MinesActPermit and the TenureTitle ConformityCredentials over at BC Gov.

[PatStLouis]

@onthebreeze the biggest change that I would ask more input on is moving the ConformityAttestation within a hasAttestation property of the credentialSubject , the subject becoming the issuedTo party. It's common for the credentialSubject.id to represent an identifier (often a did) which will make further statements or include this credential in a presentation. When reading from the DPP perspective, this would say

here's a ConformityCredential depicting a ConformityAttestation that was issued to me by this issuer, showing various ConformityAssessment made about this product/facility

Looking at the VCDM definition of the credentialSubject:

The value of the credentialSubject property is defined as a set of objects where each object MUST be the subject of one or more claims, which MUST be serialized inside the credentialSubject property. Each object MAY also contain an id to identify the subject, as described in Section 4.3 Identifiers.

Claims about the subject in this case would be things like legalName, identifier, url, image, description (or any other property defined by a Party in the UNTP spec) and most importantly hasAttestation which would contain the ConformityAttestation object as defined in the UNTP specification.

What is the most critical IMO is that the ConformityAttestation object remains intact according to this specification. The ConformityCredential says party A (issuer.id) claims party B (credentialSubject.id) has this ConformityAttestation containing these ConformityAssessment.

In other words, the credentialSubject.id of the ConformityCredential SHOULD match the issuer.id of the DigitalProductPassport. Note that the credentialSubject.id doesn't need to be a did, but it must be a URL. This URL (regardless if its a did or any other form) SHOULD map to a claim in an AnchoringIdentityCredential.

[zachzeus]

Principle: If VCDM field that serves same purpose - then we should not have a duplicated value in the schema. Is the intent of the conformity credential the same as the VCDM then don't overload the VCDM - put it inside the credential and call it something else. NOTE: We should put this in the governance section.