Stream: smart/health-cards
Topic: Identifying smart cards
Grahame Grieve (Oct 05 2021 at 19:52):
An issue raised with me after the HL7 Australia webinar on smart health cards yesterday: there's no way for the issuer to include any identifier in the card source that allows it to link the card back to an internal context; any queries/provenance related information has to be resolved by a human.
It's possible to arrange the issuing of the cards such that the nbf property in the jws is unique, but that has obvious problems at scale. Or else the source system could include a jti - I don't see that the spec rules it out, since it doesn't comment on it. Has anyone used the jti for that? Or else the spec could allow the bundle to have an id, which would be the same as the jti field.
Comments?
Josh Mandel (Oct 05 2021 at 23:13):
We don't rule this out; we generally try to avoid creating any unnecessary correlation handles, but if do you have a valid use case for this it's not something that we would expect to cause problems. JWT specification defines default semantics indicating that clients should ignore any claims they don't understand.
Max Masnick (Oct 06 2021 at 10:31):
Bundle.id can be populated in our fallback profile.
I think it's appropriate to not have id included in the primary (data minimization) profile, but if you disagree please let us know.
Grahame Grieve (Oct 06 2021 at 10:45):
I think jti is better. it's the jws itself, not the bundle, that has an id.
Grahame Grieve (Oct 06 2021 at 10:52):
But I think this is worth a comment - a line, at max, in the smart card spec. (not the ig?)
Josh Mandel (Oct 06 2021 at 13:06):
What would the line say? Implementers SHOULD NOT create unnecessary correlation handles but MAY populate standard JWT claims such as jti if their infrastructure requires it?
I'll note that the (say, sha256) hash of the entire JWS might also serve this need without adding to the payload size.
Grahame Grieve (Oct 06 2021 at 13:42):
but shas may clash. Likely to - much more than nbf. So I don't think you could use that
Josh Mandel (Oct 06 2021 at 13:48):
Wait, what do you mean by "might"?
Josh Mandel (Oct 06 2021 at 13:49):
Josh Mandel (Oct 06 2021 at 13:53):
That said, it's important to talk about the use case here. My understanding was that you just wanted a handle for issuer-internal lookups/workflows. It would be very easy for a given an issuer to make sure they never issue two cards with the same identifier (whether that's a random jti or a hash over the card or anything else).
Josh Mandel (Oct 06 2021 at 14:40):
(keep in mind also that the sha256 hash function is used by the ES256 signing algorithm, so if you could generate sha256 collisions, you could swap JWS payloads at will :-))
Christian Paquin (Oct 06 2021 at 14:54):
A SHA-256 collision would immediately invalidate the algorithm and lead to its deprecation; it is safe to assume collisions are infeasible (vs. impossible) to obtain (assuming its preimage is unique, which is the case if you hash the full SHC).
Grahame Grieve (Oct 06 2021 at 21:10):
well, technically, what matters with a hash for a signature is not there will never be collisions, but that it's infeasible to compute an alternative source that leads to the same hash.
Grahame Grieve (Oct 06 2021 at 21:12):
"never issue two cards with the same hash over the card" - hard because what do you do if it does generate the same hash? I suppose you regenerate it with a new nbf and you're good.
Grahame Grieve (Oct 06 2021 at 21:13):
but ok, sha-256 is a lot more resistant to collisions at all than I estimated in my head (I was many orders of magnitude out :slight_frown:)
Grahame Grieve (Oct 06 2021 at 21:17):
so it wouldn't hurt to have a sentence somewhere: 'issuers that want to identify cards later for provenance/investigation purposes can either (a) remember the hash of the card, (b) ensure that the nbf values are unique, or (c) populate the jti in the payload (not recommended, because of byte minimization)
Last updated: Apr 12 2022 at 19:14 UTC
