@vocab is not working

[timlichen]

@vocab works during template creation and certificate batch creation but fails the schema check during issuing.

[kimdhamilton]

Thanks for opening this @timlichen.

The context here (for reference):

Blockcerts verification checks if there are any fields unmapped in the JSON-LD context. It does it by adding a "fallback" vocab, and seeing if any fields get this as their prefix. If so, it assumes someone has tampered with the certificate after issuance.

This was a workaround for a previous issue in the jsonld normalization step (in the json-ld libraries,
per the jsonld spec) where it would silently drop any unmapped fields. However, our specific implementation was overly restrictive because it prevented issuers from adding their own vocab. Note that unmapped fields would have also been detected with an issuer-provided vocab, because the normalized jsonld would be different, hence the hash of the certificate would be different (which is also checked during verification).

Even better, I just found out from @msporny that they intend to allow an exception to be thrown if unmapped fields are detected. It appears this fix is not yet pushed; it's tracked by issue 199 in the JSON-LD javascript library. I prefer to wait to fix this issue in Blockcerts until the python and js jsonld libraries have been updated.

[kimdhamilton]

I'm not sure when the pyld library will be released, so I fixed this with a workaround in the latest version of cert-schema. If @vocab is already there, then we skip adding the fallback vocab. If the certificate is tampered with, then it will be detected during verification because the normalized version (hence the hash) will be different.

[msporny]

hey @kimdhamilton - I don't think we have an eta on releasing the "exception thrown if unmapped field detected" feature in pyld... I think it's out for jsonld.js... perhaps @davidlehn, @cwebber, or @dlongley would know more?

[kimdhamilton]

It's fine -- I have a workaround now so this is not blocking.

Also note that I'm being sloppy in my words here -- I saw the PR and it looks like jsonld/pyld will ultimately support a callback to allow custom behavior on unmapped fields. That sounds like a perfect solution, and I will switch to use that whenever it's available, but no rush