Consider QR Links for paper-based presentation

[jmandel]

There are a bunch of trade-offs here that are worth fleshing out. I'd like to get a set of proposals / assessments so we can make a decision.

This link-based approach has clear drawbacks (verifier needs to be online; data are hosted online, even if they can be encrypted and opaque to the hosting provider). The advantage are:

1. it avoids challenges of unmanageable QR code payload sizes. (Our current data profiles are creeping beyond the boundary of what can fit directly in a QR code, and specific instances can easily be too large, especially if they embed long-form DIDs in addition to signatures.)
2. it avoids the requirement for issuers to create a new/different kind of artifact for the paper-based use case; any already-issued Health Card can be represented with a Health Card Link QR code

[radamson]

Feel free to accept/reject as you see fit 🙂 .

[jmandel]

Thanks -- incorporated your proposed language tweaks.

[agropper]

Hoping to answer the challenge in #50.

The vaccine credential includes some verifiable in-person authenticator such as a driver's license number or, in some cases, a DID. If it's a DID, then a service endpoint would allow an authorized party to request and gain access the license number or other in-person verification appropriate to the LOA associated with the vaccination transaction.

A QR code would simply point to the place where the credential can be found. That could be the issuer or elsewhere. Wherever the credential is stored, it is also accompanied by a policy that can evaluate requests for access by a verifier. The policy decision point could be local or delegated to an authorization server. A patient could have separate QR codes corresponding to the different storage locations: Issuer or hosted. In cases of direct storage to a mobile device the policy decision point is moot.

At the time of credential issue (e.g. vaccination) the patient would also register a policy for access and/or tell the issuer where to store the credential online. If desired, a DID presented to the issuer could have this online location as a service endpoint. If the issuer is not online, the credential would be handed to the patient as paper and also sent to the online location at some later time as part of the required vaccine reporting process.

A verifier would be presented a QR code pointing to a policy decision point. It would be up to the verifier to provide a suitable request which might be scoped to just a type of credential such as a vaccination.

If the verifiable credential itself is stored on the patient's mobile device, then the policy decision issue is moot and the only problem is transfer of the verifiable credential from the mobile to the verifier.

The costs include hosting the verifiable credential, hosting a policy decision / authorization server, and printing or sending the QR code via email or SMS. Policy storage would likely double credential storage cost. The duty cycle of the authorization server is minimal and request / authorization bandwidth would, again, be order of the verifiable credential itself.

In summary, in the 'custodial wallet' approach, DIDs would be optional and online verifiable credential hosting cost would double. The benefit would be that the mobile device would be optional and this approach would generalize to all sorts of personal information in healthcare and other domains.

[jmandel]

Thanks @agropper! I think I see what you're driving at now with the concept of a custodial wallet, and I agree that in the longer term this kind of solution is very promising. It does indeed represent a "different point in the trade-off space."

I think the following challenges would prevent very-near-term adoption though:

1. Significant software development and "active" API/protocol hosting on the part of the custodial wallet (far beyond "just put encrypted VC files in a bucket, and give consumers a way to request removal if/when they don't want them there anymore"). And by definition in this use case the consumer doesn't have a phone other other device with which to take charge or make config decisions, so the issuer or some other party would need to mediate all the setup as well as the hosting/

2. Verifiers would need to interact with an arbitrary human-facing web UI exposed by the custodial wallet in order to complete a request (e.g., to click through, agree to terms, provide claims, and so forth). In many verification flows this will prevent things from proceeding (e.g., a verifier running a locked-down app on a mobile device that's basically a glorified QR scanner + HTTP client).

[agropper]

@jmandel wrote:

I think the following challenges would prevent very-near-term adoption though:

Significant software development and "active" API/protocol hosting on the part of the custodial wallet (far beyond "just put encrypted VC files in a bucket, and give consumers a way to request removal if/when they don't want them there anymore"). And by definition in this use case the consumer doesn't have a phone other other device with which to take charge or make config decisions, so the issuer or some other party would need to mediate all the setup as well as the hosting/

I would think the opposite... Whether it's in the cloud or on a mobile, most of the wallet software will be the same and some of it will be a lot simpler in the cloud, once containerized. The policy engine would be the one new component. It can be delivered as progressive web app to mobiles that are serving the guardian.

In this model, the fact that a mobile device is an option for the patients is a giant plus. In reality, guardianship (what we call it in the HIE of One Trustee project) likely applies to more than half of the population, because women still do most of this work :-).

Furthermore, the sophistication of the policy engine is minimal if all we care to control is vaccine credentials in some semi-standard and restricted feature space (revocation, etc...) Once we add other VCs like antigen and antibody test results, the policy engine will grow, but slowly. The added policy burden is further minimized by having a dozen or more branded bundles for guardians to choose from. I would pick the EFF bundle but might switch to the MIT bundle. All of the Massachusetts guardians will pick the CDC bundle, of course. This ability to bundle and brand consent is what we call Trustee Communities.

Verifiers would need to interact with an arbitrary human-facing web UI exposed by the custodial wallet in order to complete a request (e.g., to click through, agree to terms, provide claims, and so forth). In many verification flows this will prevent things from proceeding (e.g., a verifier running a locked-down app on a mobile device that's basically a glorified QR scanner + HTTP client).

That's not how we do it in HIE of One Trustee. We expect the verifiers to have a standard DID / VC wallet and present their credentials to the patient authorization server (as pointed to by the QR link). There are a limited number of verifiers and their root of trust can be pre-programmed into the branded policy bundles the way web browsers bundle root certificate authorities.

This is a major scalability benefit because having strong authentication for the verifiers (if they have strong DID wallets and credentials in the wallet) keeps them accountable for accessing the patient's custodial wallet (the Trustee). Every access is like a "break the glass" and every patient is a VIP :-). This will be simpler than developing governance for new federations. Major existing federations can simply issue VCs to the verifiers. Consider also that vaccine VCs are about as low a privacy risk as you can get. In many cases, the policy bundles might treat vaccine requests as public or link them to something trivial like a 3-year presence and on LinkedIn :-). It's just up to the guardians to choose a bundle.

[jmandel]

Closing in favor of embedding data