Add Support for the VC Data Model

[OR13]

Attempting to address: #25

This PR Adds tests for supporting for the JWT Proof format of the VC Data Model.

I used did:ethr and https://github.com/decentralized-identity/did-jwt-vc

To demonstrate the VC Data Model format.

I have also included support for Linked Data Proofs, because it was trivial to show how they can be supported.

No spec changes have been made, and no changes to the demo in its current form have been made.

The security context of the JWT Proof Variant of VC Data Model is the same as it was before. No JSON-LD processing is occurring (in fact there appears to be very little validation of the vc data structure performed by did-jwt-vc).

It appears that the spec language would need to be revised to align with the VC Data Model, further discussion is required.

[awoie]

@OR13 IMO, the JWT in the existing spec does not have to match the VC JWT as they are different concepts. One could use DIDs without VCs. I expect that many people would opt in for that. Why don't we use the following format the VC? Would there be any issue with the RDF graph?

JWT-Proof style:

{
  "sub": "did:example:ebfeb1f712ebc6f1c276e12ec21",
  "iss": "did:example:ebfeb1f712ebc6f1c276e12ec21",
  "exp": 1573029723,
  "vc": {
    "@context": [
      ...
    ],
    "type": ["VerifiableCredential", "DomainLinkageAssertion"],
    "credentialSubject": {
      "domain": "example.com"
    }
  }
}

LD-Proof style:

{
  "@context": [
    ...
  ],
  "type": ["VerifiableCredential", "DomainLinkageAssertion"],
  "expirationDate": "...",
  "issuer": "did:example:ebfeb1f712ebc6f1c276e12ec21",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "domain": "example.com"
  },
  "proof": {  }
}

[OR13]

@awoie I don't think the examples you provided would be an issue, they are certainly more compact. The context can only provide definitions for things underneath it, so there would be no semantic definition for sub and iss... but I'm not sure we need that, the vc data model would probably have discussed this in depth, there most be a reason they chose the structure we have today.

[csuwildcat]

Why can't we just leave the existing top-level properties and current validation rules, then specify that the domain property must also be present inside the VC portion to ensure validating it that way also works? How is that not valid?

[awoie]

@awoie I don't think the examples you provided would be an issue, they are certainly more compact. The context can only provide definitions for things underneath it, so there would be no semantic definition for sub and iss... but I'm not sure we need that, the vc data model would probably have discussed this in depth, there most be a reason they chose the structure we have today.

@OR13 The examples for LD-Proofs and JWT that I provided are semantically equivalent. By following the W3C VC spec one will be able to construct a JSON-LD credential from the JWT. So, I would be in favour of using my examples in the spec. Note, iss, sub and exp will be mapped onto issuer, id and expirationDate after applying the transformation rules, so there is a semantic definition of these three properties.

[OR13]

[OR13]

I have added tests for creating and verifying that a given did is linked via the configuration.

I think the next step is to merge this demo and then update the spec to reflect the VC Data Model as is.

[awoie]

@OR13 why was the nesting of domainLinkageAssertion necessary? Isn't that the point of JSON-LD to avoid name clashes, so it would have been save to remove that nesting?

[OR13]

@awoie good question, I have opened this issue to gather feedback: #29

I made it that way because I thought there might at some point in the future be other links of assertions in the credential subject... but I'm happy to make the credential look however we want.