search

the-commons-project / vci-directory

Holds membership information for SHC issuers that are part of the VCI (https://vci.org/) Directory.
54 stars 42 forks source link

VCI directory missing issuers allowed by Commons project verifier android app #30

Closed laurencebgood closed 11 months ago

laurencebgood commented 3 years ago

Apologies if this is the wrong place to ask this, but I haven't found anywhere that seems better. The Commons Project has released a verifier app, the android version is at https://play.google.com/store/apps/details?id=com.thecommonsproject.smarthealthcardverifier

I have been wondering what the relationship between the VCI directory and the app is, because I note the app verifies Walmart-issued SHCs successfully, but Walmart is not currently in this directory. I tried to find the source for the app to answer this myself, but it doesn't seem to be published anywhere.

I ask because I am interested in easier verification methods for small businesses, but doing so usefully will require a good directory of trusted SHC issuers, and I think that's the intention of this directory, but then the Commons Project seems to be using a separate directory for its own app, and this is very confusing.

Thanks in advance for any guidance or information you can provide, Laurence

Anvay commented 3 years ago

+1. Would like to know how small scale health providers join the Common Trust Network. We have issued shc and would not be ideal for getting partial verification.

Thanks A

jpp9 commented 3 years ago

thank you both for these comments- i hear you on the confusion. issuers request to be added to the VCI Directory by completing an attestation form and meeting the criteria described in the readme and agreement docs in the repo. the criteria don't account for the longer tail of issuers, but we hope represent a good starting point as we figure out what this directory should be and how it will be used. we do encourage everyone who fits to join, but haven't gotten 100% buy in (yet).

the SMART Health Card Verifier app does rely on the CommonTrust Network, which is based on the VCI Directory, but also proactively includes some legitimate orgs issuing proper SMART Health Cards who haven't yet joined VCI Directory for whatever reason. if you're issuing SMART Health Cards and want to be included in CommonTrust Network, you can provide info here: https://www.commontrustnetwork.org/join.

thanks!

laurencebgood commented 3 years ago

@jpp9 thanks for the explanation. If one is interested in being able to use the list the CommonTrust network is using to do verifications, are verifiers able to join? I see it seems targeted towards organizations, but I'm not sure if an open source project qualifies

laurencebgood commented 3 years ago

I notice that Walmart is now listed as a member of VCI per https://vci.org/about yet still is not listed in this directory.

Meanwhile, British Columbia provincial SHCs are being accepted by the common trust verifier but aren't even listed at https://www.commontrustnetwork.org/verifier-list

Meanwhile, tweets from the Commons project frequently refer to the VCI as the basis for trusting issuers. Eg https://twitter.com/commons_prjct/status/1440699255820226574?s=19 So this situation just gets more and more confusing. It's not clear if anyone is actually using the directory here, and it's not obvious to most what the difference is between this directory, the list for common trust, and the (secret?) list of acceptable issuer kids actually being used by the common trust verifier app. Clarity on this would be a big improvement as more issuers, both private and government, spin up.

I'm passionate enough about this that I'm interested in helping, but it's hard to understand if there's an opportunity for that in the organizational structure that exists.

awensaunders commented 3 years ago

Meanwhile, British Columbia provincial SHCs are being accepted by the common trust verifier but aren't even listed at https://www.commontrustnetwork.org/verifier-list

They're now on that list, but they aren't in the vci-issuers.json. Is commontrust proactively listing them without them having done their paperwork, or have they just not made it into the .json file yet for some reason?

modest commented 3 years ago

I understand why it seems pragmatic to extend a verifier app's trust list to include non-CommonTrust issuers, but this is getting a bit sketchy.

This is okay so far. Then:

So, which is it? Is The Commons Project's SMART Health Card Verifier app supposed to be the standard reference for validating whether a SMART Health Care is valid and comes from a trusted CommonTrust issuer? Or is it really just supposed to be an ~"Affinidi Verifier" app, a practical but non-standard tool for checking health cards?

bradhead commented 3 years ago

BC deliberately did not want our SHC to be recognized by the Verifier app to temper our verifiers from using this app over our published app that provides conclusions only and no means to view the data. So, now that someone violated the process and ignored the fact that BC is NOT in the vci json file and went ahead and added BC as an issuer trusted, undermined our approach to limit this app's utility. I would prefer that the app remove BC from its custom list. Thanks

laurencebgood commented 3 years ago

@bradhead this GitHub repo isn't listing BC, so I believe you are going to need to take that up with the people who make the verifier app in question. I haven't seen anything publicly stated about BC's position on this, though.

That said, are you affiliated with the BC government in some way? Because the BC verifier app does not accept out of province vaccination SHCs, and that sure was a fun experience for me. Mostly places would briefly get frustrated and then check it manually. One place said they were doing me a favor by letting me dine and that I would need a BC issued SHC next time. Hopefully someone corrected them before they started refusing vaccinated patrons from out of the province. I suspect a motivation for verifiers to use another app, such as the one you are complaining about, will be to validate SHCs from outside the province, so if you are from the BC government, perhaps you could escalate getting the BC verifier app to accept cards from other provinces, American states, and other issuers down the line? Otherwise, there's an incentive for verifiers to not use the official app.

modest commented 3 years ago

Here's another case study on the opposite end of the spectrum, @jpp9:

  1. A service named VaccineCheck (Pinpoint Us LLC) performs alchemy for money: For $24.95/year, they will turn anyone's paper US CDC card into a SMART Health Card.
  2. A week later, VaccineCheck will send the buyer a SMART Health Card with a mostly-compliant FHIR bundle, signed by issuer https://www.vaccinecheck.me/smartcard/wchd/.well-known/jwks.json
  3. When that SMART Health Card is scanned in The Commons Project's SMART Health Card Verifier app, the app reports that it is "CommonTrust Verified" (screenshot at bottom) by issuer "Wicomico County Health Department, MD"

But wait.

So, why does the SMART Health Card app report that the issuer is verified and part of CommonTrust? It calls the following private API to check:

https://shc.tcp.affinidi.com/api/v1/issuers/lookup?appUUID=null&issuer=https%3A//www.vaccinecheck.me/smartcard/wchd&status=VERIFIED

Affinidi's private API returns this to the app to confirm that the issuer is verified:

{
  "name": "Wicomico County Health Department, MD", 
  "logo_uri": "", 
  "iss": "https://www.vaccinecheck.me/smartcard/wchd", 
  "updated_at": 1634224756
}

So, let's recap.

(To be clear, I don't personally believe that there is actually any malicious intent here. I assume that VaccineCheck actually does some medical record research to confirm status. I assume that The Commons Project genuinely believes that this issuer has integrity. I assume that there is no improper business relationship. But I have no way to verify any of these things, and the whole point of this project is a transparent trust system.)

VaccineCheck-SHC-Verified

bradhead commented 3 years ago

@bradhead this GitHub repo isn't listing BC, so I believe you are going to need to take that up with the people who make the verifier app in question. I haven't seen anything publicly stated about BC's position on this, though.

That said, are you affiliated with the BC government in some way? Because the BC verifier app does not accept out of province vaccination SHCs, and that sure was a fun experience for me. Mostly places would briefly get frustrated and then check it manually. One place said they were doing me a favor by letting me dine and that I would need a BC issued SHC next time. Hopefully someone corrected them before they started refusing vaccinated patrons from out of the province. I suspect a motivation for verifiers to use another app, such as the one you are complaining about, will be to validate SHCs from outside the province, so if you are from the BC government, perhaps you could escalate getting the BC verifier app to accept cards from other provinces, American states, and other issuers down the line? Otherwise, there's an incentive for verifiers to not use the official app.

I am involved. I am contracted to BC MOH - I am the solution architect for the BC solution and Health Gateway and other projects and made the recommendations to adopt SHC for domestic use. We are in the middle of a verifier app release that adds the ability to support foreign issuers but our process requires policy to approve who we trust before we provision support for the out of province SHCs. We are in the middle of adding support for AB and YT with more to follow through configurations only - not relying on blind trust of the Commons Project list. Our BC Health Order is what is driving domestic verification - so BC is in control of who are verifiers and why. The official app is mandated by the province as part of the order. This isn't free choice, and is expected to be temporary order. We are technically ready to accept any valid SCH in our verifier app, but we don't until policy says to.

laurencebgood commented 3 years ago

@modest my guess is the Wicomico County Health Department contracted with vaccinecheck.me to issue SHCs and now is selling this service directly to consumers elsewhere, which...maybe is okay and maybe isn't?

Similarly, a number of states (such as North Dakota and Washington) are now using https://myirmobile.com/ to provide SHCs. I don't know what their issuer URL is, so I have no idea what eg the common trust verifier will do with it. But I don't see those states listed on either the common trust or VCI websites.

laurencebgood commented 3 years ago

@bradhead fair enough. This isn't the repo for the Common Trust list, though I'm sure some of the commons project people here could connect you with them somehow. But in a sense I guess this issue is a good place to bring this up, as I opened it in the first place to discuss the ongoing confusion having both a transparent directory like this and an app that doesn't use it could cause.

I will tell you as a practical matter, one restaurant in Vancouver did use an ipad app that looked like the BC verifier, but accepted my California SHC. So interesting things are already happening.

modest commented 3 years ago

This isn't the repo for the Common Trust list

Wow. You're right. VCI and CommonTrust are completely separate issuer trust registries, both operated by The Commons Project, with different industry partners. And CommonTrust's registry, unlike VCI, does not appear to be public.

The Commons Project might want to stop stamping Common on incompatible things. Between CommonPass, CommonHealth, CommonTrust, VCI, and CommonCheck, there isn't a lot in common other than attempting to solve the same problem in completely different ways.

jpp9 commented 3 years ago

hey all- thanks for the comments, we appreciate the feedback and concerns. as you can imagine the launch of SMART Health Cards has led to a dynamic and quickly changing ecosystem of issuers and verifiers. as we have scaled up, the VCI Directory and CommonTrust Network have taken on a small diff, due to a decision for CommonTrust Network to include information from the public domain, specifically ISSes for government issuers who are known to have compliant implementations and best practices. aside from that, the process to be included as a SMART Health Card issuer in CommonTrust Network is to register as an issuer for the VCI Directory.

within the next two weeks, we plan to have the diffs ironed such that the VCI Directory entries match the CommonTrust entries completely and remain that way going forward.

jpp9 commented 3 years ago

@modest, @laurencebgood's take is correct re Maryland counties, but if you wouldn't mind reaching out and sharing more details about that particular circumstance, i would be very interested. thanks!

laurencebgood commented 3 years ago

@jpp9 thanks for the thoughtful response. I understand how in general that decision by Common Trust makes sense. The normalization you describe will be a big positive, and I'm glad to hear it will be happening. It resolves the core of what I opened this issue for in the first place.

A couple of points this all raises, though:

1) the CommonTrust network has also included Walmart in their app for quite a while. I don't know if that's the only non-governmental addition they have made, but it's a pretty big one. I'm not necessarily saying this is a problem, but it does suggest that it would be preferable for Common Trust to be more explicit about their criteria for proactive inclusion, so verifiers can make informed choices. VCI has a very explicit inclusion criteria explained right here in this repo, so if that's going to remain the same, normalization between VCI and CommonTrust network will fully resolve this. (It's a bit odd that Walmart has been issuing SHCs for so long but still isn't present here in the VCI directory-will they be getting removed from the CommonTrust network if they don't want to agree to the VCI terms when normalization happens?).

