the-commons-project / vci-directory Goto Github PK

Since some new issuers might get added to vci-issuers.json, and to keep the verifier application up to date with the participating issuers, is there an api we can call from our code to get the list of participating issuers?

This is just a nice-to-have --

It's reasonable for non-programmers at both issuers and verifiers to want to see the list of issuers in the VCI directory.

The only method to do so, is currently just the raw json file. A simple transform that presented a table UI of issuers would be a useful features.

The vci-issuers.json file has a typo in the iss value for Hartford Healthcare.

The substring "epicproxy" is not in the correct case based on observation of production samples.

The following entry:

    {
      "iss": "https://epicproxy.hhchealth.org/FHIR/api/epic/2021/Security/Open/EcKeys/32001/SHC",
      "name": "Hartford HealthCare",
      "website": "https://hartfordhealthcare.org/"
    },

should be changed to:

    {
      "iss": "https://EpicProxy.hhchealth.org/FHIR/api/epic/2021/Security/Open/EcKeys/32001/SHC",
      "name": "Hartford HealthCare",
      "website": "https://hartfordhealthcare.org/"
    },

The 2022-06-07 vci_snapshot has keys.crlVersion and crls.ctr as strings instead of numbers, which causes a parse failure on this record (and some directory parsers to fail to load the entire directory).

@@ -4742,7 +4742,7 @@
             "keys": [
                 {
                     "alg": "ES256",
-                    "crlVersion": 0,
+                    "crlVersion": "1",
                     "crv": "P-256",
                     "date": 1631112755371,
                     "kid": "8C-9TNgyGuOqc-3FXyNRq6m5U9S1wyhCS1TvpgjzkoU",
@@ -4752,7 +4752,15 @@
                     "y": "_qaENBMJz6iLf1qyYMx2_D6fXxbbNoHbLcfdPF9rUI0"
                 }
             ],
