Evidence extension point (was: Improve tests for Evidence)

[OR13]

See https://www.w3.org/TR/vc-data-model/#evidence

DocumentVerification2018...

this tremendously poorly defined and should be defined for all serializations or removed.

Ideally we would have a test suite that shows how this property supports interoperability, and that suite would cover popular feature such as identity assurance in sufficient detail.

[OR13]

cc @bumblefudge

[jandrieu]

Please do not remove this.

There are some use cases where providing evidence of the pre-issuance DID auth is exceptionally valuable.

This property is meant to be an extension point and we should keep it as such.

[OR13]

@jandrieu can you point to examples of this extension that are being used in the wild today?

I know folks have been considering it, we should gather evidence that it's being used or being considered, and if we can't we should try and remove it to simplify the spec.

[jandrieu]

I can't, today, speak publicly about either of the two initiatives I know of who are expecting this capability.

What I will say is that without evidence of having performed did-auth embedded in the VC itself, we have no mechanism to verify whether or not the issuer, in fact, proofed control of the DID before issuance. For those subject=holder use cases that rely on the verifier to compare the VP signer to the Subject ID to perform a second step in identity assurance, the evidence property is the only way (within the current spec) that I know of to demonstrate that the first step was completed satisfactorily.

This extension point exists for a reason. Removing it just to "simplify the spec" isn't appropriate here.

[OR13]

I think @selfissued also knows of some folks considering this feature, we should strive to get it covered in the test suite, if it really is being used.

[brentzundel]

Blocked by an item in the VC extensions directory that defines evidence that we can point to and test against?

[David-Chadwick]

Yes an example has been added to the Directory

[David-Chadwick]

It points to the use of the OIDF Identity Assurance draft standard as an example of Evidence

[OR13]

I suggest the following:

1. evidence is removed from the core spec and added as an extension to vc-specs-dir.
2. evidence is added to the core spec AFTER 2 implementations of the Evidence property have been tested for a given type.

Similar argument would apply to the other properties that are in the core spec, but for which we have no evidence (cough)... of actual implementation or use.

[OR13]

Example from Open Badges

"evidence": [
    {
      "id": "https://1edtech.edu/credentials/3732/evidence/1",
      "type":
        "Evidence"
      ,
      "narrative": "# Final Project Report \n This project was ...",
      "name": "Final Project Report",
      "description": "This is the final project report.",
      "genre": "Research",
      "audience": "Department"
    },
    {
      "id": "https://github.com/somebody/project",
      "type":
        "Evidence"
      ,
      "name": "Final Project Code",
      "description": "This is the source code for the final project app.",
      "genre": "Research",
      "audience": "Department"
    }
  ],

• https://1edtech.github.io/openbadges-specification/ob_v3p0.html#evidence

[Sakurann]

assigning Oliver to find out what needs to be done to resolve that issue

[OR13]

Example from OIDF eKYC and IDA Evidence

