FHIR Chat · Connectathon 27 siemens QR scanner testing · smart/health-cards

Stream: smart/health-cards

Topic: Connectathon 27 siemens QR scanner testing

Reece Adamson (May 18 2021 at 13:28):

Hey @Vijayendra Prabhakar I'm trying to test out your verifier app, but am getting an unexpected "Signature is invalid" error.

It works with one of the QR codes we've generated, (e.g. https://connectathon.vci.org/patients/1)

Screen-Shot-2021-05-18-at-9.26.48-AM.png

but not with the first spec example

Screen-Shot-2021-05-18-at-9.20.01-AM.png

Any ideas on why the spec example QR is failing?

Christian Paquin (May 18 2021 at 13:32):

(deleted)

Reece Adamson (May 18 2021 at 13:32):

This is failing when I try to scan: https://smarthealth.cards/examples/example-00-g-qr-code-0.svg

Reece Adamson (May 18 2021 at 13:33):

Link to the verifier: https://smart-health-vault-siemens-healthineers.azurewebsites.net/verifier

Vijayendra Prabhakar (May 18 2021 at 13:38):

Reece Adamson said:

Hey Vijayendra Prabhakar I'm trying to test out your verifier app, but am getting an unexpected "Signature is invalid" error.

It works with one of the QR codes we've generated, (e.g. https://connectathon.vci.org/patients/1)

Screen-Shot-2021-05-18-at-9.26.48-AM.png

but not with the first spec example

Screen-Shot-2021-05-18-at-9.20.01-AM.png

Any ideas on why the spec example QR is failing?

Hey @Reece Adamson we support only PNGs for the moment and not SVGs. Also the issuer from the example is not a valid public issuer which is also one of the reasons why it is failing.

Reece Adamson (May 18 2021 at 13:40):

I was scanning using the camera on my mac so I don't think that the SVG should be a problem.

Maruthi M (May 18 2021 at 13:43):

Reece Adamson said:

I was scanning using the camera on my mac so I don't think that the SVG should be a problem.

Hi, What vijay was trying say is that, we support only png file selection in verfier.

Reece Adamson (May 18 2021 at 14:00):

Hey @Maruthi M I might be mis-understanding, but I am using the "Scan QR" option, not the "Choose Files Option".

Vijayendra Prabhakar (May 18 2021 at 14:05):

Reece Adamson said:

Hey Maruthi M I might be mis-understanding, but I am using the "Scan QR" option, not the "Choose Files Option".

Hey @Reece Adamson we understand what you are doing. The thing is the QR codes from the examples does not contain a valid issuer url. It starts with "https://smarthealth.cards/examples/issuer" which is not a accessible url from which we could get the public keys( JWKS)

Reece Adamson (May 18 2021 at 14:13):

Ah I see. The public keys do exist at https://smarthealth.cards/examples/issuer/.well-known/jwks.json, but there isn't a requirement that the base iss url resolves. @Josh Mandel not sure if you have any thoughts on this (i.e. does it matter if the iss resolves as long as {iss}/.well-known/jwks.json resolves)?

Christian Paquin (May 18 2021 at 14:16):

Vijayendra Prabhakar said:

Hey Reece Adamson we understand what you are doing. The thing is the QR codes from the examples does not contain a valid issuer url. It starts with "https://smarthealth.cards/examples/issuer" which is not a accessible url from which we could get the public keys( JWKS)

