DPP Schema 0.5.1 proposal fixing constant value requirements

[absoludity]

What type of PR is this? (check all applicable)

• 🍕 Feature
• 🐛 Bug Fix
• 📝 Documentation Update
• 🎨 Style
• 🧑‍💻 Code Refactor
• 🔥 Performance Improvements
• ✅ Test
• 🤖 Build
• 🔁 CI
• 📦 Chore (Release)
• ⏩ Revert

Description

Running our 0.5.0 DPP schema validation for the example Digital Product Passport for FoodAgility fails with:

Testing Credential: digitalProductPassport
Version: v0.5.0
Path: credentials/productPassport/DigitalLivestockPassport-decoded-invalid.json
Result: FAIL
Error: 
/type field must be equal to constant.
/type/0 field must be equal to one of the allowed values. Allowed values: DigitalProductPassport, VerifiableCredential.
/@context field must be equal to constant.
/@context/1 field must be equal to one of the allowed values. Allowed values: https://www.w3.org/ns/credentials/v2, https://test.uncefact.org/vocabulary/untp/dpp/0.5.0/.
/credentialSubject/type field must be equal to constant.
/credentialSubject/type/0 field must be equal to one of the allowed values. Allowed values: Product.

This (draft) PR defines a proposed schema change (for 0.5.1) that require the arrays to contain at least one (or two) specific values, rather than being constant. If there's agreement, we'll request this change in jargon (or better, wait for any other schema changes for the next release, before requesting the change in jargon).

I've included the decoded original example DPP from FoodAgility (decoded-invalid) as well as a slightly modified version (decoded-valid) so that they can both be tested with yarn run untp test. The updated version (decode-valid) ensures that

• the "type" includes "DigitalProductPassport" (in addition to "DigitalLivestockPassport"),
• the "context" field includes the standard dpp context.

Note: the example DPP includes a context, aatp-dlp-context which appears to define the standard dpp context as well. It should be defining only the additional context for the DigitalLivestockPassport, I assume - I'll investigate that next. In the mean-time, it will be interesting to see if it fails the jsonld validation which @ashleythedeveloper is adding, or whether it will pass because it doesn't change or redefine those context values.

Note 2: The standard JSON-schema error messages used by the lib being used here, for the "contains", is not great. If, for example, the DPP's "type" field doesn't include the "DigitalProductPassport" value, the error is:

Result: FAIL
Error: 
/type/0 field must be equal to constant.
/type/1 field must be equal to constant.
/type field must contain at least 1 valid item(s).

which is incorrect (the items in the array aren't const, rather one of them needs to contain the value "DigitalProductPassport" and none do). I'll investigate if this is the lib that we're using or whether it can be improved.

Added tests?

• 👍 yes (well, added test data for a proposed schema change, not code tests)
• 🙅 no, because they aren't needed
• 🙋 no, because I need help

Added to documentation?

• 📖 Mock App docs site
• 📜 README.md
• 📕 storybook
• 🙅 no documentation needed

[optional] Are there any post-deployment tasks we need to perform?

Ref: https://github.com/gs-gs/fa-ag-trace/issues/905

[absoludity]

The actual diff for the 0.5.0 to 0.5.1 change is in commit 64cefdd