WHO SVC Test Suite coordination with W3C CCG?

[msporny]

A few of the members in the W3C Credentials Community Group have been working on a Vaccination Certificate Vocabulary that is compatible with the WHO SVC work. The W3C CCG has also been working on a Verifiable Credentials HTTP API.

For those that are not familiar with the W3C CCG, it is the group (consisting of 400+ members) that created and standardized the Verifiable Credentials and Decentralized Identifier global standards (among many others that are currently being developed). These standards are used by a large number of digital vaccination certificate projects around the world (EU, US, NZ, etc.).

We (Digital Bazaar) thought it might be interesting to see if we could create one (of possibly many) interoperability test suites for the WHO Smart Vaccination Certificate data model using the tools listed above.

The test suite covers 28 types of vaccines that are covered in the SVC work, including Measles, Smallpox, Polio, Yellow Fever, COVID-19, and others.

Please note:

• This is all experimental; it's not meant to step on any toes (the 40+ other vaccination certificate projects).
• The solution is designed to address all goals listed in the recently published WHO document on SVCs.
• The certificates, dictionaries, and tests will track changes WHO SVC work (and are designed to be rapidly regenerated and tested).

With that said, we've been able to achieve the following:

• A test suite containing 1,624 tests covering the 28 vaccine types in the WHO SVC dictionary.
• 7 independent vendor implementations issuing and verifying each others WHO Smart Vaccination Certificates.
• 1,623 passing tests demonstrating objective results wrt. technical interoperability.

You can view the latest Vaccination Certificate test suite report here:

https://w3id.org/vaccination/interop-reports

The announcement to the W3C Credentials Community Group is here:

https://lists.w3.org/Archives/Public/public-credentials/2021Apr/0081.html

How can we best coordinate the test suite work with VCI? We have a number of concerns related to the claims made about SMART Health Cards being conforming Verifiable Credentials (they are not)... how can we help to close this gap?

[jmandel]

Thanks Manu! To make sure we're using consistent terms, I want to note that you may have inadvertently combined two similar names when you wrote "WHO Smart Vaccination Cards"; this looks like a mixture of terms between the "SMART Health Cards" project and WHO's "Smart Vaccination Certificates" project (yes, the naming here is confusing).

We should emphasize that WHO is still early in the process of defining requirements for QR representations in its "Smart Vaccination Certificate" project. As such, it creates confusion to describe Digital Bazaar's work here as an "interoperability test suite for the WHO Smart Vaccination" effort -- perhaps it would be more accurate to describe this as more like "an interop test suite that represents the kind of thing we hope WHO will adopt". (WHO's process is not public, but I'm participating along with other invited experts, and I think it's fair to say that participants are bringing many considerations to the table, and no specific choices have been made yet about details for various QRs and their contents to support diverse workflows.)

Having said that: VCI's work is focused on the SMART Health Cards specification; we have information about testing and validation resources at https://smarthealth.cards/#what-testing-tools-are-available-to-validate-smart-health-cards-implementations.

[agropper]

How are patients identified in these various standards?

Is there a photo when presented?

What's the relationship between the patient identity and the verifiable credential?

[jmandel]

There's good context in https://smarthealth.cards/#can-a-smart-health-card-be-used-as-a-form-of-identification and the related FAQs.

The specific demographics in a Health Card are: name + date of birth. https://smarthealth.cards/examples/example-00-a-fhirBundle.json has an example showing what this looks like.

[msporny]

Thanks Manu! To make sure we're using consistent terms, I want to note that you may have inadvertently combined two similar names when you wrote "WHO Smart Vaccination Cards"; this looks like a mixture of terms between the "SMART Health Cards" project and WHO's "Smart Vaccination Certificates" project (yes, the naming here is confusing).

Thanks for pointing that out, @jmandel ... I've fixed the language in the original post.

it creates confusion to describe Digital Bazaar's work here as an "interoperability test suite for the WHO Smart Vaccination" effort -- perhaps it would be more accurate to describe this as more like

I have re-worded the language to state:

We (Digital Bazaar) thought it might be interesting to see if we could create one (of possibly many) interoperability test suites for the WHO Smart Vaccination Certificate data model using the tools listed above.

While we are on the topic of "creating confusion", there are a number of things that I (and other VCI participants) continue to be confused about:

• Why it is being assumed that the Microsoft's proposal for "SMART Health Cards" are being viewed as the de-facto solution for VCI? Was there a vote to adopt this as the solution? I've been participating since the 2nd meeting and at no point was the question put to the group. I was under the impression that this would be a technical specification working group that was considering multiple potential solutions.
• Why does the SMART Health Cards specification note that it is built on the Verifiable Credentials open standard, yet is incompatible with the specification in a number of ways and implements bespoke key management solutions that are not common in the Verifiable Credentials ecosystem?

These are just two of many questions I (and a number of other VCI participants) have. I have to run to another call now, but expect that we'll pick this discussion up during the next call. I am concerned that a pseudo-proprietary solution is being rushed to market and would like to discuss this with the group.

[jmandel]

To clarify the expectations here in human language:

• fhirVersion conveys a value from the "Version" column of http://hl7.org/fhir/directory.html (a slowly moving target)
• fhirBundle is a valid FHIR JSON Bundle resource

We'd be very open to contributions that would improve the @context defined in the mapping at https://smarthealth.cards/credential-modeling/#mapping-into-the-w3c-vc-data-model, as long as they are aligned with these expectations.

[OR13]

@jmandel you should provide a complete example without @vocab, for example:

Setup a redirect for your name space, in case you decide smarthealth.cards doesn't feel professional enough, you won't be stuck using it forever to provide documentation for your vocabulary...:

Example:

https://w3id.org/health-cards/v1 -> your context.json
https://w3id.org/health-cards -> https://smarthealth.cards/ (your vocabulary).

{
    "fhirBundle": {
      "@id": "https://w3id.org/health-cards/#fhirBundle",
      "@type": "@json"
    },
    "fhirVersion": {
      "@id": "https://w3id.org/health-cards/#fhirVersion",
    }
  }

"@context": [
  "https://www.w3.org/2018/credentials/v1",
  "https://w3id.org/health-cards/v1"
],
....
"type": ["VerifiableCredential", "SmartHealthCard"],
"credentialSubject": {
  "fhirVersion": "4.0.1", // you support latest version?
  "fhirBundle": "{ example data here }"
}