2) Normalization would address @bradhead's concern if the VCI inclusion policy isn't changing thus causing the CommonTrust network's list to follow the same inclusion policy, which among other things requires an explicit opt-in, and so would result in BC's removal from CommonTrust network's list. Or is the policy going to change in some way, such as including obviously reasonable issuers like governments, and if so will it permit opt out? Is there a plan yet? (I have my own opinions on opt in, opt out, etc but that's a conversation better to have separately from this issue, maybe a conversation instead of an issue, if someone even wants to hear them)

3) the government of Singapore is going to start allowing the use of SHCs to prove vaccination status for their "vaccinated travel lane" program in less than 4 days. For the moment, they are allowing issuers from both VCI and CommonTrust https://safetravel.ica.gov.sg/vtl/faq#Q7 but it's not clear how they are going to check that in practice. Do they have access to CommonTrust's issuers list? Do they know that there may be VCI-listed issuers who aren't included in CommonTrust's verifier app? Not really clear. But does kind of put a finer point on it. When the lists are normalized, this concern goes away, but I wanted to call this out because it's the first time I've seen a government specify issuer lists for SHCs, and I am guessing this will become more common. (Also, @bradhead, if BC is delisted from all these verification lists, that would either require getting the gov of Singapore to specifically allow BC SHCs anyway, or it would exclude those vaccinated in BC from Singapore's VTL program)