-            "lastRetrieved": "2022-05-03T04:43:55Z"
+            "crls": [
+                {
+                    "ctr": "1",
+                    "kid": "8C-9TNgyGuOqc-3FXyNRq6m5U9S1wyhCS1TvpgjzkoU",
+                    "method": "rid",
+                    "rids": []
+                }
+            ],
+            "lastRetrieved": "2022-06-07T04:41:42Z"
         },
         {
             "issuer": {

I find that the iss listed for UCSD:

https://epicproxy.et0502.epichosted.com/EPPARRPRD/api/epic/2021/Security/Open/EcKeys/32001/SHC

does not correspond to the iss found in my own personal vaccine record:

https://epicproxy-pub.et0502.epichosted.com/EPPARRPRD/api/epic/2021/Security/Open/EcKeys/32001/SHC

Note the presence of -pub in the live example.

Both return identical keys.

This begs the question of Smart Health Card Verifier is able to match the UCSD issuer and display the name, since the iss value in the downloaded QR will not match.

(I would look myself, but I believe Verifier is not open source?)

As well, I question how Verifier is able to verify the signature. It seems to me that an exhaustive search for kid across all known issuers would not be proper - it should be constrained to the claimed iss.

Assuming the data here is out of sync with data in the Verifier.

(I have built my own decoder/verifier, which is how I saw the iss value).

After #358 was merged, I realized that they are blocking the entire Cayman Islands (which is even a CommonTrust member). This is in direct violation of rule 7 in the VCI directory agreement. https://github.com/the-commons-project/vci-directory/blob/main/VCI%20Directory%20Agreement.pdf

@edwardjcruz @spncrd Could you please remove all the country blocks you have on Amazon CloudFront immediately? Both https://prd.pkey.dhdp.ontariohealth.ca/ and https://covid19.ontariohealth.ca/ being blocked.

403 ERROR
The request could not be satisfied.
The Amazon CloudFront distribution is configured to block access from your country. We can't connect to the server for this app or website at this time. There might be too much traffic or a configuration error. Try again later, or contact the app or website owner.
If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation.
Generated by cloudfront (CloudFront)
Request ID: ibRurI4C4vMndE9-SGIBXrQ-spVQ34C-HbS-zmFsxb_gk89AXBnEBg==

Several websites which are navigable, full and complete links are returning benign errors in the directory's checks, preventing them from being added.

@jdkizer9 I believe you mentioned that this was a problem with the checks, not the websites in a PR a while back. Feel free to clarify with the specifics here.

I have received multiple SHC QR codes from my users which were issued by CVS Health with "iss": "https://api.cvshealth.com/public" and "kid": "h0MD1WZcbX37spRMaNkLGt4uzyOqzgU8DtXVLw1YmpI". My app is failing to verify those SHCs because that key does not appear in vci_snapshot.json. It's worth noting that the official Commons Project Verifier app also rejects those SHCs, presumably for the same reason.

That key appears in https://api.cvshealth.com/public/jwks.json and in daily_log.json:

{
    "crv": "P-256",
    "x": "TXWmbGcaaK-VCByK8_ziepSXGcwjjRWOZx0vAPUcErQ",
    "y": "ID8SUpjFnwOV-H-eGLIv4xCZzw72nCGeXzLbSUXKDQg",
    "kty": "EC",
    "kid": "h0MD1WZcbX37spRMaNkLGt4uzyOqzgU8DtXVLw1YmpI"
 }

It's being excluded from vci_snapshot.json because it's missing the use and alg properties.

That is clearly invalid according to the section of the SHC standard incorporated by reference into the policy in the README:

SHALL have "kty": "EC", "use": "sig", and "alg": "ES256"

Does VCI have contact information for CVS Health that can be used to get them to add the missing properties to that key?

If not, would it be possible to relax that validation in the audit script that generates the snapshot?

I've set up my app so that when signature verification fails with the JWKS from the snapshot it fetches the JWKS from the issuer itself and validates the keys with a slightly relaxed validation: it accepts keys where use and alg are correctly set or where they're missing, but not keys with incorrect values for those parameters.

I have started to use the directory in a project, and I found the names for Issuers wanting, so I added my own long name and short name in my own table.

This sounded reasonable, so long as there were only 3 Issuers in the directory.

Boom! the directory exploded over night. (Yay!)

It seems now some Issuers have a different idea than perhaps was anticipated? The Cerner additions are fine-grain in some cases down to the individual practice.

It seems to me there are going to be a lot of names that can be confused for each other, and maybe even literally identical, even though they have the same NAME they are not the same THING. (Shades of Through the Looking Glass!)

In any case, it is quite common when listing entities of some sort of another, to have perhaps a long name, short name, maybe even medium length name. Depending on layout and available space, one or the other might be preferable, for example.

Not to mention actual legal name (which would be the case for any registered entity, Corporation or LLC, etc.)

I have naive about medical entities. I have to assume there is are some national/international/regional ID schemes.

I am familiar with secondary and higher education, for example. There are FSC codes, CEEB Codes, Liason Codes, ACT Codes, FAFSA Codes, NCES codes, etc. (Because there can never be enough codes!)

I'll bet medical entities have lots of codes to identify them!

Sorry for the can of worms! ;)

See also #21, which addresses uniqueness of the issuing authorities.

Some major providers like Walmart and CVS are not included in vci-issuers.json. Does this file include all official providers in the US?

Hello,

Is this the official location developers should use to determine if an issuer has been validated by the VCI?

If so, can we rely on vci-issuers.json remaining in the root directory with the same structure it currently has?

Thank you for the good work!

@BenjaminatEpic AltaHealth has been failing for the last 24 hours. Can you check with them to see what's going on? Thanks!

https://github.com/the-commons-project/vci-directory/runs/3984813290?check_suite_focus=true

https://epicproxy.et1123.epichosted.com/FHIRProxy/api/epic/2021/Security/Open/EcKeys/32001/SHC/.well-known/jwks.json

Hi there - we noticed that the Government of BC is no longer on the issuers.json.

Can you please add the public URL?

  "iss": "https://smarthealthcard.phsa.ca/v1/issuer/.well-known/jwks.json",
  "name": "Government of BC",
  "website": "https://www.healthgateway.gov.bc.ca/"

Related to #52.

Typically, clinical staff collect the specimen on which a COVID-19 test is run. In fact, most issuers don't have any workflows in which the specimen is collected by the patient, unsupervised. There are exceptional cases where self-swabs, for example, are unsupervised.

Some venues/locales/countries will not trust any SMART Health Cards containing a valid lab result without additional, out-of-doubt verification that the issuer doesn't support unsupervised patient collects.

Suggest two fixes, short-term and investigate a long-term:

1. Add field to metadata, something like this:

{
  "issuer_metadata": [
    {
      "canonical_iss": "https://simple.example.com",
      "website": "https://simple.example.com/portal",
      "help_line": "(555) 867-5309",
      "specimen_collection_supervision": "all-supervised",
      "issuer_type": [
        "state"
      ],
      "state": "CA",
      "country": "US"
    }
  ]
}

Where the specimen_collection_supervision has a valueset of: all-supervised, some-unsupervised, none-unsupervised, defined-in-card.

2. The obvious downside to this approach is inherent in some-unsupervised. Likely, an issuer who includes even a minimal number of unsupervised collection lab results will likely have all of its SHCs rejected -- ultimately hurting patients. In the longterm, we should investigate the feasibility of placing this information into the card itself. Including a defined-in-card option now, identifies a clear-cut path for verifiers and apps to expect may be coming in the future.

There is a trailing space in the iss entry for Boston Medical Center, which is invalid if strictly parsing that field as URLs.

I have filled out the attestation at https://www.commontrustnetwork.org/joinhealth for Kroger Pharmacy to be included in the directory. I have also sent a follow up message requesting an update on the status but have not heard any response.

Can I work with someone to get Kroger Pharmacy added to the VCI directory? We already have development and testing complete so we are ready to release our final code to production.

Tracking issue -- can resolve when tests at https://github.com/smart-on-fhir/health-cards-dev-tools are passing

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

Fields that would be helpful to add to the issuer schema:

• website: Link to a website for the issuer. Following this link should lead to a web page where individuals can interact with the issuer (e.g., to request help, or learn how to request a copy of their data as a SMART Health Card)
• securityContact: E-mail address to contact this issuer to report security issues
• canonicalIss: if the issuer has migrated to a new iss value, this field conveys the new (canonical) iss
• attestedToVciAgreement: boolean, or date indicating whether/when the issuer attested to the terms https://github.com/the-commons-project/vci-directory/blob/main/VCI%20Directory%20Agreement.pdf (this paves the way for listing issuers that have not yet attested, if we have other reasons to think they're reliable sources of SMART Health Cards)
• healthCardTypes: array of space-separated strings, conveying the sets of types an issuer is allowed to issue. For an issuer that does only COVID-19 immunizations the value would be
  • ["https://smarthealth.cards#health-card https://smarthealth.cards#covid19 https://smarthealth.cards#immunization"]

@BenjaminatEpic can you take a look at this? It's been failing for the last 12 hours

https://github.com/the-commons-project/vci-directory/runs/3934695295?check_suite_focus=true

Steps to reproduce

1. Go to https://vci.org/issuers/

Screenshots

Console:

Request URL:
https://vci.org/issuers/data/vci-issuers.json

Request URL:
https://vci.org/issuers/data/vci-issuers-metadata.json

I'm working with a team to build some software that can read SMART health cards and extract vaccination status. Our current solution uses the KID value to look up the issuer (from the list here), and then from there we can decrypt the data. One weird thing we've noticed is that multiple Issuers are using the same KID value.

For example University of Alabama Hospital and University of Missouri Health Care.
https://fhir-myrecord.cerner.com/r4/11e960ca-465e-403d-a8ac-dfa9be65dd83/.well-known/jwks.json
https://fhir-myrecord.cerner.com/r4/Vo3nb7XNL_9G2kQXBPPW3-r0QcpkrCy7/.well-known/jwks.json.

These two Cerner hospital centers are using the same KID/X/Y. Why are we listing them separately? How would we be able to tell them apart if we are looking them up by KID?

#9 brings up an interesting additional issue.

So, now there are two iss values that in fact represent the same real-world legal entity.

And not (as is my understanding) that they are different divisions of the entity - like clinics in different cities, or sub-organizations, but, literally, the exact same issuing authority.

Maybe a one-time DNS change early on.

Or not.

Any thought to assigning some kind of entity ID?

I will write up a separate Issue on alternative names.

The Government of New Brunswick has begun its smart health card program. Could the iss be added to the directory?

"iss": "https://www.gnb.ca/smarthealth",
"name": "Government of New Brunswick"

@BenjaminatEpic can you look into this?

Also, I'm having @edwardjcruz help with merging some of the new issuers in. The checks that we currently have in place prevent merging of pull requests unless all issuers are passing validation. My concern is that as the list grows, the amount of time that one or more existing issuers is down will also grow. Any thoughts on how we can address this?

cc: @isaacvetter

Starting yesterday, Hennepin Healthcare consistently started returning 401 status for JWKS requests (see here). @BenjaminatEpic Can you look into this?

https://hie.hcmed.org/FHIR/api/epic/2021/Security/Open/EcKeys/32001/SHC/.well-known/jwks.json

The vci-issuers.json file has a typo in the iss value for Riverside Medical Clinic.

The domain "sf1.rmcps.com" is not in the correct case based on observation of production samples.

The following entry:

    {
      "iss": "https://sf1.rmcps.com/FHIRProxy/api/epic/2021/Security/Open/EcKeys/32001/SHC",
      "name": "Riverside Medical Clinic",
      "website": "https://www.riversidemedicalclinic.com/"
    },

should be changed to:

   {
      "iss": "https://SF1.rmcps.com/FHIRProxy/api/epic/2021/Security/Open/EcKeys/32001/SHC",
      "name": "Riverside Medical Clinic",
      "website": "https://www.riversidemedicalclinic.com/"
    },

Could we localize the checks to the added endpoints to allow the PRs to pass when the errors are unrelated to the endpoint modified, or potentially recheck failures with a small grace period? The end effect currently is that some errors are issued, which by the time they are examined, are no longer apparent errors.

Example: UPMC's endpoint threw an error in the "add County of Santa Clara Health System" PR, but when examined showed no signs of an error. The "add Dartmouth-Hitchcock Health" endpoint, which was added very shortly after passed with no endpoints.

Issue #52 discussed adding more fields to the directory, one of which was:

• securityContact: E-mail address to contact this issuer to report security issues

I didn't see any discussion relating to this particular field before the issue was closed, so I'm resurrecting it here.

If this EU covid pass news is any indication, it is prudent to assume that a VCI issuer key will leak at some point, and there should be a rapid way to contact the issuer.

Thoughts?

Hi,

I am wondering how we go about being listed on the vci-issuers.json directory and become a verified issuer of SMART Health Cards.

Our public organisation (Sydney Local Health District) has been added to the General Membership on vci.org on the 28th September and has lodged to be added into the VCI issuers directory using the Google Docs Form

1. Is there another step that we need in order do to be added to the directory?
2. Will this be enough for us to be a verified issuer of SMART Health Cards?
3. Do we need to join the CommonTrust network?

@jdkizer9 @edwardjcruz Can you help me determine how we can quickly back out any changes from this PR to Epic organizations? This incorrectly overwrites the websites and naming conventions requested by Epic organizations. At a glance it looks like there is downstream system responsible for copying these changes to the metadata file we would need to consider - is that accurate?

Originally posted by @BenjaminatEpic in #754 (comment)

Hi @BenjaminatEpic,

We've gotten some reports of some SHCs issued from UNC Health that are not being recognized by the SMART Health Card Verifier. It looks like they are being issued with a different iss value (see attached screenshot) than what is provided here in the directory. Do you know what might be going on?

Thanks!

Cook County completed the VCI form but has not heard back concerning the adding to the issuers. When can we expect to be added to the issuer's list?

{
      "iss": ""https://s3.us-east-2.amazonaws.com/shc.vaccine.cookcountyil.gov"",
      "name": "Cook County Community Vaccination Program",
      "website": "https://vaccine.cookcountyil.gov"
}

The above is the entry I believe that needs to be made. I can also create a PR if it's easier

@BenjaminatEpic can you look into this? https://github.com/the-commons-project/vci-directory/runs/4069956794?check_suite_focus=true

Thanks!

Is there any way to know the dose number?

Some people don't have all doses included in the QRCode, for instance if the QRCode only includes the booster shot, how can I know it's a booster?
If somebody got a booster shot, it means they are fully-vaccinated. So, knowing the dose number is important to know if they are fully vaccinated.

When I make a get request to these urls below they are causing issues:

URL: https://tpc-shield.tpcllp.com/FHIR/api/epic/2021/Security/Open/EcKeys/32001/SHC/.well-known/jwks.json
Issue: Connection reset by peer - SSL_connect. Cant even open this link in a browser.

URL: https://www.gov.nl.ca/covid-19/life-during-covid-19/vaccination-record/prod/.well-known/jwks.json
Issue: When I try to parse the body of the response I get an error due to a malformed JSON String -> this is because the response body is not a valid JSON string.

URL: https://api.ccf.org/mu/api/epic/2021/Security/Open/EcKeys/32001/SHC/.well-known/jwks.json
Issue: I keep getting a Spike arrest violation even though I have looked at it 3-4 times within the last 2 days.

Can someone please help by looking into this further and contacting the issuers themselves to make some changes on their ends.

Hello!

Love the project.

Two days ago you added around 1,200 providers to the list.

Today you removed those providers.

What happened?

As early advocates of this system and consumers of this resource as developers we would like a bit more information when major changes happen beyond 'added XYZ' 'removed XYZ' when referring to changing 99% of the content of the core file consumed in this repo.

It would help put our mind at ease and allow us to advocate for and develop with this system as it grows.

I know this probably isn't the place to ask as it's potentially not due to a fault here, but I'm trying to get to Singapore and when I apply through their portal it is getting rejected for the QR code not being issued from the country I'm departing from. The error is: "Vaccination certificate is not issued in the VTL country/region you are departing from.". When I dug into the the response, I noticed that it returned:

provider" : { "healthcareInstitution" : { "name" : "EL PASO COUNTY PUBLIC HEALTH", "phone" : "", "address" : "", "country" : "", "id" : "" } }

The country field is blank so perhaps that is the issue?

With the recent changes I can now download the QR Code from the myColorado app and upload it into the CommonPass app - awesome! However, Colorado isn't appearing in the list of issuers on the VCI of CommonTrust website. Is Colorado not an approved issuer yet? Any thoughts on why this QR code isn't being verified despite being on the list?

We are getting below mention issue in one scenario.

One of the VerifiableCredentialTypes (vc.type) was not an allowed value, type found was: VerifiableCredential.
The supported types are:
https://smarthealth.cards#covid19,
https://smarthealth.cards#health-card,
https://smarthealth.cards#immunization,
https://smarthealth.cards#laboratory

Decoded Token has a non standard string highlighted below. Going by the specifications (https://spec.smarthealth.cards/vocabulary/) , this is not a valid type, so validation error thrown is correct. And we didn’t see such issue for any other Issuer.

type: [
"VerifiableCredential",
"https://smarthealth.cards#health-card",
"https://smarthealth.cards#immunization",
"https://smarthealth.cards#covid19"
]

As we are getting not standard string in type we are not able to decode from the Walmart issuer.

We have a SMART verifier app (https://vizcat.com) that we launched in July 2021 - and have been using your vci-directory as a way to verify SMART issuers.

In the past month we've been encountering issues with your vci-issuers-metadata.json file:

1. We had assumed that your vci-issuers-metadata.json and vci-issuers.json files were in sync, and was using an index to look up records in the other. This appears to no longer be the case (vci-issuers.json is 2 records longer than vci-issuers-metadata.json), so now we're using the iss field.

2. More importantly, we're now seeing malformed vci-issuers-metadata.json files (in the latest case a trailing comma in an array), which breaks JSON parsers. This makes it difficult to rely on your registry for validation.

Can you please add a test to check that your JSON is valid before checking this in?

Thanks!

The vci-issuers.json file has a typo in the iss value for Confluence Health.

The substring "Fhirproxy" is not in the correct case based on observation of production samples.

The following entry:

    {
      "iss": "https://epicproxy.et0764.epichosted.com/Fhirproxy/api/epic/2021/Security/Open/EcKeys/32001/SHC",
      "name": "Confluence Health",
      "website": "https://www.confluencehealth.org/"
    },

should be changed to:

    {
      "iss": "https://epicproxy.et0764.epichosted.com/FHIRProxy/api/epic/2021/Security/Open/EcKeys/32001/SHC",
      "name": "Confluence Health",
      "website": "https://www.confluencehealth.org/"
    },

Yet, BC and specifically the Provincial Health Services Authority public key well-known end point was never published to the vci-directory here. So, what updated the Verifier app? Is there another list?

The Health Cards Validation SDK was renamed to Health Cards Dev Tools, so point 4 of the VCI agreement should now read:

SHCs issued by Issuer have gone through a quality assurance process to ensure correctness in addition to the validation using the developer tools, available at https://github.com/smart-on-fhir/health-cards-dev-tools and as a portal at https://demo-portals.smarthealth.cards/VerifierPortal.html.

The vci-issuers.json file has a typo in the iss value for Dartmouth-Hitchcock Health.

The "p" in "proxy" is provided as lowercase, but should be uppercase (based on observation of production samples).

The following entry:

   {
      "iss": "https://edhwebportal.hitchcock.org/FHIRproxy/api/epic/2021/Security/Open/EcKeys/32001/SHC",
      "name": "Dartmouth-Hitchcock Health",
      "website": "https://www.dartmouth-hitchcock.org/"
    },

should be changed to:

   {
      "iss": "https://edhwebportal.hitchcock.org/FHIRProxy/api/epic/2021/Security/Open/EcKeys/32001/SHC",
      "name": "Dartmouth-Hitchcock Health",
      "website": "https://www.dartmouth-hitchcock.org/"
    },