Generic solution for dealing with complexity degrees of conformity credentials

[nissimsan]

Conformity credentials come in different levels of complexity, and I would like to see this group suggest a generic data model to support this.

Example: A Mill Test Report can include a number of tests. But, say, a pressure test makes makes sense for a tube or a valve - but not a coil.
The exact tests carried on a MTR depends on (at least):

• Type of product,
• Customer,
• Region/country/jurisdiction.

Two general thoughts come to my mind:

• Narrowly defined schemas, dedicated to for example specific products. I would assume there are applicable standards which can guide this subdivision.
• Inheritance, since a lot - but not all - elements on such different MTR types would overlap. Technically, though, this is complexity danger zone which I'd prefer to avoid.

[nissimsan]

@zachzeus, I'd love your input on this. Related to #98

[seewodg]

For what it is worth, I think much of the complexity in VCs can be avoided through:
Enabling a catalog of standards (DCAT) that references standards and where available, parts of standards, and a Profile (https://www.w3.org/TR/dx-prof/) that is connected to the catalog.

Profile creation/updates can be enabled through a simple forms mechanism and governance applied to profiles to control publishing of profiles can be a simple overlay to the access mechanism (e.g. AD, or SAML, or other). Creation of a profile need not be technical (the form can engage selecting from the catalog).

Schema can be generated from the profile and if required from the DCAT catalog (export to CSV, JSON LD, JSON, etc). For an example of DCAT catalogs see: https://data.europa.eu/data/catalogues?locale=en

Profiles have persistent URI's that can be referenced in a VC or DPP.

Profiles can be reused like a template where a profile can be taken from the profile graph and altered to suit a supply chain participant then altered as required then published as a new profile.

This approach is both well used today and enables Trust Anchors to take a role in profile publishing.

This approach removes complexity from the VC and DPP, and supports the goals for the UNTP, and most importantly is a mature solution. It also creates separation of concerns between cataloged standards and implemented profiles, thus it supports diversity in claims for a particular domain.

At least two graphs would be required, 1 x DCAT Catalog Graph, 1 x Profile Graph.

Governments, Industry Bodies and other bodies can independently implement catalog and profile graphs. Individual products could have a profile, whole supply chains could have a profile, CVs can reference one or more profiles and profiles will be resolvable (even federated queries are supported - see DCAT specification).

Given this approach is working today for applications in the EU (and elsewhere around the globe), I feel there is no need to reinvent the wheel.

[seewodg]

I should have also pointed out, that the Catalog and Profile graphs would include a provenance graph (PROV-O from W3C) so that changes to the catalog and profiles would be traceable in terms of Agent, Activity and Entity.

[nissimsan]

@seewodg, cheers!

I failed to mentioned this, but the intention of my question was actually more basic. Specifically I meant to discuss approaches for reusing of parts of JSON Schemas. If we can solve this, the semantic layer can always be solved with an appropriately detailed @context.

[PatStLouis]

@nissimsan I believe this belongs here but here is an issue I'm facing with the current conformity credential data model. There's a field called issuedTo which outlines an entity this credential was issued to and a list of identifiers this entity is known as. In one of our use case, the conformity credential represents a legal document that entitles entities to a piece of land for raw material extraction. These title can include one of more entity with their respective shares.

My approach would be to use the issuedTo field as a list of entities instead of 1 entity containing multiple identifiers:

"issuedTo": [
        {
            "type": ["Organization", "Permittee"],
            "id": "did:web:example.com:123",
            "url": "https://orgbook.gov.bc.ca/entity/FM0087460",
            "name": "HUNT GRAPHICS",
            "interest": "100.0000"
        }
]

Any thoughts on this concern/approach?

[PatStLouis]

@nissimsan you can ignore my previous comment, we have opted to issue a separate credential to each holder.

[PatStLouis]

I would like to change the term facility from the assessment to location, and a location could be a facility or an area. Some use cases the assessment will be made in a location which may not have a facility.

Additional context can provide information about what is the actual assessment and what is the location (is it a mine, a well, a protected area of land?)

Here's more or less what I had in mind as a generic ConformityCredential (based on the example from the spec)

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2"
  ],
  "type": [
    "VerifiableCredential",
    "ConformityCredential"
  ],
  "id": "",
  "issuer": {
    "id": "did:web:issuer.example.com"
  },
  "validFrom": "",
  "validUntil": "",
  "credentialSubject": {
    "id": "did:web:product-owner.example.com",
    "type": [
      "Organization"
    ],
    "description": "Some org",
    "hasAttestation": {
      "type": ["ConformityAttestation"],
      "assessments": [
        {
          "type": [
            "ConformityAssessment" \\ Additional context will define an additional type, such as a MinesActPermit or a TenureTitle
          ],
          "topic": {
            "type": [],
            "id": ""
          },
          "level": {
            "type": []
          },
          "regulation": {
            "type": [], \\ Additional context will define a type, such as a LegalAct
            "id": "",
            "name": "",
            "issuingBody": {},
            "effectiveDate": ""
          },
          "attestedProducts": [],
          "attestedLocations": [] \\ Location could be a facility, an area of land or any other subject location of the assessment
        }
      ]
    }
  }
}

[PatStLouis]

@nissimsan I had another read of this issue in light of the more recent development I've been making with CC.

One of the products we will be including an assessment about in our TenureTitle will be Petroleum.

As part of the product assessment, we are including information about the depth at which the product can/can't be extracted from the soil within the area of the tenure agreement, which is a legal restriction put on a specific title. This is a governance compliance topic which the title holder will need to abide by.

This is a case where the assessment is no longer generic and is becoming specific to the product in question. We are defining these new "properties" with your second thought, inheritance, meaning we provide an additional context which defines a type to be used in conjunction with the AssessedProduct type.

The resulting credential will result in a narrowly defined schema.

I think this is related to your question raised.

Would it be fair to say that an extension will enable inheritance by providing an additional context file and the narrowly defined schema will be generated from this summed credential?