{
    "evidence": [{
        "type": ["https://openid.bitbucket.io/ekyc/openid-connect-4-identity-assurance.html#name-verification-element"],
        "verification": {
            "trust_framework": "uk_tfida",
            "scheme": "idconnect",
            "assurance_level": "idconnect_kyc_partial",
            "assurance_process": {
                "policy": "GPG_45",
                "scheme_policy": "idconnect_kyc",
                "procedure": "L1B",
                "scheme_procedure": "dlnl_sm",
                "gpg45_confidence_level": "low",
                "assurance_details": [{
                        "assurance_type": "evidence_validation",
                        "assurance_classification": "3",
                        "evidence_ref": [{
                            "txn": "WED-85762937582385444",
                            "evidence_classification": "3"
                        }]
                    },
                    {
                        "assurance_type": "address_validation",
                        "assurance_classification": "2",
                        "evidence_ref": [{
                            "txn": "idv-7567445464543",
                            "evidence_classification": "3"
                        }]
                    },
                    {
                        "assurance_type": "verification",
                        "assurance_classification": "3",
                        "evidence_ref": [{
                            "txn": "BIO-8576293758238555"
                        }]
                    }
                ]
            },
            "time": "2021-05-11T14:29-01:00",
            "verification_process": "7675D80F-57E0-AB14-9543-26B41FC22",
            "evidence": [{
                    "type": "document",
                    "check_details": [{
                            "check_method": "vri",
                            "sub_check_method": "vri",
                            "organization": "wedocu",
                            "txn": "WED-85762937582385444"
                        },
                        {
                            "check_method": "bvr",
                            "sub_check_method": "bvr",
                            "organization": "biotrick",
                            "txn": "BIO-85762937582385555"
                        }
                    ],
                    "time": "2021-04-09T14:12Z",
                    "document_details": {
                        "type": "driving_permit",
                        "document_number": "MORGA753116SM9IJ35",
                        "date_of_issuance": "2021-01-01",
                        "date_of_expiry": "2030-12-31",
                        "attachments": [{
                            "desc": "image_of_document",
                            "content_type": "image/png",
                            "content": "Wkd0bWFtVnlhWFI2Wlc0Mk16VER2RFUyY0RRMWFUbDBNelJ1TlRjd31dzdaM1pTQXJaWGRsTXpNZ2RETmxDZwo="
                        }],
                        "issuer": {
                            "name": "DVLA",
                            "country_code": "GBR"
                        }
                    },
                    "claims": {
                        "given_name": "Sarah",
                        "family_name": "Meredyth",
                        "birthdate": "1976-03-11",
                        "place_of_birth": {
                            "country": "UK"
                        },
                        "address": {
                            "locality": "Edinburgh",
                            "postal_code": "EH1 9GP",
                            "country": "UK",
                            "street_address": "122 Burns Crescent"
                        }
                    }
                },
                {
                    "type": "electronic_record",
                    "check_details": [{
                        "check_method": "data",
                        "sub_check_method": "cra_record_primary",
                        "organization": "theIdP",
                        "txn": "idv-7567445464543"
                    }],
                    "time": "2021-04-09T14:12Z",
                    "record": {
                        "type": "cra_account",
                        "authoritative_source": "equiexpunion",
                        "authoritative_source_reference": "gg54y4y5y5433443",
                        "created_at": "2021-01-01",
                        "date_of_expiry": "2030-12-31",
                        "date_last_updated": "2022-01-31",
                        "outcome_of_check": "positive",
                        "source": {
                            "name": "idvalidation4u",
                            "address": {
                                "street_address": "300 Bath Street",
                                "postal_code": "G2 4LH",
                                "country_code": "SCO"
                            }
                        }
                    },
                    "claims": {
                        "given_name": "Sarah",
                        "family_name": "Appleby",
                        "birthdate": "1976-03-11",
                        "address": {
                            "locality": "Leeds",
                            "postal_code": "LS12 6GT",
                            "country": "UK",
                            "street_address": "45 White Rose Road"
                        },
                        "start_date": "01-01-2020",
                        "end_date": "31-12-2020"
                    }
                }
            ]
        }
    }]
}

[OR13]

Based on the 2 examples in the vc-specs dir, it seems people are using "type" in different ways...

if there are 2 independent implementations of either of these, I think evidence predicate can stay in the core spec, but we probably should add a note that it is interpreted based on type and possibly in very different ways.

[OR13]

Related issue: https://github.com/w3c/vc-data-model/issues/893

[iherman]

The issue was discussed in a meeting on 2023-04-04

• no resolutions were taken

View the transcript

