FHIR Chat · VCI directory auditing · smart/health-cards

Stream: smart/health-cards

Topic: VCI directory auditing


view this post on Zulip Christian Paquin (Aug 05 2021 at 14:28):

It would be useful to have a audit system for the VCI directory. I’m thinking a daily script (github action?) that would download each issuer’s key set, validate the keys, and log differences from day to day. This would help keep track if a particular key is removed (consciously revoked, or accidental removal) and help debug unreachable issuers (momentarily offline vs. out-of-business). We could also think about creating a daily known keyset of all VCI issuers, to allow offline verifiers to pre-load the keys and validate SMART Health Cards. Thoughts?

view this post on Zulip Josh Mandel (Aug 06 2021 at 17:48):

I think this would be great in terms of transparency, and useful for a bunch of purposes downstream, as you suggest!

view this post on Zulip Paul Denning (Aug 06 2021 at 20:35):

Where would the "daily known keyset" live? Isn't part of the trust the fact that you retrieved it from the iss, not some 3rd party? I assume verifiers would periodically grab all of the keys (individually) using the iss from https://github.com/the-commons-project/vci-directory/blob/main/vci-issuers.json (or their trusted source of this info). I like the idea of knowing about changes. Where would you get a sample of something signed with the private key to validate the public keys?

view this post on Zulip Josh Mandel (Aug 06 2021 at 21:51):

Our use of kid computed from the hash of JWK contents means that a JWK is self-authenticating -- the problem of "has a certain key been revoked by the issuer?" doesn't go away, but the problem of "resolve this kid to a JWK JSON struct" is easier (you can't "lie" about the value of a JWK).

view this post on Zulip Christian Paquin (Aug 07 2021 at 16:22):

Paul Denning said:

Where would the "daily known keyset" live?

Hosting it somewhere next to the VCI directory itself would provide equivalent security.

Isn't part of the trust the fact that you retrieved it from the iss, not some 3rd party?

Yes. That's the ideal case, but what happens if you can't reach the iss endpoint? Is the verifier connection down? Is the issuer down? This could happen even if the card is valid and should be accepted. I'm thinking about cases where verifiers, potentially disconnected, need to quickly validate multiple cards quickly (e.g., mass transit system, or big concert venues); it would be useful to load a valid daily set of keys to speed up validation and avoid communication failures.

I assume verifiers would periodically grab all of the keys (individually) using the iss from https://github.com/the-commons-project/vci-directory/blob/main/vci-issuers.json (or their trusted source of this info).

This is currently an implementation detail; a validation app could certainly do that, but this is time consuming and requires non-trivial management (especially for a mobile app). A centralized, common list would be easier to use.

I like the idea of knowing about changes.

That would be the main value; audit changes, and VCI could follow-up with issuers with "strange" key sets, or reach out if keys are removed, to make sure issuers are aware that this effectively revoke all cards issued under those keys.

Where would you get a sample of something signed with the private key to validate the public keys?

You wouldn't need it. We can check that the key is a valid JSON cryptographic public key.

view this post on Zulip James Kizer (Aug 10 2021 at 19:47):

I think this is a great idea. Happy to find some time to talk through the details @Christian Paquin

view this post on Zulip Christian Paquin (Aug 10 2021 at 20:05):

We can have a chat with whomever is interested next week. I'll be away for the rest of the week on vacation...

view this post on Zulip Christian Paquin (Aug 20 2021 at 21:23):

I've put some proof of concept code together here for the first part of the proposal: directory auditing. The tool (which could be run daily by, say, a github action) fetches and saves the jwks from every issuers, checks for duplication (in names, key IDs, iss urls), logs endpoint errors, and compares with a previous log to see how the directory changed (e.g., key ID removed).

If you want to play with it, run npm run audit to scan the VCI directory, or npm run test-audit-X with X=1,2,3 to scan a test directory that changes twice.

view this post on Zulip Christian Paquin (Sep 17 2021 at 20:57):

Would it be a good idea to have issuers publish a signed SMART Health Card with their application to join the VCI directory? We currently ask them to run the validation dev tool, but having access to a sample SHC would allow 1) auditing scripts to check proper conformance to the spec, and 2) allow 3rd party validator to test their implementations. One issue is that depending when their implementation was completed, an issuer might not be conformant to the latest version of the spec. These cards could be generated with well-known, common test values to avoid using real-user data.

view this post on Zulip Josh Mandel (Sep 17 2021 at 21:09):

I agree this would give us better overall assurance, and would let us move toward a more automated process for getting there.

view this post on Zulip Josh Mandel (Sep 17 2021 at 21:09):

(even if we don't require this, I think it would be worth recommending. I guess we'd want to have some kind of standardized patient record for the examples, with names and birth dates that would be unambiguously fake.)


Last updated: Apr 12 2022 at 19:14 UTC