Simplify API Surface Area for the Health Cards Spec (removing DID, SIOP)

[jmandel]

Looking at the number of in-flight efforts focused on sharing immunization records with consumers, it's more important than ever that we focus the specification with an eye to implementability and equal access for users without smartphones.

Over the weekend I tried the experiment of: "given what we know now about how Health Card VCs are going to be used, how could we simplify the SMART Health Cards spec?" Here's what came to mind:

• We could eliminate user DIDs from the picture. They're already optional, and in some of our most important flows they're unlikely to be available. They provide some additional information to a verifier (basically: the device making this presentation was also able to access a patient portal account at some point), but this information isn't really actionable.

• Without user DIDs, we could eliminate the need to bind an issuer to a holder ahead of time. This means we could allow OAuth-authorized SMART on FHIR clients to call $HealthWallet.issueVc without having to call $HealthWallet.connect first.

• We could replace issuer DIDs with hosted JSON Web Key Sets. Basically, if we assume that issuers can be identified by URL, then we can establish the convention that .well-known/jwks.json should be available. This allows verifiers (or trust frameworks) to easily find and cache results. While it doesn't offer all the benefits of a decentralized system, it solves the problem at hand in a reasonably decentralized way (i.e., issuers can act independently and can be trusted independently, with an overlay-based trust framework); and it gives us a place to tie in things like certificate chains for hierarchical trust if we want that down the line.

• For Verifier::Holder conversations, we could replace the "DID SIOP" flow with a combination of QR-based presentations (for paper users, or smartphone users who don't want a "full wallet" app experience) and on-device inter-app communications (where a 3rd party app can request specific health cards from a wallet on-device)

What do we gain:

• Simpler, smaller surface area for implementation
• Focus on capabilities that have strong cross-platform library support
• Cut dependencies on specs that are still work-in-progress

What are the downsides:

• (Maybe) Less interop with the ecosystem of DID-based self-sovreign identity protocols (though our focus on VCs rather than presentation protocols may actually make integration with such wallets easier)
• Issuers need to maintain a stable web presence, or else trust frameworks need to maintain a list of historical JWKS values
• While verifiers can be sure the VC came from a specific issuer based on the JWS, they won't know if the VC was initially issued for a specific holder app directly from a patient portal vs (say) by taking a photo of a QR code over someone's shoulder. This is mitigated by the fact that the contents speak for themselves (i.e., act as a bearer credential with a tamper-proof signature), which has always been the core basis for trust.

[vitorpamplona]

Great to see the movement!

Hopefully one day we can get a VC standard without using JSONs (too much overhead for QR Codes).

The public key format can be significantly reduced to an index. Including the entire PublicKey on a JSON is overkill.

Keep pushing! :)

[jmandel]

Great to see the movement!

Thanks!

Including the entire PublicKey on a JSON is overkill.

To be clear, we only include a JWK thumbprint in the QR, not a full key.

[vitorpamplona]

To be clear, we only include a JWK thumbprint in the QR, not a full key.

Yes, the thumbprint is too big.

[jmandel]

Well okay. The key thumbprint uses ~2% of our payload budget, which isn't ideal but ensures a verifiable binding to key material; there's much lower hanging fruit we could go after if needed.

[vitorpamplona]

We had to reduce it to ~8 bytes on our spec. Every single byte counts :)

[jmandel]

@vitorpamplona can you share a link? We're trying to balance extensibility and "no special processing" goals on the one hand with extremely limited space on the other -- would love to make sure we're not missing opportunities here.

[vitorpamplona]

Sure thing!

Our latest uses a URI Schema on Alphanumeric QR with Base36 for ECDSA/secp256k1 Signature/Hashes and pre-defined positional fields instead of key-value pairs. The goal is to be legible and so small that the payload can ultimately fit into a single SMS message (not there yet). Next step, we are trying some Schnorr signatures and smaller Hashes.

Demo of the latest: https://vitorpamplona.com/vaccine-certificate-qrcode-generator/index.v5.html

Just click Load Demo Data and Sign All to see the QRs.

Base spec for our 4 cards: https://github.com/Path-Check/paper-cred/blob/main/SPECIFICATION.md

[jmandel]

Thanks! The demo is super helpful.

keyId referencing the database and public key used to verify the ECDSA signature

I'm not quite following the model here: what is "the database"? Searched the repo but I'm not finding this. Is the database related to the "PubKey" URL ("www.pathcheck.org/hubfs/pub" in the examples)?

[vitorpamplona]

We want to build a simpler issuing database to save space, but I am not super sure if this is a good idea (who-controls-the-database? types of questions). The idea is to use a format :, example: cdc:1, cdc:2... One id for each public key (maybe one id per state?). Scanner apps can download all public keys from cdc:* to avoid the need for internet when reading the actual codes.

These database names would be reserved keywords in the standard, pointing to given websites.

If the idea fails then we could use a simple URL like the one in the demo.

[jmandel]

Thanks! Yeah, the combination of "Single database" and "key IDs aren't self-verifying" is tough, for a system that's going to be used widely or in diverse contexts. (With Health Cards, the goal is to ensure that a "Trust framework" -- or "database of keys" -- can be layered onto the system, but that everything can work without.)

[agropper]

HIE of One proposes an open federation model to answer the "who controls the database" issue. Allow communities to fork the recommended code and operate their own instance of a managed database. Allow patients to choose the community based on the community managers' reputation and the privacy policies. Make switching costs across communities trivial for the patient. Allow patients to use a mobile app as an option if they really don't want to trust any community.