#### 1.12. Improve tests for Evidence (issue vc-data-model#870) _See github issue [vc-data-model#870](https://github.com/w3c/vc-test-suite/issues/134)._ **Kristina Yasuda:** By Orie, about evidence. Anyone willing to take this one?. … To those who joined late, this call is about assigning issues that are not currently assigned. It means you are responsible that the issue gets addressed.. > *Oliver Terbu:* +1 ivan. **Ivan Herman:** I don't really understand.. The title says you have to improve tests, which suggests this is about tests, not the spec. The text talks about better defining the property or removing it. What is this about? Question is to Orie.. **Orie Steele:** I believe we had the spectre of objections in the context of our RDF terms for which there have been no implementation. I believe "evidence" is one of them. In order to retain this in the core spec, this was the original intention of the issue. As far as I am aware, we have not provided any concrete examples of using the "evidence" property.. … I think DavidC is the furthest toward a concrete example. If we have multiple concrete implementations, this is the testing we should have to retain the property.. **Ivan Herman:** I understand. I suggest we postpone this to when we get to CR exit criteria. We have to say what it means for a property to pass the CR line. The issue wasn't clear from the description.. **David Chadwick:** Part of the NGI Atlantic project, we did a simple example which referred to NIST and eIDAS levels of assurance. There would have been two independent implementations, but the project ran out of time.. **Oliver Terbu:** To proceed with this issue, does somebody have to register an "evidence" type in the directory, and then write a test that uses this "evidence" type? Implementers don't need to anything, but they should not fail if they encounter an "evidence" property of this specific type, is this correct?. **David Chadwick:** This is a discussion we had with termsOfUse and nonTransferable, whether these properties can be ignored by recipients. I think DavidC added something to this discussion.. **Oliver Terbu:** Whoever gets assigned to this issue, should be someone who knows an "evidence" type that is used somewhere, and it should be registered in the VC directory. Does this make sense?. **Dave Longley:** Trying to respond to ignoring extension points. This was certainly the intention.. **Kerri Lemoie:** We have OpenBadges 2.0 use "evidence". I will share a link.. > *Kerri Lemoie:* See [Open badges reference](https://1edtech.github.io/openbadges-specification/ob_v3p0.html#evidence). **Kerri Lemoie:** It's a bit confusing, because they are using the "evidence" property from the VC spec, but they are using it in their own way with their own properties. This is important for EDU community, but they have their own testing. There is overlap, not sure what to do with it. I don't know if we can test it if they already test it in their own way.. > *Dave Longley:* +1 to you must be able to ignore unrecognized terms. **Michael Jones:** It's not a question whether they can ignore "evidence". They must be able to ignore it. In our test suite we should inject random elements and ensure that implementations don't fail if they encounter them.. **Kristina Yasuda:** Anyone willing to be assigned to this issue?. **Oliver Terbu:** You can assign me to find out what actually needs to be done, if anything needs to be changed in the test suite.. > *Kerri Lemoie:* oliver - feel free to reach out if you want insights into Open Badges.

[David-Chadwick]

@OR13 It is obvious that the Open Badges example is wrong and the OIDF example is correct, given the standard definition "Each evidence scheme is identified by its type. The id property is optional" The type must be a URI.

[awoie]

@OR13 To me it is not entirely clear what this issue is about. The title of the issue seems to imply we have to update the test suite. In that case, we should move this issue to https://github.com/w3c/vc-test-suite. Would you agree? If this is not the case, then we should close this issue and create a new one that describes what you wanted to get fixed. If you want to remove evidence entirely from the W3C VCDM core spec because the property is lacking two independent implementations of a type registered in the VC directory, then we should create a separate issue for that.

For reference, the W3C test suite has one test case for evidence, which uses the following evidence object:

  "evidence": [{
    "id": "https://example.edu/evidence/f2aeec97-fc0d-42bf-8ca7-0548192d4231",
    "type": ["DocumentVerification"],
    "verifier": "https://example.edu/issuers/14",
    "evidenceDocument": "DriversLicense",
    "subjectPresence": "Physical",
    "documentPresence": "Physical"

It seems that the type DocumentVerification has two problems at least:

• not included in @context
• not included in VC directory

I'm supportive on using an evidence type in the W3C test suite that has been registered in the VC directory instead. Currently, there is just one which is the OIDF eKYC one which doesn't define a context/vocab which makes it hard to be included in the W3C VC test suite.

[OR13]

There should be 2 places where tests are improved:

1. tests for the core data model
2. tests for securing formats that use evidence

I'm not volunteering to do either for evidence, but if neither is done well, I will argue against continuing to keep evidence in the core spec.

[TallTed]

the type DocumentVerification has two problems at least

A third is that this type is not a URI.

[awoie]

I believe this is blocked by w3c/vc-data-model#1082 since if we decide to include evidence in the reserved property list, we will have to remove the test cases that contain evidence. On the other hand, if we decide to keep evidence, we need to update the test cases to be fixed like @OR13 described it above, 1) in the core data model, 2) in the securing formats.

@OR13 let's close this issue after w3c/vc-data-model#1082 was resolved. If tests for evidence still have to be improved, please close this issue and open a new issue in the test suite repository.

[David-Chadwick]

Could @awoie or @OR13 please state what you expect the conformance tests to test. It seems to me that we could have tests along the following lines 1) send a correctly formatted Evidence object in a correctly formatted VC to the system under test and expect it accept the VC (Note. the system under test does not need to process nor understand the Evidence object. There is no requirement to do this). 2) send an incorrectly formatted Evidence object with the type parameter missing to the system under test and expect it to reject the VC I think these two tests are the minimum that are needed, but may be sufficient for the test suite

[OR13]

Ideally we could test both conformance to the data model, and business logic associated with evidence production and consumption.

The latter would need to be in a different test suite from the core data model.

[David-Chadwick]

I agree that testing business logic should not be part of the VCDM test suite. My question to you was about tests for the VCDM.

