Clarify multi-JWS treatment in QR codes

[christianpaquin]

The spec allows for a .smart-health-card file to contain multiple JWS in the verifiableCredential property (as specified in the via File Download section).

What is the intent for QR codes? The Every Health Card can be embedded in a QR Code section says:

the same JWS strings that appear as .verifiableCredential[] entries in a .smart-health-card file SHALL be encoded as Numerical Mode QR codes consisting of the digits 0-9 (see "Encoding Chunks as QR Codes")

and the referred section refers to "Each chunk of the JWS string", singular.

Now, what's the intent here? One QR per JWS, or a QR with concatenated JWS? If the latter, how? Also if the latter, why have a different behavior for files and QRs (another way of asking: do we really need that multi-JWS per card feature?)

(stemming from issue 61 of the validation SDK)

[jmandel]

The intention right now is:

• multiple health cards (JWSs) can be packaged into a single JSON file
• a singe health card (JWS) can be represented in a QR (or, if it's too big, >1 QR)

We've had some discussion about a presentation format for concatenating >1 (small) health card JWS in a single QR (e.g., by ;-separating them), but we haven't decided to do this yet; may do in the future if it becomes important to present multiple cards from disparate issuers in a single flow.

why have a different behavior for files and QRs (another way of asking: do we really need that multi-JWS per card feature?)

Aim was to support the simplest flow we can for downloading content from a portal into an app, since some issuers aren't supporting API-based issuance with the FHIR operation; one file with a pile of JWSs lets you bring in a bunch of data all at once (e.g., a set of historical immunizations in separate cards) even though you might share them one at a time as QRs.

[jmandel]

I wouldn't necessarily object to restricting the .smart-health-card file to contain a single JWS; it might be more complexity than it's worth.

[christianpaquin]

I wouldn't necessarily object to restricting the .smart-health-card file to contain a single JWS; it might be more complexity than it's worth.

It does introduce some complexity for verifiers, so it depends on the scenarios. There are no restrictions between the JWS, so the "card" could effectively become a "wallet" (is that even allowed, have multiple JWS from different issuers? Spec says yes, right?). On the other hand, @kevin-durand (who opened the issue) has a use case for it, so it's ok if it is useful to deployers.

If we keep this, I suggest adding a few clarifications to the spec, and adding an example. (I can create a PR for these)

[jmandel]

Thanks -- worth adding clarifications when you're ready. Will keep this open to track.

[christianpaquin]

Will do tomorrow.