Offline Presentation / Verification?

[jmandel]

If we wanted to support an offline verification, what is your vision to achieve this?

(For visibility, cross-linking to discussion at #6.)

There are a few aspects here. Offline could mean nobody is on the internet, but there may be local intranet access -- vs offline like the holder doesn't have a device at all, or doesn't have a device that can connect to the verifier's device. In all these scenarios, a verifier needs to keep a local cache of valid issuers for any of these schemes to work. Beyond this consideration... if the holder and verifier are on a local network together, DID-SIOP can work; if the holder has a device but no network access, you could theoretically convey a verifiable presentation through QR codes or BLE or NFC. Alternatively, if the holder doesn't have a device at all, you can't quite do Verifiable Presentation, but you can at least share a VC in its entirety (e.g., by scanning a QR code, or by tapping an NFC card). We haven't gone deep in specifying a standard for this, but this is worth doing! The size of the VCs (if you don't take particular steps to keep them small) isn't entirely conducive to QR codes, so this is an area that needs more attention.

[PSUPing]

Just doing a small test based on this example a minified payload is 1780 bytes. The max alphanumeric size on a QR Code is 4296. Minification isn't a particularly taxing process and should be a feature of almost any JSON/string processing library available. Based on minification allowing a bit of headroom, even if there's some extra extensions or a little bulkier payload, it should fit within a QR code. That feels like it might be a good offline option.

[jmandel]

There's some more exploration at https://github.com/microsoft-healthcare-madison/health-wallet-demo/blob/master/src/summaries/summarize-immunization-status.output -- it's important to consider the overhead of signatures + metadata. So even if we condense the actual FHIR content from 1780 bytes to a tiny "summary" of just 159 bytes, the final package is still ~500 bytes by the time signatures and headers are applied (and it's closer to 1kb if you're not careful to avoid repeated keys).

In theory QR codes can convey >2Kb of data but in practice as the size/detail of the codes gets large, scanning them with "regular" consumer devices (like, my current generation Android phone) gets challenging.

[PSUPing]

Ah, I see what you're getting at. I feel like trying for a QR Code if possible would likely make this pretty portable. It sounds like the key would be minimizing whatever data is included in there as much as possible. Is there any place the spec for something like that is being worked on? I feel like that might be outside of a traditional FHIR spec.

[AlexJonsson]

If just the holder was offline then what about an NFC tag? The 215 model here holds over 500 bytes: https://www.shopnfc.com/en/content/6-nfc-tags-specs

[jmandel]

NFC tags are fun, and are available in larger sizes too (including sizes large enough to hold our example credentials without minification tricks). Still, I don't think they're going to be a general-purpose offline solution, since they're (relative to paper!) hard to create/copy (e.g.. you can't just download and print).