[iherman]

The issue was discussed in a meeting on 2023-07-05

• no resolutions were taken

View the transcript

#### 2.11. Evidence extension point (was: Improve tests for Evidence) (issue vc-data-model#870) _See github issue [vc-data-model#870](https://github.com/w3c/vc-test-suite/issues/134)._ **Kristina Yasuda:** Is this addressed by evidence being in the reserved properties, Orie? **Orie Steele:** Sort of. … It's pretty bad form to reserve something that you can't find any interoperable implementations of. … If there's a stronger evidence type, that would be better to revert to. **Kristina Yasuda:** I think that EBSI and Kerry in EDU are using evidence. > *Orie Steele:* right, but each party using `evidence` is using the `predicate` and AFAIK, the `type` has no interop? **Phillip Long:** In the education community, it's often used with assertions of skills and confidences. > *Greg Bernstein:* Phil is evidence in the new clr 2 spec? > *Phillip Long:* `@GregB` - lemme look. > *Greg Bernstein:* CLR 2.0 [https://www.imsglobal.org/spec/clr/v2p0#evidence](https://www.imsglobal.org/spec/clr/v2p0#evidence). > *Phillip Long:* `@GregB` it's used frequently in the CLRv2: see [https://www.imsglobal.org/node/205106#evidence,](https://www.imsglobal.org/node/205106#evidence,) and, [https://www.imsglobal.org/node/205106#evidence-0](https://www.imsglobal.org/node/205106#evidence-0) for examples. **Manu Sporny:** I see that Gabe is saying that TBD will be using it. … The OpenID eKYC-IDA spec uses it. > *Orie Steele:* fwiw, i dont think anyone is using it in any interoperable way... and 2, we have no ability to encourage interop based on what we have been doing. **Manu Sporny:** We need to see some level of interop demonstration. … I believe you need at least 2 interoperable implementations to reserve a term. … There are a number of people using it in some capacity. … But interop has yet to be demonstrated. **David Chadwick:** You can test that 2 implementations will work with the evidence property. … Testing the business logic is another thing altogether. … I don't think our spec specifies the business logic. **Manu Sporny:** That was the model we were working under in the V1 and V1.1 WGs. … It seems like the V2 WG is upping the bar. … It seems to be what people are pushing towards. > *Orie Steele:* +1 Manu. **Manu Sporny:** Several accepted PRs have asked for more. **Kristina Yasuda:** What does that mean in terms of the spec text or directory? **David Chadwick:** I don't see how you can put those conformance tests into the VCDM test suite. … There are different applications that will have different specifications of evidence. … They will be specific to those groups of users and won't be generic. **Orie Steele:** If the VCDM defines the evidence property and it's defined in the normative @context then there are positive and negative data model tests than can be applied to it. … even if what the property means is completely untestable. > *David Chadwick:* +1 to Orie. **Kristina Yasuda:** I'm leaving this open. The IRC comments will be reflected in the issue. > *Orie Steele:* can we cite IMS global normatively? > *Phillip Long:* @Orie - yes, they have six implementers as I recall. > *Orie Steele:* maybe good to do that, when keeping the property. **Manu Sporny:** The next step for this issue should be to refer to Phil's citations above. **Phillip Long:** I can be assigned this issue. I will add citations to the issue. **Kristina Yasuda:** Brent will chair next week. … We will probably cancel in two weeks. ---

[longpd]

There is a strong reliance in the education and training implementations of the VCDM for the evidence property. In the OBv3 specification.

Example from 1Edtech Open Badges v3.0 specification in Final Candidate Public release

"evidence": [
    {
      "id": "https://1edtech.edu/credentials/3732/evidence/1",
      "type":
        "Evidence"
      ,
      "narrative": "# Final Project Report \n This project was ...",
      "name": "Final Project Report",
      "description": "This is the final project report.",
      "genre": "Research",
      "audience": "Department"
    },
    {
      "id": "https://github.com/somebody/project",
      "type":
        "Evidence"
      ,
      "name": "Final Project Code",
      "description": "This is the source code for the final project app.",
      "genre": "Research",
      "audience": "Department"
    }
  ],

* https://1edtech.github.io/openbadges-specification/ob_v3p0.html#evidence

It is also used in the 1Edtech CLRv2 (compound credential including a transcript, OBv3s and CASE competency statements).

There are commitments to implement these VC compatible 1Edtect credentials by numerous platform providers including: Territorium, AwardAssured, & Randa Solutions. Several others have expressed intent but aren't far enough along, or at least willing to say publicly their timeline.

