Id mapping of VCI to trust framwork.

[cjbuchanan]

This will complete issue #59 when accepted.

[agropper]

Thank you @cjbuchanan for this analysis of @jmandel's protocol choices wiki.

Please consider using this analytical approach for an alternate standards and privacy design proposal:

Whereas:

Goal: Speed and ease of adoption of W3C VCs for COVID vaccination
Stipulate: “The justifiable parties are limited to patients, issuers, and validator HCPs utilizing VCI standards to ingest HL7 FHIR v4 data”
Document: VCI standards and trust-related issues to meet the Goal by facilitating “very-near-term-adoption” issues.
Consider: Various DIDs may be useful for some of the justifiable parties and their relationships but are a nice-to-have and not essential to the Goal.
Consider: That VCs, FHIR, JWS, JWE, and OAuth2, and arguably DID Core are the only ‘real’ standards in this use-case. Protocols and methods such as DIDcomm, DID-SIOP, did:ion, did:web, did:key, and GNAP are works-in-progress but all are under intense development and evolution at this time.

Proposed:

Health Cards would be more likely to succeed at rapidly introducing SSI principles to COVID vaccinations if the core component associated with a patient was a fiduciary GNAP authorization server as a service. See also the thread #49

[cjbuchanan]

@agropper -- good recommendation. I think that makes it clearer for everyone. I will have to get some clarification of the goals.

[Sakurann]

Health-Cards do not use DIDs AFAIK

[jmandel]

Work on the trust framework mapping document stalled in early 2021; @cjbuchanan should we remove this document from the repo?

[cjbuchanan]

@jmandel I'm happy to revise it to fit the current implementation, but I'd need to do some catching up. What is your preference?

[jmandel]

@cjbuchanan I think this is at your discretion; this isn't something our implementer community has been clamoring for, but I'd be happy to include it if you think it'd be valuable.

[agropper]

Per my Feb 6 #63 (comment), let's consider the scope of FHIR 4.0 compatibility we are proposing:

• MUST a Health Card always fit the FHIR 4.0 data by value or MAY it be by reference to the issuer?
• MUST a Health Card presume patient matching or MAY it include a biometric?
• How important is it for Health Cards to support delegated access to the FHIR 4.0 data (see the Cruise Ship Use Case )

[jmandel]

@agropper: back in Feb we decided on these issues: SMART Health Cards v1 supports only the model where data are directly embedded in a JWS (not shared via links to an external server), and identity binding occurs through demographics in the FHIR Patient resource that's embedded in the fhirBundle inside this JWS.

On the subject of links to "cloud-hosted" verifiable data, we have had some more recent community discussion on https://chat.fhir.org/#narrow/stream/284830-smart.2Fhealth-cards, and I've written up some notes at https://hackmd.io/kvyVFD5cQK2Bg1_vnXSh_Q . Please keep in mind that we're exploring this concept on a track distinct from SMART Health Cards, but if we get consensus on an approach it'd obviously be complementary to the SMART Health Cards core spec, and we can talk through ways to more fully integrate it. But one step at a time; any workflow where potentially sensitive data are hosted online raises a number of questions that we've done well to put aside up until now.

[jmandel]

Closing after 1y of inactivity (current PR is from before our 1.0 release and does not correspond to our published framework). Happy to revive if there's interest in re-mapping.