The spec examples are properly signed, and the public keys are published here (adding .well-known/jwks.json to the issuer URL.

Isaac Vetter (May 18 2021 at 14:24):

there isn't a requirement that the base iss url resolves

fyi - our iss doesn't resolve to anything as of right now, further, it's unclear what it should resolve to ... a web page explaining stuff?

Christian Paquin (May 18 2021 at 14:31):

Reece Adamson said:

Ah I see. The public keys do exist at https://smarthealth.cards/examples/issuer/.well-known/jwks.json, but there isn't a requirement that the base iss url resolves.

There is no requirement for the issuer URL to resolve.

Josh Mandel (May 18 2021 at 14:50):

there isn't a requirement that the base iss url resolves

It's true there's no requirement for iss itself to resolve, but we do kind of hope/expect that iss represents a consumer-facing recognizable brand (to the extent that the issuer has such a brand). It might be worth adding language to encourage this.

Josh Mandel (May 18 2021 at 14:52):

Like, for a pharmacy issuing health cards, the iss could be the pharmacy's public, widely recognized domain. This promotes transparency and trust in linking issuers, so for example even without any formal trust framework you might show a user a message like "This Health Card was issued by https://mypharmacy.example.org. Please proceed only if you recognize and trust this issuer." (This a lot harder if the iss is something like "https://proxy-gateway-01.hc.ec-us.cloud.example.org")

Vijayendra Prabhakar (May 18 2021 at 14:52):

Hey @Christian Paquin one query here, if iss is not resolved then how will the verifier access .well-known/jwks.json ?

Christian Paquin (May 18 2021 at 14:56):

Vijayendra Prabhakar said:

Hey Christian Paquin one query here, if iss is not resolved then how will the verifier access .well-known/jwks.json ?

The full url ending with .well-known/jwks.json must resolve to the issuer key set, but the base one doesn't need to. Just like the spec examples: https://smarthealth.cards/examples/issuer/ is 404 but https://smarthealth.cards/examples/issuer/.well-known/jwks.json provides the key set.

Vijayendra Prabhakar (May 18 2021 at 14:59):

Christian Paquin said:

Vijayendra Prabhakar said:

Hey Christian Paquin one query here, if iss is not resolved then how will the verifier access .well-known/jwks.json ?

The full url ending with .well-known/jwks.json must resolve to the issuer key set, but the base one doesn't need to. Just like the spec examples: https://smarthealth.cards/examples/issuer/ is 404 but https://smarthealth.cards/examples/issuer/.well-known/jwks.json provides the key set.

Oh ok thanks. Even we are verifying the full url ending with .well-known/jwks.json. Like the one in the example https://smarthealth.cards/examples/issuer/.well-known/jwks.json

Reece Adamson (May 18 2021 at 20:56):

Just tested the holder and successfully imported a health card as a QR code and then was able to subsequently scan the regenerated QR code and verify the signature. QR codes from the original issuer and on the app are the same

See Patient "Dewayne, Anderson" on the siemens holder. The patient can be found here at the issuer: https://connectathon.vci.org/patients/14

Reece Adamson (May 19 2021 at 14:47):

@Vijayendra Prabhakar I just tested out the multiple QR code scanning with Example 2 from the spec and was able to get it to successfully scan the 3 QR codes and verify the signature. Screen-Shot-2021-05-19-at-10.44.42-AM.png

Reece Adamson (May 19 2021 at 14:48):

It looks like it still can't verify the second example from the spec. Are these keys manually loaded at the moment (the second example is signed with a different key from the same JWKS)?

Christian Paquin (May 19 2021 at 14:55):

Reece Adamson said:

It looks like it still can't verify the second example from the spec. Are these keys manually loaded at the moment (the second example is signed with a different key from the same JWKS)?

What do you call 2nd example? Is is example 01? If so, yes, it is signed by a different key in the jwks (see key selection on line 18 of the generation spec, index number selects the key). Examples 00 and 02 are signed by the same key. The key for example 01 contains a x5c field.

Reece Adamson (May 19 2021 at 15:00):

@Christian Paquin Yes, I'm referring to example 01. (e.g. this QR code)

Reece Adamson (May 19 2021 at 15:01):

And what I meant by I can't verify it, I meant that I couldn't verify it using https://smart-health-vault-siemens-healthineers.azurewebsites.net/verifier (sorry if it wasn't clear)

Reece Adamson (May 19 2021 at 15:12):

Tested the multiple QRs with the validation-sdk it also looks like there are a few errors/warnings. One that stands out to me is that it looks like the kid for this JWK is not calculated/assigned correctly. I double checked with our Ruby library and which agrees with the validation-sdk as Dcgz_ncijpuFTy9FSiRX_L2tyHIu6KfmQu7ixrPMqzU being the correct thumbprint for the key in the JWK.

> node . --path ~/Downloads/smart-health-card-29715b32-d684-45a0-a665-bca0075072e9_0.png --path ~/Downloads/smart-health-card-29715b32-d684-45a0-a665-bca0075072e9_1.png --path ~/Downloads/smart-health-card-29715b32-d684-45a0-a665-bca0075072e9_2.png --type qr

SMART Health Card Validation SDK v1.0.0-1


QR images (3)
   │
   └─ QR numeric (3)
         │
         └─ JWS-compact
               │
                 ...
               ├─ Error
               │    · key[996ce4e1-59dc-4390-9666-ccc049a48279]: 'kid' does not match thumbprint in issuer key. expected: Dcgz_ncijpuFTy9FSiRX_L2tyHIu6KfmQu7ixrPMqzU, actual: 996ce4e1-59dc-4390-9666-ccc049a48279
               │    · key[996ce4e1-59dc-4390-9666-ccc049a48279]: 'alg' missing in issuer key
                 ...

Vijayendra Prabhakar (May 19 2021 at 16:19):

Reece Adamson said:

And what I meant by I can't verify it, I meant that I couldn't verify it using https://smart-health-vault-siemens-healthineers.azurewebsites.net/verifier (sorry if it wasn't clear)

@Reece Adamson if there are multiple public keys, we were verifying with the first key. This is now being handled to verify with multiple public keys in the key array.

Josh Mandel (May 19 2021 at 16:25):

actual: 996ce4e1-59dc-4390-9666-ccc049a48279
               │    · key[996ce4e1-59dc-4390-9666-ccc049a48279]: 'alg' missing in issuer key

Yeah, looks like a UUID slipped in here as a kid.

Vijayendra Prabhakar (May 19 2021 at 16:32):

Josh Mandel said:

actual: 996ce4e1-59dc-4390-9666-ccc049a48279
               │    · key[996ce4e1-59dc-4390-9666-ccc049a48279]: 'alg' missing in issuer key

Yeah, looks like a UUID slipped in here as a kid.

@Reece Adamson @Josh Mandel Please dont worry about this because this is one of the smart cards that we have imported to test our issuer API that we created as a POC.

Reece Adamson (May 19 2021 at 16:38):

Got it. Just so you are aware the kid is incorrect in the hosted JWK as well.

Last updated: Apr 12 2022 at 19:14 UTC