[iherman]

The issue was discussed in a meeting on 2023-07-26

• no resolutions were taken

View the transcript

#### 2.1. Evidence extension point (was: Improve tests for Evidence) (issue vc-data-model#870) _See github issue [vc-data-model#870](https://github.com/w3c/vc-test-suite/issues/134)._ **Brent Zundel:** Issue 870. Should we do this before or after CR and who to assign? > *Manu Sporny:* [https://w3c.github.io/vc-specs-dir/#evidence](https://w3c.github.io/vc-specs-dir/#evidence). > *Manu Sporny:* [https://www.imsglobal.org/spec/ob/v3p0/](https://www.imsglobal.org/spec/ob/v3p0/). > *Manu Sporny:* [https://1edtech.github.io/openbadges-specification/ob_v3p0.html#evidence](https://1edtech.github.io/openbadges-specification/ob_v3p0.html#evidence). **Manu Sporny:** I think we need to resolve it before CR. It's missing 1EdTech - they very clearly use this extension point.

[longpd]

Reviewing the thread above it seems there are a couple of different issues here. One is the question of testing the evidence extension point. A second is about the use of the Evidence, either to include corroborating information about the claim being made in the credential or as a pointer to such corroborating information and how that should be represented. Lastly there is a question about aligning the term Evidence with its definition by NIST, which is specific to evidence concerning ensuring the security of a system, which is very specific to a that particular use case.

Two immediate suggestions:

First David Chandwick notes that a test could be made to assure the Evidence object is correctly formatted or not. The 'test" would be to send a correctly formatted and the incorrectly formatted credential with the Evidence object in it. The first should pass and the second should fail. This makes sense and I think creating a PR to this effect in vc-test-suite.

Finally there is an issue with the proper syntax of the Evidence Object. Its use by OIDF eKYC and IDA Evidence relative to the use of Evidence by 1Edtech in the OBv3 specification.

My preference is to stay consistent with the VCDM v1.1

This specification defines the evidence property for expressing evidence information.

evidence The value of the evidence property MUST be one or more evidence schemes providing enough information for a verifier to determine whether the evidence gathered by the issuer meets its confidence requirements for relying on the credential. Each evidence scheme is identified by its type. The id property is optional, but if present, SHOULD contain a URL that points to where more information about this instance of evidence can be found. The precise content of each evidence scheme is determined by the specific evidence type definition.

Id there is a difference between how 1Etech defines evidence this can be raised in their credentials workgroup and a PR entered into their Github repo to address changing this.

What is important and clear is the need for Evidence and its importance to substantiate claims being made in a credential.

[TallTed]

My concern and issue with the current definition of the evidence property shown above is that it is only applicable to an entire VC.

I believe it should be applicable to any assertion/claim (or group of same) contained in a VC — in other words, that the issuer may say "I relied on this evidence for these claims, and this other evidence for these other claims" and the verifier may decide that "these claims" may be (sufficiently) relied upon, but "these other claims" may not be relied upon at all.

[longpd]

TallTed - I'm assuming you're saying the vcdm v1.1 prevents use of the element property to make multiple assertions. Can you elaborate why you come to that conclusion?

[TallTed]

It's not that the VCDMv1.1 prevents use of the evidence property to make multiple assertions. It's that the definition of the evidence property clearly scopes (each value of) that property to apply to the entire credential, not to any partial set of claims or assertions taken from within the credential. Again —

The value of the evidence property MUST be one or more evidence schemes providing enough information for a verifier to determine whether the evidence gathered by the issuer meets its confidence requirements for relying on the credential.

[dmitrizagidulin]

@TallTed - I think the current definition you quoted still permits for the use case Phil has in mind. It's like - what's the property for? It's for providing additional /evidence/ for why issuer is confident in claims. So it actually makes sense to differentiate each piece of evidence to each claim. So if the VC has 3 claims in the credentialSubject, it's very reasonable to see 3 different evidence objects, one for each claim.

[dmitrizagidulin]

@TallTed or, to put it a different way, how can we phrase the definition of evidence in the spec, to clear up that confusion? (To clarify that an evidence object can apply to all claims or to a subset of them, including to just one).

[TallTed]

This might get us closer --

The value of the evidence property MUST be one or more evidence schemes providing enough information for a verifier to determine whether the evidence gathered by the issuer meets its confidence requirements for relying on one or more claims, up to and including all claims, in the credential.

