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

[LuisOsta]

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:

• verificationMethod
• proofPurpose

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]

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