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.