FAQs: Issuing and Presenting

[jmandel]

If I'm a patient and I just created a wallet with my self-issued DID, how do you envision that the identity of the patient is validated against the identity in the ID Card. Meaning, I can issue myself a DID and a wallet and claim I'm Josh Mandel?

When your health wallet generates a DID, there are no "claims" in it; it's just an identifier for a set of public keys. The issuer of a SMART Health Card (e.g., a COVID-19 vaccination card) is responsible for including identity claims in the VC -- https://github.com/microsoft-healthcare-madison/health-wallet-demo/blob/master/src/fixtures/vc-covid-immunization.json#L27-L48 has an example showing a name and phone number validated to IAL2.

If I understand correctly, a VC Issuer would capture my DID (possibly through scanning a QR Code in my wallet with my DID?). Once the Immunization VC is issued with my DID listed as the subject, what mechanism could be used to transfer the VC into the subject's wallet?

This is optional, but yes: there's a protocol for you to register your DID with an issuer, if you have one. This happens through the DID-SIOP workflow; the entry point here is often API-driven (FHIR "$HealthWallet.connect" operation to kick this off), though it could also start with issuer presenting a "begin SIOP" QR code that the holder scans.

Could we encode the entire credential into a series of QR Codes where the subject could import these into a wallet from a printed document?

Right now, you can import a VC into your wallet using any method you like. We define two "standard" methods ($HealthWallet.issueVc FHIR operation, and file download -- and of course, you can share a link to this file via SMS, or include the file itself as an encrypted email attachment or whatever; that's out of band, and you'll want to consider privacy aspects of where/how this is hosted). Beyond these two standard methods, any way that you have to get access to a VC is also fine.

When a subject is facing a verifier in-person, what I understand is that the verifier would scan the holder's DID via a QR code, which would request certain cards from the wallet. The holder would then consent, and the wallet would transmit the entire VCs (or a Verifiable Presentation) to the verifier. What transmission protocol is used to communicate?

Right now, the only presentation method we specify in a standard​ way is a DID-SIOP flow where the verifier presents a QR code, and the holder scans it, agrees to share, and uploads a Verifiable Presentation to the verifier's endpoint. That upload happens via https POST. While this is the only method we currently include in the spec, we don't prohibit other presentation methods from being used; indeed, there's lots​ of interest in developing on-device presentations to share a VC between an app like the Common Health app and 3rd party verifier apps, and I think this is a great direction to pursue.

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

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... 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 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.