If your claim is not durable enough for the protocol's expiration setting (e.g. authorization, in some cases), then don't abuse JWTs. Simple!
Makes it really easy to scatter low budget devices across the state that require no Internet connection, and gives a red light/green light on whether you're allowed to go shopping or be out in public that day.
All the infrastructure is right there in place. Didn't get that far.
This time.
Anyway, all of that "infrastructure" is people making judgments. It will enable a police state if the people think they should enable it.
What would the procedure that can guarantee no mistaken passport will ever get signed look like?
Of course you need some form of revocation, otherwise the first bad apple will spoil the system.
When the issuer is ready to generate a Health Card, the issuer creates a FHIR payload and packs it into a corresponding Health Card VC (or Health Card Set).
The VC structure (scaffold) is shown in the following example. The Health Cards framework serializes VCs using the compact JWS serialization, where the payload is a compressed set of JWT claims (see Appendix 3 of RFC7515 for an example using ECDSA P-256 SHA-256, as required by this specification). Specific encoding choices ensure compatibility with standard JWT claims, as described at https://www.w3.org/TR/vc-data-model/#jwt-encoding.
Especially when I signed the opt out form requesting to not be placed on the database.
Especially 2.0, when I called the database, and was told that my records could not be deleted.