Document end-to-end protocol and data format choices

[msporny]

I'm one of the global standards Editors for the W3C Verifiable Credentials specification, W3C Decentralized Identifier specification, and a variety of ecosystem-supporting specifications. These specifications allow for a variety of design choices to be made; we did this to ensure that we were building big tent where most anyone could participate in building solutions. The downside to that philosophy is that there are a varied number of technologies that are sprouting up that, while compatible with the specifications, are incompatible with each other in many practical settings. In order to ensure that decision makers have clear guidance wrt. what technologies work well together, there are government-funded programs (in the US, Canada, and EU) that are focusing on creating interoperability test suites that test the software produced for these ecosystems for interoperability.

Therefore, it is important for the health cards initiative to clearly articulate which technologies are being used for each stage of a Verifiable Credentials exchange and how many organizations have working solutions for each technology. This issue is being created to track the various options that are available and how many organizations are supporting those options today.

[cjbuchanan]

Thanks, Manu. This is the work I described on our call last week and is a follow-on to #35. @jmandel: Recommend 35 be closed as completed as VCI decided to move forward with the mapping and this issue will serve to actually create the document.

[jmandel]

Thanks! As one input into the discussion, https://github.com/smart-on-fhir/health-cards/wiki is a list I put together last year documenting the key areas required for some level of interoperability within the Health Cards ecosystem. (I expect these map into the trust over IP framework but perhaps at a different level of granularity or emphasis.)

[agropper]

I am a contributor to the global standards for W3C Verifiable Credentials and W3C Decentralized Identifiers data models in the role of invited expert on privacy. I am also an author of the W3C Use Cases and Requirements for Decentralized Identifiers spec including the healthcare focal use-case.

The end-to-end protocol choices we make in health-cards should be informed by the privacy and adoption challenges associated with pandemic response. Some of these are discussed in #49 (comment).

[jmandel]

I've updated the wiki page with a section at the bottom to make these protocol and data format choices explicit. @cjbuchanan hoping this will help with the mapping work.

[cjbuchanan]

Updated document here. Pull request submitted (#63 ).

@jmandel I will have to update with protocol choices, so if you want to reject pull #63 I'll request again later, or we can just link the Wiki page to the document. Happy to do it either way.

[agropper]

If our primary objective is adoption of VCs by issuers and verifiers of a vaccine (and/or test) credential, it would be good to minimize issues related to the patient / holder role including tech and trust. Therefore, we should consider:

• Need to present a device (as opposed to just a QR code on paper)
• Ability to work with a guardian for children and incompetent patients
• Disparities for people who don’t have a smartphone
• Compatibility with adding a test results VC hours after a sample was taken
• Building trust and scale by giving patients a choice of communities for support

One way to achieve all five of these goals is by putting the holder online and making a mobile app optional for patients that want it. The online holder would be an HTTP (GNAP) authorization server that processes requests according to the patient's policy (as inherited from a "branded" community group). Policies as well as credentials would be stored, with encryption, in a scalable data vault like CouchDB.

Requests for accepting or presenting credentials would be processed based on policy and a patient's choice among three options:

1. The data requested is public - the AS just logs the request and maybe sends SMS / email to the patient
2. The patient or guardian receives a SMS / email with the request and responds with a previously received decryption key. The AS uses the key to decrypt / re-encrypt the credential, issues a token, and then discards the key pending the next request.
3. The patient or guardian installs a mobile app (based on PouchDB) that syncs their records with the online database (CouchDB). The AS never sees the encryption keys but can respond to the request with access tokens to the online encrypted data vault.

This approach makes patient DIDs optional. If they are desired for the VCs, adding a public DID document to the CouchDB is an option, but other methods will work as well. Also, the separation of concerns between policy decision (AS) and policy enforcement (an online resource server) is aligned with ongoing standards work in W3C / DIF on encrypted data vaults.

[jmandel]

@cjbuchanan I've been heads-down working through #64 which obviously would have impact here. I don't mind merging #63 with a link to the wiki page, but we might also wait a bit until these details shake out -- your call!

[cjbuchanan]

Based on this issue and the feedback for #63, I think mapping a path from VCI to GHPC principles would satisfy both issues... (if I change the scope of #63). It seems that everyone who would have taken the VCI to trust framework mapping has already joined GHPC. This would also elevate it to a tech agnostic path.