Stream: smart/health-cards
Topic: Revocation of VCI Credential
Ashier De Leon (May 20 2021 at 00:13):
Is there any standard way of revoking a VCI credential? @Michael Turman @Joe Rattazzi
Josh Mandel (May 20 2021 at 00:57):
No. Issuers with compromised keys can revoke their signing keys by omitting them from their jwks.json, but there is no standardized way to revoke an individual SMART Health Card.
Ashier De Leon (May 20 2021 at 03:24):
Thank you @Josh Mandel for the quick revert. Signing key meaning the Issuer's private key right? Hmm, then revoking the issuer's private key will revoke all keys issued under that signing key. What is your recommendation to have the ability to revoke a single credential?
Josh Mandel (May 20 2021 at 04:31):
This hasn't been a design goal, so we haven't standardized a mechanism. Practically: Trust Frameworks could establish their own patterns on top of the SMART Health Cards spec. For example, via revocation lists. e.g., participating issuers could add unique identifiers to each Card via a JWS claim, and the trust framework or specific issuers could publish lists of revoked identifiers. One key consideration is privacy (e.g., protecting users from being tracked by issuers); it's important to ensure that checks don't reveal a specific certificate ID (but rather, ensure that revocation checks can be aggregated at the level of a group of, say, 10^5 or more certificates).
Ashier De Leon (May 20 2021 at 07:04):
Thanks @Josh Mandel
Richard Braman (FLY.HEALTH) (May 20 2021 at 12:08):
When I first implemented our system, I backed the entire thing by PKI. Every cert was signed with a RSA private key and every VC was backed by a digital certificate. That would enable certificates to be revoked. I am still maintaining that branch; however there are some technical concessions that have to be made to do it this way.
Josh Mandel (May 20 2021 at 13:11):
Hmm, @Richard Braman (FLY.HEALTH) does this imply that you were using a different iss URL for every Health Card you issued? This would create a direct and unavoidable privacy/tracking concern, and it's a behavior we probably want to prohibit at the spec level. (This isn't something that has come up in discussion before, as far as I'm aware.)
Michael Turman (May 20 2021 at 13:36):
The spec does not detail a method of 'expiration' for the health card today. The card could be 'revoked' if the public keys associated with the Issuer's signature are no longer valid or are not registered with a trust network the Verifier uses.
Edit: went to 'Mentions' and didn't see all the responses - doh!
Richard Braman (FLY.HEALTH) (May 20 2021 at 13:49):
@Josh Mandel No, the iss URL was the same. In the PKI model, the credential subject is created from the certificate Subject and extended Subject attributes. So it was not the FHIR bundle. But truthfully, the data in the extended subject attributes could be converted back to the FHIR payload for purposes of conforming 100% to the SHC spec. In its current form, the PKI implementation conforms to the Wc3 VC spec, but not 100% to the SHC spec.
Christian Paquin (May 20 2021 at 22:38):
Ashier De Leon said:
Is there any standard way of revoking a VCI credential? Michael Turman Joe Rattazzi
Which revocation scenario do you have in mind? Revoking erroneously issued health cards? As Josh said, not part of the spec, and might not be "critical" since there is no user key material to protect, but issued cards could be put on a revocation list using any UID derived from it (e.g., hash of the JWS).
Ashier De Leon (May 20 2021 at 23:27):
@Christian Paquin
Erroneous, yes. Also, like issuing Lab results, it may only be valid for a few months, right? So, like if we are verifying a VC, should we consider it still valid even the contents are already expired?
Christian Paquin (May 20 2021 at 23:45):
Ashier De Leon said:
Christian Paquin
Erroneous, yes. Also, like issuing Lab results, it may only be valid for a few months, right? So, like if we are verifying a VC, should we consider it still valid even the contents are already expired?
Revocation is typically for "unplanned" situations (key compromise, creds issued in error, etc.), should be a different strategy than "planned" or defined usage, such as a limited validity period. The scope of the spec is to provide the clinical data, what happened, when, by/to whom. The fact that the lab result might not be valid anymore to make a health assessment doesn't make the health card itself invalid; verifiers will be able to make their authorization decision based on the data authenticated by the issuer.
Ashier De Leon (May 21 2021 at 01:21):
Thanks for the clarification @Christian Paquin
Last updated: Apr 12 2022 at 19:14 UTC