Something might be added, more explicitly defining the Range and Domain of the evidence property, and how to include multiple values for it, each associated with a different subset of claims, up to and including the entire VC.

[OR13]

cc @iherman, keeper of ranges and domains in the vocabulary... what do you think?

[iherman]

@OR13 My apologies, but I did not really dive into this particular issue. And I am not sure how to translate https://github.com/w3c/vc-test-suite/issues/134 of @TallTed into RDF(S). The range of the cred:evidence is already defined to be a cred:CredentialEvidence class, but the latter does not have any attached properties at the moment. @TallTed do you mean to say that there is a need for a more detailed definition of that Class? What should/would they be?

Warning: the expressiveness of RDF/RDFS is fairly limited. Getting more complex definitions defining the CredentialEvidence class relying on, say, cardinality of properties (like "any instance of this class must have at least one property of type x") leads us to OWL land, and that is a very different world where, imho, we should not go with this vocabulary. In other words, the spec may define restrictions of the class behaviour in English prose, but formalizing it may be an unnecessary exercise...

@TallTed, I presume you are familiar with OWL, can you try to explain what you have in mind?

[TallTed]

I am minimally familiar with OWL.

My concern here is more about the Domain, than the Range, of cred:evidence. The current human definition suggests to me that this Domain has been defined to be cred:Credential, while I want this Domain to include any property in the credential.

To hopefully clarify, Example 23 in VCDMv1.1 shows evidence (of the subject's identity) attached to the credential --

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": ["VerifiableCredential", "UniversityDegreeCredential"],
  "issuer": "https://example.edu/issuers/14",
  "issuanceDate": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
    }
  },
  "evidence": [{
    "id": "https://example.edu/evidence/f2aeec97-fc0d-42bf-8ca7-0548192d4231",
    "type": ["DocumentVerification"],
    "verifier": "https://example.edu/issuers/14",
    "evidenceDocument": "DriversLicense",
    "subjectPresence": "Physical",
    "documentPresence": "Physical",
    "licenseNumber": "123AB4567"
  }],
  "proof": {  }
}

Rather, I want to be able to attach a distinct evidence property to each of the credentialSubject (proof of identity) and the degree (proof of degree), and none to the overall credential, à la --

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "http://example.edu/credentials/3732",
  "type": ["VerifiableCredential", "UniversityDegreeCredential"],
  "issuer": "https://example.edu/issuers/14",
  "issuanceDate": "2010-01-01T19:23:24Z",
  "credentialSubject": {
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "evidence": [{
      "id": "https://example.edu/evidence/f2aeec97-fc0d-42bf-8ca7-0548192d4231",
      "type": ["DocumentVerification"],
      "verifier": "https://example.edu/issuers/14",
      "evidenceDocument": "DriversLicense",
      "subjectPresence": "Physical",
      "documentPresence": "Physical",
      "licenseNumber": "123AB4567"
    }],
    "degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Science and Arts"
      "evidence": [{
        "id": "https://example.edu/evidence/example-12341241341",
        "type": ["DocumentVerification"],
        "verifier": "https://example.edu/issuers/fred",
        "evidenceDocument": "Diploma",
        "subjectPresence": "Physical",
        "documentPresence": "Physical",
        "diplomaNumber": "example-fasrgaertlh"
      }]
    }
  },
  "proof": {  }
}

[iherman]

Thanks, @TallTed, for your clarification.

My concern here is more about the Domain, than the Range, of cred:evidence. The current human definition suggests to me that this Domain has been defined to be cred:Credential

That is correct: the domain is set to cred:VerifiableCredential at the moment.

, while I want this Domain to include any property in the credential.

