w3c / vc-test-suite

Verifiable Credentials WG Test Suite
https://w3c.github.io/vc-test-suite/
BSD 3-Clause "New" or "Revised" License
69 stars 39 forks source link

Inputs For Verifiable Credentials with `proof` properties Do Not Match Data Integrity Specs #135

Open LuisOsta opened 8 months ago

LuisOsta commented 8 months ago

There are several JSON-LD input documents where the proof property does not adhere to the spec data model requirements of a data integrity proof outlined in https://www.w3.org/TR/vc-data-integrity/#proofs. Here's an illustrative example in example1.jsonld (which is meant to be correct)

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "http://example.edu/credentials/58473",
  "type": ["VerifiableCredential", "AlumniCredential"],
  "issuer": "https://example.edu/issuers/14",
  "issuanceDate": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "alumniOf": "Example University"
  },
  "proof": {
    "type": "RsaSignature2018"
  }
}

But the following properties are mandated (MUST) by the spec:

Looking at the spec for the proof type RsaSignature2018 I can't see where/if it defines an alternative data model - https://w3c-ccg.github.io/lds-rsa2018/ and when looking at the context

This isn't the case for all of the examples, for instance example-5.jsonld has the correct construction:

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "http://example.gov/credentials/3732",
  "type": ["VerifiableCredential", "UniversityDegreeCredential"],
  "issuer": "https://example.edu",
  "issuanceDate": "2017-06-18T21:19:00Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science in Mechanical Engineering"
    }
  },
  "proof": {
    "type": "RsaSignature2018",
    "created": "2017-06-18T21:19:10Z",
    "proofPurpose": "assertionMethod",
    "verificationMethod": "https://example.com/jdoe/keys/1",
    "jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5XsITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUcX16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtjPAYuNzVBAh4vGHSrQyHUdBBPM"
  }
}

Could y'all point me to where the schema for this is defined that means that the values aren't required? And if they are required should we update the input documents?

LuisOsta commented 8 months ago

@dmitrizagidulin @brentzundel Any thoughts or clarity? If this is a spec-related clarity issue should I file an issue with the data integrity spec?