Tamper proofing

As part of the verification process, MATTR VII checks for any tampering of the credential, based on Linked Data Proofs. When the credential is signed, the JSON body is expanded using the dereferenced @context vocabularies. You can explore what this looks like in the JSON-LD Playground.

This expanded credential view is then signed using keys from the Issuer DID document.

The @context schema is expanded using a ‘last term wins’ process. That means that when two different schemas define the same terms, the lower context in the list defines the expanded terms used in the LD-Proof.

Any JSON-LD term that is not defined in a standard schema will get picked up by the @vocab context. When there is a @vocab referenced lower in the list (e.g. "@vocab": "http://schema.org") it will override the credential’s default context.

1{"@vocab": "https://w3id.org/security/undefinedTerm#"}

Example 1

Changing the givenName from Chris to Bob fails the verification because the expanded term has clearly changed:

Credential payload

"givenName": "Bob",

NQUAD

<did:key:z6MkfxQU7dy8eKxyHpG267FV23agZQu9zmokd8BprepfHALi> <http://schema.org/givenName> "Bob" .

Result

1{
2  "verified": false,
3  "reason": "Credential is invalid"
4}

Example 2

Inserting a new resolvable context to the credential payload in the middle of the list results in no change to the result, and the verification continues to be true.

This is because for this credential, the terms in this context givenName , familyName etc. are overwritten by the schema.org context lower in the list, so the resulting expanded terms have not changed.

Credential payload

1"@context": [
2    "https://www.w3.org/2018/credentials/v1",
3    {
4        "@vocab": "https://w3id.org/security/undefinedTerm#"
5    },
6    "https://www.w3.org/2018/credentials/examples/v1",
7    "https://schema.org"
8],

NQUAD

<did:key:z6MkfxQU7dy8eKxyHpG267FV23agZQu9zmokd8BprepfHALi> <http://schema.org/educationalCredentialAwarded> "Certificate Name" .
<did:key:z6MkfxQU7dy8eKxyHpG267FV23agZQu9zmokd8BprepfHALi> <http://schema.org/familyName> "Shin" .
<did:key:z6MkfxQU7dy8eKxyHpG267FV23agZQu9zmokd8BprepfHALi> <http://schema.org/givenName> "Chris" .
<did:key:z6MkndAHigYrXNpape7jgaC7jHiWwxzB3chuKUGXJg2b5RSj> <http://schema.org/name> "tenant" .
...

Result

1{
2  "verified": true
3}

Example 3

Inserting the same resolvable context to the bottom of the @Context list leads to the verification being false because the expanded view shows that the semantic meaning of the credential has been altered since it was issued (in this case a format change on the name term but other scenarios could be more impactful).

Credential payload

1"@context": [
2    "https://www.w3.org/2018/credentials/v1",
3    {
4        "@vocab": "https://w3id.org/security/undefinedTerm#"
5    },
6    "https://schema.org",
7    "https://www.w3.org/2018/credentials/examples/v1"
8],

NQUAD

<did:key:z6MkfxQU7dy8eKxyHpG267FV23agZQu9zmokd8BprepfHALi> <http://schema.org/educationalCredentialAwarded> "Certificate Name" .
<did:key:z6MkfxQU7dy8eKxyHpG267FV23agZQu9zmokd8BprepfHALi> <http://schema.org/familyName> "Shin" .
<did:key:z6MkfxQU7dy8eKxyHpG267FV23agZQu9zmokd8BprepfHALi> <http://schema.org/givenName> "Chris" .
<did:key:z6MkndAHigYrXNpape7jgaC7jHiWwxzB3chuKUGXJg2b5RSj> <http://schema.org/name> "tenant"^^<http://www.w3.org/1999/02/22-rdf-syntax-ns#HTML> .
...

Result

1{
2  "verified": false,
3  "reason": "Credential is invalid"
4}