To hopefully clarify, Example 23 in VCDMv1.1 shows evidence (of the subject's identity) attached to the credential --

[…]

Rather, I want to be able to attach a distinct evidence property to each of the credentialSubject (proof of identity) and the degree (proof of degree)

The easiest possible change in the vocabulary specification is to simply remove the domain statement, i.e., putting no domain reference. That means one can use the property with anything.

and none to the overall credential, à la --

That is a different matter.

Such a restriction can be expressed in OWL, I believe (caveat: my OWL knowledge has never been very good and what remains of it is rusty; everything I write should be under the control of @pchampin). Here is an attempt (in Turtle):

cred:evidence rdfs:domain [
    rdfs:subClassOf [
        a owl:Class ;
        owl:complementOf cred:VerifiableCredential
    ]
]

Which simply says that the domain of the property (which can be viewed as a set of individuals, a.k.a. resources) is part of the complement of the set of verifiable credentials. I believe that is your intention.

Even if this OWL statement is correct, I see some practical problems with that statement, though:

• Is it really what we would want? I.e., do we want to disallow the cred:evidence on a Verifiable Credential as a whole?
• It is not clear to me whether we should add this to our vocabulary. Indeed, one of the values of the formal RDFS ontology, beyond being a necessary specification piece for an RDF vocabulary, is that if a Verifiable Credential represented by an RDF Graph is combined with other Linked Data in RDF (that can be another VC Graph or indeed anything else), then a smart RDF engine (RDF Database, SPARQL query engine, etc.) can deduce extra "implicit" relationships based on the ontology statements. In practice, many tools, databases, or query engines have the capability to handle a simple ontology like the one we have today. However, engines that can handle OWL, including the statement above, are much less widespread, as far as I know (and are usually aimed at large and complex cases like medical ontologies). @TallTed, I would expect you know that market way better than I do, so you can prove me wrong but, if I am right, then having such a statement in our ontology does not have much practical importance, and just makes our life a bit more complicated.
• (While of course we should never be influenced by the deficiencies of the current tool, the current yml2vocab tool is not prepared to include such OWL statements. It will require some non-obvious work to do things like that if we want to avoid doing some manual adjustments on its output...)

In my personal view (my staff contact hat put down) is that, to do what you would like to have, we should remove the domain statement from the definition of a cred:evidence and any other restriction should be added to the specification with English prose.

[TallTed]

do we want to disallow the cred:evidence on a Verifiable Credential as a whole?

I was unclear; I do not mean to forbid attachment to the overall credential -- there may well be use cases where cred:evidence is appropriately attached to the top level!

I just want to ensure that attachment to any level within the credential is also permitted, as I think this will be the more commonly appropriate attachment.

[iherman]

do we want to disallow the cred:evidence on a Verifiable Credential as a whole?

I was unclear; I do not mean to forbid attachment to the overall credential -- there may well be use cases where cred:evidence is appropriately attached to the top level!

I just want to ensure that attachment to any level within the credential is also permitted, as I think this will be the more commonly appropriate attachment.

... in which case, I believe, the solution would be really simple: just ditch any domain statement on the cred:evidence property. It means that anything goes: the statement can be used on any resources.

[TallTed]

... or make it explicit, cred:evidence rdfs:domain rdfs:Resource.

All things considered, I think this would be better, because leaving it out means "rdfs:domain of cred:evidence is unknown", not, as you say, "anything goes".

[longpd]

Sounds like we may be reaching a consensus to allowing evidence to be used with any resource. Is that where we're at now? I rather like this because I think the concept of evidence that is corroborated by digital objects that support a claim about a resource makes it more useful.

Perhaps something we haven't considered will arise but until then sounds like a good direction.

[iherman]

... or make it explicit, cred:evidence rdfs:domain rdfs:Resource.

All things considered, I think this would be better, because leaving it out means "rdfs:domain of cred:evidence is unknown", not, as you say, "anything goes".

I do not mind doing that; my only concern is that, for consistency's stake, it would require to make this type of statement (both for domain and for range) for all properties that do not have an explicit domain/range set, which would make the description and the vocabulary unnecessarily verbose.

[TallTed]

I do not think these explicit statements would be unnecessary (or at least, inappropriate) verbosity. Leaving them out suggests that we don't know the rdfs:range or rdfs:domain of some of the properties we've created. It may be worth reviewing those properties that currently have undeclared Range and/or Domain, to confirm that they really are rdfs:Resource, before we make such broad updates.

[iherman]

I was not part of the initial discussions, nor am I a domain expert... It seems that a possible PR to close this issue would be to make a simple change in the vocabulary, removing the domain statement from the definition of evidence property. I am happy to do such a PR if there is a general agreement on this (it should also be reflected by a slight change in the diagram of w3c/vc-data-model#1236).

I would think that the more general approach of adding a reference to rdf:Resource (https://github.com/w3c/vc-test-suite/issues/134) should be the subject of a separate PR/issue.

[longpd]

There has been a lot of input and we appear close to an outcome with a solution to remove any domain statement on the cred:evidence property. However, Ivan H. expressed concern that it would require us to make this type of statement (both for domain and for range) for all properties that do not have an explicit domain/range set.

At the end of all this TallTed suggested "It may be worth reviewing those properties that currently have undeclared Range and/or Domain, to confirm that they really are rdfs:Resource, before we make such broad updates."

I am not an expert in rdfs, but I’ve consulted a few recently on this question about the concern of rdfs properties and explicit or absent domain range settings. Among the things I’ve learned include advice from someone involved in Dublic Core (DCMI) who explained to me that none of the properties in that well established meta data initiative have explicit range or domain settings.

I was given a reference to the SEMIC style guide for semantic engineers Semantic Conventions which arise from the Clarifications on reuse, where the guidelines explicitly say “no expressions of (a) property domain specification (rdfs:domain) and (b) property range specification (rdfs:range) shall be used unless justified as absolutely necessary. The need for setting property domain and range constraints is better fulfilled by the data shapes expressed in SHACL language.”

I was also reminded of a colleague with who I worked for several years, Stuart Sutton, also deeply involved in the development of DCMI, and wrote with Tom Baker an introduction to the Bulletin of the Association for Information Science and Technology, Special Section: Linked Data and the Charm of Weak Semantics (Volume41, Issue4, April/May 2015, Pages 10-12). While it’s a bit dated, I’m told this position is still the predominant view among most semantic engineers. Their summary said, “Linked data practice, in short, values pragmatic links alongside formal ontologies, prefers vocabularies specified with lightweight semantics for maximum reusability, defines overlapping profiles in place of monolithic data structures, sees data in terms of graphs and concepts more than formal classes, shuns over-formalized semantics, embraces flexible and iterative evolution over static standardization and accepts partial interoperability as the only realistically attainable goal in today's massively diverse web. The linked data movement has invented useful new roles for constructs and languages that are, by design, semantically weak.”

The discussions in this issue have been robust and a number of topics raised and responded to. My overall conclusion at this stage is we can safely move forward with Evidence leaving domain range and domain left undefined for now. Several active implementations using Evidence exist and with the emergence of LinkedClaims and its use, including a recent grant to develop an web-based app to author such claims that hides a lot of the JSON-LD complexity behind the UI (Gates Fdn grant to the T3 Innovation Network, with Golda Velez, Dmitri Zagidulin and myself as the recipients) my sense is we close this issue and leave Evidence for the community to use. We could, if desired, make reference in an implementation guide to the vcdm the preferences expressed among the semantic meta data community that is recommended to leave this properties undefined. However, that would likely be useful to minority of those deeply familiar with rdfs and be largely lost on the rest.

[OR13]

So concretely:

1. Keep the reserved term.
2. Don't define an abstract class / domain or range.
3. Encourage people to use the term however they like, as long as instances have an id and a type?

I don't think we have any normative requirements for Evidence, but we should double check.

[longpd]

@OR13 That ^^^^ sums it up.

[TallTed]

Not saying anything about range or domain (or any other property of anything) in this or any ontology in this Open World of RDF means that the values of those properties must be treated as unknown.

If the values of those properties are in fact known, it behooves us to state them, not least because by leaving them unstated anyone else may assert any value(s) for them, including competing assertions of same and there is no authority to appeal to for the correct value.

SHACL (and ShEx) can be used for after-the-fact data shape enforcement, similar to but not exactly like referential integrity constraints in the SQL world, but these are external definitions and processes. That said, a SHACL processor can take an ontology and its class definitions as input, including but not limited to domain and range, which again supports us putting these properties in place, as the authors of this ontology.

Our doing so does not actively prevent subsequent users from ignoring what we've said because, again, RDF's ontological domain and range do not have the same enforcement effect as SQL's referential integrity constraints. Effectively, domain and range are advisory — and I believe they are generally good advice.

[OR13]

@TallTed I read your reply as a request to specify domain and range for all normative vocabulary items.

Is there any reason why we might only domain?

Second concrete proposal:

1. Reserve the terms
2. Define abstract classes for all domain and range.
3. Specify domain and range for all predicates

[iherman]

Our doing so does not actively prevent subsequent users from ignoring what we've said because, again, RDF's ontological domain and range do not have the same enforcement effect as SQL's referential integrity constraints. Effectively, domain and range are advisory — and I believe they are generally good advice.

It is a bit more than that. If the environment makes a minimal amount of RDF(S) reasoning, then domain/range statements are licenses to infer. If the vocabulary says:

voc:prop rdf:type rdf:Property;
    rdfs:domain voc:A.

and the actual data includes the statement

ex:a voc:prop ex:b .

then a reasoner can infer that the following is also true:

ex:a rdf:type voc:A

which may be good or bad, depending on the application.