Then copying the updated example from `https://smarthealth.cards/credential-modeling/#mapping-into-the-w3c-vc-data-model, and testing it as valid JSON & JSON-LD should produce no errors, etc... you might also consider using the issuer object to provide better descriptions of the issuer, for example:

"issuer": {
... https://www.hl7.org/fhir/organization.html

Since turtle is supported HL7/FHIR have you considered helping map WHO vocabulary to HL7/FHIR ?

For example:

• http://hl7.org/fhir/Organization ?
• https://www.hl7.org/fhir/organization-definitions.html#Organization ?

It would seem you are going a bit out of your way to just shove everything into an untyped JSON object...

Is this a real example of "fhirBundle"?,

Maybe there are some parts of it that are always present that you can define for us all, and then we can push @json types down until you hit some really strong evidence of needing to support arbitrary JSON?

for example:

"resourceType": "Bundle",
"type": "collection",

I assume these are always present?

How much extra work would it be to transform this FHIR data into a WHO format? wouldn't it be easier to normalize your data before exporting it, instead of treating HL7 /. FHIR as the representation? That way your credential format would work for folks who don't have an EHR, you know... how much of this data is really available over FHIR today? Are we optimizing the credential format for a tiny pipe to a small pond? vs making an open interoperable data format that works for everyone?

[tplooker]

wouldn't it be easier to normalize your data before exporting it, instead of treating HL7 /. FHIR as the representation

Yeah +1 to this approach, one of the reasons we set out to work on the vaccination vocabulary was because relying on another data model definition (e.g FHIR bundles for vaccine certification representation) makes it virtually impossible to meet other requirements that projects like FHIR dont have, like achieving a concise representation. Put another way, FHIR defines a verbose and extensible data model for health related resources primarily to be exchange in web based RESTful APIs, whereas vaccination certificates are concise cryptographically secure assertions for the purpose of proving the vaccination status of an individual, ones that MUST work in much lower tech and constrained mediums such as transferable via optical code tech (e.g QR codes).

[dleve123]

@OR13 - thanks for your perspectives here! Correct me if I wrong, but it seems like a major point you are trying to raise is that not publishing a specific vocabulary (by that, I mean describing the nature of the FHIR resources, not just naming them) in @context is fundamentally against the grain of a W3C conformant Verifiable Credential.

Assuming that is correct, for those of us that are less familiar with VCs outside of this use-case, can you provide some rational for why more precision here is important? Is there widely adopted tooling that uses @context to structurally validate a VC against its stated @context? Other considerations? Would be great to learn a bit more about the practical considerations here!

[jmandel]

I want to see if I can explain some of the underlying tension here. Let's start with a shared goal: the SMART Health Cards community and the JSON-LD community are both deeply interested in semantic interoperability. Within this context:

• SMART Health Cards community looks to well-crafted FHIR profiles and the underlying FHIR Core specification as the source of semantic interop.

• JSON-LD community looks to well-crafted JSON-LD @contexts and the underlying JSON-LD Data Model as the source of semantic interop.

An ideal outcome would full address both. That said, there are pragmatic design tensions. We'd like to craft the best JSON-LD @context we can without changing (i.e., breaking) the FHIR JSON data structures that the international healthcare community has invested in deeply.

(N.B., I'm not saying there couldn't be long-term value in shifting the healthcare community away from vanilla FHIR JSON, but that's a very different discussion and out of scope for this project. For context, the FHIR JSON syntax is normative today, and while it has some real warts and could in theory be augmented with alternatives, we had a last call around these decisions back in 2018 and this is where we landed.)

From https://w3c.github.io/json-ld-syntax (emphasis added):

The [JSON-LD] syntax is designed to not disturb already deployed systems running on JSON, but provide a smooth upgrade path from JSON

From https://json-ld.org/spec/latest/json-ld-api-best-practices/ (emphasis added):

While most use of JSON-LD should not require a client to change the data representation, JSON-LD does allow the use of various algorithms to re-shape a JSON-LD document.

SMART Health Cards implementers want to leverage the existing JSON structures they rely on; they've spent years building systems and stacks to support FHIR Bundles in this way, and several requirements are included in regulations. Within this constraint, let's design the very best @context we can and document it at https://smarthealth.cards/credential-modeling/#mapping-into-the-w3c-vc-data-model (or anywhere else the JSON-LD community would find helpful). I'd be happy to take suggestions on how to improve the documented mapping without breaking the serialized data structures.

(Re: WHO, I should note that their interim guidance defines a "core data set" rather than a "vocabulary" for vaccination certificates. In SMART Health Cards, https://github.com/dvci/vaccine-credential-ig is the FHIR Implementation Guide that explains how these functional requirements are met through the use of FHIR Bundles.)

[agropper]

This is an important conversation that needs to separate the vocabulary dimension from the identity dimension.

The identity aspects relate to equity and involve access to technology, employment, and participation by the undocumented.

There is obviously some relationship between the vocabulary and identity dimensions, if only because the overall size of the credential is limited by printing and technology cost constraints.

One thing that stands out, for example, is the statement that the patient/subject will be identified by Name and DOB. Would we ever identify someone by Name and License Number or would we ever include a code for Level of Assurance? Do we allow people to self-identify in order to improve access by the undocumented? Are we setting a precedent for rapid testing, including home self-testing?

Public health is another dimension. Every digital credential issued is an opportunity to collect valuable information on prevalence, side-effects, and disparities. Every credential could also be associated with voluntary self-reporting. Getting digital privacy right will have more impact on society than anything having to do with the digital vocabulary conversation.

[jmandel]

Agreed these are important to keep separate. On that note, I'd suggest creating a distinct topic for this. Keep in mind that for the use case of verifiable vaccination records, the implementation guide where these details are defined is https://github.com/dvci/vaccine-credential-ig.

[agropper]

The IG link is inscrutable to me @jmandel If you care to factor out the privacy and equity issues from the vocabulary issues, then please launch and scope that discussion in whatever format fits your process. I will gladly contribute there.

[agropper]

Here's an example of a self-verifying, paper-compatible, health card: https://docs.google.com/document/d/1o_773vzcbtSf59oU-iRUfAy5WSz3Wn9JUAvi0hKHE48/edit# created with the help of Spruce didkit. Self-verifying means that (once the hash of the quantized image is included in the credential (in place of the DOB, for example) there is no need for the verifier to connect to a centralized identity provider for the subject. Unless, of course, the VC needs to have a revocation method :-). This example uses a custodial VC as the presentation that, with appropriate access controls like GNAP, would be compatible with FHIR. A self-contained version of the health card would benefit from a compressed format, of course. I'm not sure how FHIR-compatibility would work in that case.

…

On Fri, Apr 16, 2021 at 2:17 PM Josh Mandel ***@***.***> wrote: Agreed these are important to keep separate. On that note, I'd suggest creating a distinct topic for this. Keep in mind that for the use case of verifiable vaccination records, the implementation guide where these details are defined is https://github.com/dvci/vaccine-credential-ig. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#120 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABB4YOSPNN72MNW7H5ZNMDTJB5NLANCNFSM42VK2THA> .