As for what @modest is talking about, what's surprising to me is that vaccinecheck.me is selling cards it is issuing using the issuer it created for a county. @modest, did you pay for their service in order to get a sample? I am curious because their website suggests their verification process is fairly thorough, but I have no idea whether or not it actually is. (Whether or not purchased SHCs should be included in VCI, I don't know, if some entities are intentionally making it hard for people to get verifiable vaccine credentials, and they are doing significant work in order to verify the genuineness of a purchaser's vaccination despite this, then maybe that's okay-I have opinions on this, too, but again if someone wants to hear them, this issue isn't the place, and a conversation would probably be better than another issue)

As a practical matter, @jpp9, should the VCI agreement be amended to require providers that work on behalf of multiple "notional" issuers be required to use a separate iss URL for each one? The agreement incorporates documentation and best practices that kind of implies it, but isn't explicit about it. Both Cerner and epic have been doing exactly this. Interestingly, vaccinecheck is doing this as well-they issue for several Maryland counties, and use a different iss URL for each one. Given that, I'm surprised they are selling individuals an SHC that uses the same iss as they created for Wicomico county. Perhaps this is merely an oversight on their part? I'm hoping so.

(wow that's a lot of text, oof, sorry, thanks for reading it all!)

modest commented 3 years ago

within the next two weeks, we plan to have the diffs ironed such that the VCI Directory entries match the CommonTrust entries completely and remain that way going forward.

This is awesome. Thanks.

did you pay for their service in order to get a sample?

Yup I did. I followed up with @jpp9 about the details here and shared my sample. He'll follow up offline about the Wicomico County Health Department oddities. Just to reiterate, everything seems to indicate that VaccineCheck does their homework and properly verifies medical records. The red flag was the combination of an atypical issuer that wasn't listed in VCI and the mislabelling of that issuer as a government health department.

[…] require providers that work on behalf of multiple "notional" issuers be required to use a separate iss URL for each one?

This is definitely the right question. I don't know the full set of scenarios and threat models around stuff like revocation, so that's what would need to inform the design. In the SSL/X.509 analogy, VCI is the Root CA, all of the trusted issuers are Intermediate CAs, and the Intermediate CA's identity is shown during certificate verification (scanning SHRs).

Do you want to allow a scenario where an Intermediate CA (e.g. Epic, VaccineCheck, MyIR) is allowed to sign other "3rd-level" Intermediate CAs (Washington State, Arizona State, etc.) without approval from the Root CA? Or do you want to make them register as independent "2nd-level" Intermediate CAs with the Root CA? In the X.509 model, the "Path Length Constraint" assigned to each Root CA / Intermediate CA addresses the question of whether they are allowed to sign other CAs or just certificates.

All of that might get easier in a future model where SHR issuers use a true X.509 chain of trust model with the "x5c" extension on their JWKS, but gotta crawl before you can walk.

As an armchair commentator who has not followed this standardization process, participated in the discussions, or watched the meetings, I trust that these have all been debated ad nauseam by more qualified experts than myself, so this is where I get off the train :) Thanks

laurencebgood commented 3 years ago

@modest there's a simpler reason to not allow multiple notional issuers to use the iss URL: display name. There's no useful way to support multiple display names for a single iss URL in the SHC format. So unless you want the "intermediate" (to use your parlance) to be displayed, then that's a pretty straightforward reason to use unique iss URLs.

I also think that in the case of, for example, Epic, it would be weird if they were to use a shared iss URL, since it's the healthcare system that is their customer that does the validation and adds the vaccination events to their records, not Epic. You would find it odd if the displayed name for lots of websites was eg namecheap, and you might even end up accidentally complaining to namecheap.

But I suspect, as you say, this has already been discussed by those involved in the standardization process, and that there's just a need to spell it out a bit more clearly.

isaacvetter commented 3 years ago

And to clarify, y'all are talking about https://vaccinecheck.us, not vaccinecheck.me, right?

laurencebgood commented 3 years ago

@isaacvetter vaccinecheck.us is the website where humans interface with them, paths on the host www.vaccinecheck.me are what they use for iss URLs

Manouchehri commented 2 years ago

@modest Thanks for doing all the initial research. Have you done any further reverse engineering of the closed source app? Would be interesting to know the findings. =)