Stream: smart/health-cards
Topic: Card Follow up
Grahame Grieve (Nov 23 2021 at 03:41):
Another discovered issue from the Australian connectathon around Lab testing: the lab test omits the DiagnosticReport. That's.. potentially problematic. Long term, we think it will be necessary to provide some kind of link in or next to the jwks.json that refers to a service where the issuer may provide some additional services to (a) renew cards and (b) get more information about the cards for authorised users
Josh Mandel (Nov 23 2021 at 14:50):
Worth writing up some use cases here -- very interesting area (and significant complexity, but if labs are willing to invest, we can support with specs).
Grahame Grieve (Nov 25 2021 at 00:13):
well, so far, I have two particular cases. One featured very prominently in this weeks podcast of The Dropout (about the fall of Elizabeth Holmes and Theranos, which is recommended listening for anyone working in health it and interested in the intersection between business, tech, and health): you never share lab results with a patient with out some context or guidance. mostly, this is left to the doctor who requested the test, but that's not how SHCs work, and so labs will want to - and may have regulatory obligations to - provide the patient with a path for advice / guidance / treatment pathways / etc. As featured in the podcast, in the absence of this, patients often don't seek advice / follow up at all, which is very bad or they decide that they should, but pursue it through the wrong channels (e.g. business sales support for the lab provider).
But this isn't unique to labs. Any provision of a healthcare fact raises the same conceptual issues (though not necessarily the same regulatory requirements). So any number of workflows beyond lab would benefit from a standard arrangement where the provider published, along with their key, the URL of a service to seek more information about the card. When invoking that service, the client submits the card, and... something happens.
Also, if the card is revoked (this is my second case), then the service can automatically offer a replacement (if they deem it is appropriate). or they can provide further advice as appropriate based on clinical context
For me this is also a sales thing: like branding your SHC, and turning the SHC into a branded channel. Feedback to me (general feedback about APIs, not SHCs) is that this is critical to getting CEO / business buy in to sending SHCs. (See also this card from the Australian connectathon yesterday):
So I think it would be really useful for the issuer of the card to have a URL with a name, declared at the <<issuer>> that a client would submit the card to, and then... magic would happen. Obviously I haven't worked through that but what follows smells suspiciously look a CDS Hooks kind of thing - one of a number of cards could be returned. The invocation context is kind of different, so CDS Hooks might need some context, but it's pretty much the same thing, right?
Salvador Mendoza (Nov 26 2021 at 06:52):
smart/health-cards
Vitor Pamplona (Nov 28 2021 at 22:14):
I think it would be nicer to define a framework to consume cards (e.g. Trust Registry for Verifiers) as opposed to let the issuer dictate where to go for more information. For instance, a Lab Result should be consumed by a Clinic/Hospital that would not only be liable to have the appropriate understanding of the payload but are also in tune with the latest scientific knowledge and public health policy of the region to provide individualized medical recommendations upon request. Having a fixed URL from the issuer might block use-cases that are outside the purview of that issuer, e.g. multi-jurisdiction use cases. Also, let's try to avoid mixing the lab results are are designed to go straight to consumers (COVID testing, pregnancy test, etc) from the lab results that clinicians request.
Grahame Grieve (Nov 29 2021 at 04:14):
Also, let's try to avoid mixing the lab results are are designed to go straight to consumers (COVID testing, pregnancy test, etc) from the lab results that clinicians request.
Sure. but a lab result that goes to the patient is likely to go to a clinic next. But sure, it's not the same thing.
Having a fixed URL from the issuer might block use-cases
how? It doesn't stop the client from doing whatever, it just makes it easy for the client to ask the issuer as well as anything else
Vitor Pamplona (Nov 29 2021 at 13:34):
It depends on who is the client. if the client is the wallet of the Patient, then it shouldn't be a problem, but if the client is any other verifier, then there is a massive privacy issue. Verifiers should not be allowed to communicate with issuers directly. That's the whole point of verifiable credentials. If they are allowed to ping the issuer then suddenly the payload doesn't even need to be signed anymore.
Josh Mandel (Nov 29 2021 at 14:58):
Agree with Vitor here about the privacy concern. There may be some capabilities that are helpful to advertise, but we definitely do not want to get in the game of enabling back channels between a verifier and issuer for the purpose of verification or with a consequence of trekking individual credential use.
Grahame Grieve (Nov 29 2021 at 18:54):
I really don't understand why we would forbid communication. I really don't understand why defining a channel to allow follow up suddenly becomes 'you must follow up' or why you suddenly don't need to verify the payload.
The point of a follow up channel is (a) the user doesn't need to use it and (b) the client only uses it if someone asks to and (c) privacy and security still need to be right on the channel
Josh Mandel (Nov 29 2021 at 22:06):
It establishes preconditions for verifiers and issuers to communicate without input from (or visibility to) the individuali.
Grahame Grieve (Nov 29 2021 at 22:29):
I do not see how it's better that they can't communicate at all.
Josh Mandel (Nov 29 2021 at 22:56):
Because then the individual has a better concept of what is being shared. Specifically: the things they decided to share.
I'm not saying there is no use case for advertising more endpoints and details in an issuer specific way, but this is something we want to be very cautious about.
Grahame Grieve (Nov 29 2021 at 22:58):
I don't really understand. If you don't standardise this, then institutions will do one of two things, since the use case is genuine:
- use something other than SHC that don't have any privacy properties at all
- make custom arrangements that happen behind the scenes
Better to describe how to do it properly and create conformance expectations about privacy.
Josh Mandel (Nov 29 2021 at 23:05):
At least one of the use cases you mentioned above was about an endpoint for providing information directly to patients. There is no problem with those kinds of patterns. It's something we are starting to explore in our directory metadata, and something that we could easily push into a standardized discovery file if it turns out to be useful.
The concerns are about discovery data that expect and allow for direct communication behind an individual's back.
Grahame Grieve (Nov 29 2021 at 23:09):
well, I don't want to expect communication behind an individuals back, but I don't see how you're going to stop allowing it. But if you describe it, you can also describe how to make it require an individuals authorisation, or at least, to ensure that they get a notification if it's used
Josh Mandel (Nov 29 2021 at 23:11):
These are all good points
Vitor Pamplona (Nov 30 2021 at 00:39):
@Grahame Grieve It would be nice to have a very specific/real use case for adding the link.
Grahame Grieve (Nov 30 2021 at 00:40):
you've dismissed the ones I provided above?
Vitor Pamplona (Nov 30 2021 at 00:44):
I meant a real use case with actual payload and links. The ones you provided are still very abstract.
Grahame Grieve (Nov 30 2021 at 01:20):
let's start with the case where the card that's been issued has an expiry date, or the key it was signed with has been revoked. Getting a new one is technically straight forward, but administratively difficult. And particularly in the case of key revocation, likely to be extremely embarrassing - I'm going about my business, some one scans my QR code, and then, bingo, it's not valid. Whoever scanned my code isn't going to think that there's a problem with the infrastructure; they're going to think that I'm lying to them. And most people will just be angry and confused because what happened is nothing to do with them, but their life is disrupted - potentially very severely
To extend this, if I was asked to break the SHC system, this is precisely where I'd try first: if I can entice the issuer into thinking that their key has been compromised, then they'll revoke the key, and suddenly 100k's of users will have invalid SHCs that they are rightly convinced are valid, and keep showing, because they don't have the time or knowledge to go through the adminstrative processes to get themselves a new card. And bingo, trust in the SHC system collapses, and I can present any card I made up and claim that it really is valid, it's not my fault
So I think that a good system to re-issue cards seamlessly is very necessary. And that's the first use case I had. There'd be a link "get a new card" when it's not valid, and upon proper authentication, the user would get a new card (delivered immediately or mailed or emailed or whatever).
so the issuer would have .well-known/links.json:
{
"re-issue" : {
"link" : "http://www.acme.com/shc/re-issue",
"name" : "Get a new card"
}
And when the card fails, and the holder of the card (assumes that the software understands from it's context that the card it has is on behalf of the user), clicks on/touches "Get a new card", then the software posts the card to http://www.acme.com/shc/re-issue, and the response is a CDS Hook card:
{
"cards" : [{
"summary" : "The key used to sign the card was revoked. The holder of the card can get a new card.",
"indicator" : "info",
"source" : {
"label" : "ACME Patient Services"
}
"links" : [{
"label" : "if you have a digital account and can log in, choose this to get a new card immediately",
"url" : "http://acme.com/patient/login",
"type" : "absolute"
},{
"label" : "Alternatively, get a new card mailed to your home",
"url" : "http://acme.com/patient/request-card-mailed",
"type" : "absolute"
}]
}]
}
Josh Mandel (Nov 30 2021 at 01:22):
We do have a "website" metadata item in the VCI directory for this purpose. It is intended to be a link that a consumer can follow to get information about how to obtain a health card from a given issuer. ( In general, we're looking at metadata in the directory as a kind of trial ground for things that we might want to standardize and push up to issuer based discovery endpoints.)
Grahame Grieve (Nov 30 2021 at 01:23):
so the key difference for me is to make this slicker: they don't have to go somewhere else to find that out, and the card is posted back to the issuer to transfer the context.
Josh Mandel (Nov 30 2021 at 01:23):
(I should also know that for issuers of supporting smart on fhir, it would typically be a wallet app responsible for checking and obtaining any available credentials on some regular basis, or when a credential issuer key is discovered to have been revoked. For other issuers, we certainly encourage them to proactively reach out to individual VC holders anytime. They are about to revoke a key or otherwise invalidate longstanding credentials. These don't take away from the utility of advertising in metadata, but they are worth knowing about)
Josh Mandel (Nov 30 2021 at 01:25):
Re: a protocol for reissuing credentials ("here's my old SHC; please return a new one that has been signed by a key that isn't revoked :wink:")... Certainly this could be defined, but it starts to overlap pretty quickly with the FHIR API for issuance we have today, and so far the issuers we have seen using non FHIR approaches don't offer an API at all, but rather want to interact with a consumer to have them verify control of a phone number or email address before issuing a card to them.
Grahame Grieve (Nov 30 2021 at 01:28):
it would typically be a wallet app responsible for checking and obtaining any available credentials on some regular basis
What wallet app? each issuer has their own so they know how to do it? THat's pretty much what I'm trying to talk about, making interop possible here
Josh Mandel (Nov 30 2021 at 01:29):
No, I'm talking about apps like Apple or Common health here, which can fetch credentials using the SMART on FHIR issuance API
Grahame Grieve (Nov 30 2021 at 01:30):
that's not the only way that those apps get the cards in the first place. in fact, it's unlikely to be how they get them at all - at least in Australia, where push to consumer exists widely, but the authentication infrastructure for smart on fhir exists very rarely
Josh Mandel (Nov 30 2021 at 01:30):
(Although to your point, issuer-specific apps like MyChart of course can help with these details as well.)
Grahame Grieve (Nov 30 2021 at 01:33):
it doesn't make any difference to me whether the link is at the issuer URL, or in the vci directory, though in general I think it should be secondary in the vci directory
Josh Mandel (Nov 30 2021 at 01:34):
There's a lot more that you would want in a protocol like this. If you wanted to expose an API where anyone could trade in a copy of a card that was signed with a bad key and obtain a new card signed with a good key... You need some binding to a verifiable identity claim or a decentralized identifier that allows verifiable presentations, etc. It's worth checking out the VC API work happening in W3C https://github.com/w3c-ccg/vc-api for a sense of what is involved here
Grahame Grieve (Nov 30 2021 at 01:36):
ah what? I don't want any of those things. I'm assuming that they reissue based on the original issuing protocol - I don't think that needs any of that complexity. Passing the card just passes along the administrative context to kick the process off in the right context
Josh Mandel (Nov 30 2021 at 01:37):
So the protocol is: anyone in the world can post a SMART Health Card to the issuer's "get the rightful holder of this card a new copy" endpoint, and then the issuer wakes up and reaches out proactively to the individual holder through some channel that the issuer chooses?
Grahame Grieve (Nov 30 2021 at 01:38):
or redirects them to a login if it thinks that the individual holder can/might login
Grahame Grieve (Nov 30 2021 at 01:38):
but yes
Josh Mandel (Nov 30 2021 at 01:42):
Okay. I mean that's certainly workable. We just haven't seen a convergence of 1) issuers that want to support HTTP APIs, 2) issuers that don't want to do SMART on FHIR -- but if this is the case for Australia, it could be a good place to start.
I take your point that if supporting some very narrow APIs was dead simple, the group in (1) could theoretically be much bigger
Grahame Grieve (Nov 30 2021 at 01:43):
right. there's often no interest in something that doesn't exist
Grahame Grieve (Nov 30 2021 at 01:43):
but you're right that there's an underlying assumption of non smart on fhir distribution channels in my thinking
Vitor Pamplona (Nov 30 2021 at 02:44):
Thanks for the example. I think that information could easily be part of the Keys file that the issuer exposes. We can even break down by card type if needed. It doesn't need to be signed in the QR itself.
Grahame Grieve (Nov 30 2021 at 03:28):
no I don't think this should be in the card - I'm not proposing that
John Moehrke (Nov 30 2021 at 13:07):
@Grahame Grieve are you specifically looking for an API automation for re-issuing? Meaning the server at the API can use more robust algorithms to prove that the old card "was" issued properly, so it issues a new card? If this is just an api to create a "fresh" card given an old card; then there is not much downside... but the new card should not invalidate the old, the old should stand on its own. Meaning this should not be an method for a malicious actor to scan a targets card, send that card to the API, so that the target is now holding a revoked card. The re-fresh API should not affect the old card status; while it is fully based on the old card authenticity.
John Moehrke (Nov 30 2021 at 13:08):
so constant re-freshing should have no downside except as a DOS against that API... which it can/should/shall protect itself.
Vitor Pamplona (Nov 30 2021 at 13:29):
Also, let's make sure the information to perform a login in this API is not included in the card. A simple form with Name + DOB + ID should not be acceptable.
John Moehrke (Nov 30 2021 at 13:37):
the old card should be sufficient. no need to have the request extract these into api parameters.. right? The card already has them, and has a signature... even if the issuing certificate has expired or been revoked, the issuing service can look at the signature "in context" of the issuing time, and understanding why/when a revocation happened. Thus this old card was validly issued at a time when the signing cert was not in question, so a new card can be issued based solely on the old card.
Vitor Pamplona (Nov 30 2021 at 13:39):
No, otherwise Verifier databases will keep refreshing their cards at will. We don't want verifiers to be able to refresh a card without the holder's permission.
John Moehrke (Nov 30 2021 at 13:40):
I think the "we" in your sentence is fundimentally different than the use-case Grahame is presenting. but I might be wrong.
Vitor Pamplona (Nov 30 2021 at 13:41):
If that is what they want, then they don't need any signature. Just ping the other server and download all the info. There's no need for smart health cards.
Vitor Pamplona (Nov 30 2021 at 13:46):
The idea of expiring cards exist exactly to block verifiers from using the information beyond what they need it for. A COVID pass is only valid for 2 days not because the person is not protected after the two days, but because holders don't want verifiers to use that information outside that time window.
John Moehrke (Nov 30 2021 at 13:57):
that sounds like a reasonable policy that a server that needs to enforce can enforce. but that policy does not need to prevent the API from existing to support policies and use-cases such as Grahame (I think) has presented.
Vitor Pamplona (Nov 30 2021 at 14:03):
The problem is that broadening the support for these use cases defeats the purpose of the entire spec. There are a lot of options that allow verifiers to talk directly to issuers. Grahame can choose any of them. What makes a Verifiable Credential different is exactly the fact that the communication between an issuer and a verifier is MEDIATED by the holder at all times. If you don't want that, you don't need a verifiable credential. There are simpler, faster, better ways to develop that communication outside the Verifiable Credential ecosystem.
If you want credit cards to behave like cash, just use cash. It's a better solution :)
John Moehrke (Nov 30 2021 at 14:22):
when a credit card is revoked, that card issuer sends me a new card.... Thus, this is exactly what I read is what Grahame is looking for.
John Moehrke (Nov 30 2021 at 14:23):
His use-cases, in my read, is focused on support of Patients when an issuing certificate is revoked due to a later exposure. Supporting re-issuing a fresh card.
Josh Mandel (Nov 30 2021 at 14:48):
The thing is, when your credit card is revoked the issuer knows this fact and just sends you new card. They don't wait for a third party app to come by and make an API call requesting it :smile: So Grahame's use case here is a bit different. It's about cases where the issuer isn't willing to or can't just proactively send out a new card and instead is waiting for a third party app to trigger this step (I'm not sure why? Maybe because the issuers don't know an email or SMS or physical street address where they can send a new SHC? Or to account for cases where proactive sending was attempted but didn't really work and the user still needs help?).
John Moehrke (Nov 30 2021 at 14:58):
proactive sending might be a useful "best current practice" that could be informatively said.... not clear to me that Grahame's use-case would not like that solution.
Vitor Pamplona (Nov 30 2021 at 15:26):
The UX problem here (the user needs help renewing their cards) is real and very common. There are many ways to solve it: One could allow the verifier to get a new card for the holder, a very convenient UX for the holder but one that breaks the triangle of trust model; or we can just extend the wallet/issuer requirements to include an API for the holder to do that by him/herself. The more we empower the holder, the better the system gets.
Josh Mandel (Nov 30 2021 at 15:47):
Agree with this principle @Vitor Pamplona ; to Grahame's point, some kinds of API endpoints that an issuer advertises fall into this category (individual holder requesting reissuance does) and others don't (e.g., "is card X [still] valid?). The mechanism of discovery is the same.
Josh Mandel (Nov 30 2021 at 15:49):
To take this discussion forward, I think it would make sense to add an "extensions" or "rfcs" folder to our spec repository outside of the core spec content, akin to the FAQs we have today at https://github.com/smart-on-fhir/health-cards/tree/main/FAQ... where we try to outline a spec for this kind of discovery and see what serve adoption we can get. I don't want to start cramming new functionality into the specification unless someone in the real world wants to support it, but I understand there's a catch 22 here and I think there may be some common ground. Anybody interested in drafting such a thing? Otherwise I can take a crack.
Vitor Pamplona (Nov 30 2021 at 15:53):
I wonder if there is a way to generalize this spec in the same way the SHC spec just says use a FHIR Bundle as model. I am not sure it needs to be an SHC document.
John Moehrke (Nov 30 2021 at 15:55):
it does seem adjacent, or "trial"... yup. I just don't agree that having this specific kind of API is contrary to SHC. Grahame has indicated the use-case is about a proper use of SHC, but where the issuing cert is revoked. That is why it is within SHC. I would agree that this is not just an API for checking status, but why would a "check status" use-case of this same API be contrary to SHC? Yes, a dominant design requirement of SHC is off-line-proofing, which an online "check status" is clearly contrary to; but the format of the card issued can be SHC and the validation from the point of the API returning can be the same SHC processing.... more important is that a service can explicitly reject "check status" if that instance of the service has a policy forbidding that use-case, while that service instance allows for "re-issue card that was invalidated by a issuing cert revocation".
Vitor Pamplona (Nov 30 2021 at 15:55):
FYI, the WHO DDCC spec does have a "ping issuer to check status and re-download the cert" feature which will be developed in the upcoming months. Maybe this whole thing evolves into something every Verifiable Credential standard can use.
Josh Mandel (Nov 30 2021 at 15:55):
If that's the goal, I would strongly encourage participation in https://github.com/w3c-ccg/vc-api
Grahame Grieve (Nov 30 2021 at 19:36):
@John Moehrke it is not my interest to have the card automatically re-issued. Just to make a smooth UX for re-issue possible in an interoperable way.
And yes, I'm assuming that an issuer that revokes a key that invalidates several million cards will not proactively reissue all of them because of cost and various other factors (including not knowing which ones are worth re-issuing)
John Moehrke (Nov 30 2021 at 21:39):
I was not the one proposing automatic re-issuing. I was not indicating WHY the api would be triggered. Just that once called, with an old cert, the service could validate, follow local policy, and return a new.
John Moehrke (Nov 30 2021 at 21:40):
and those local polices would be designed to protect the api from abuse, and misuse.
Josh Mandel (Dec 01 2021 at 00:18):
Just that once called, with an old cert, the service could validate, follow local policy, and return a new.
This is slightlydiffeent from the service Grahame was describing, where the API would be "once called, begin a re-issuance flow in an issuer-determined fashion".
Josh Mandel (Dec 01 2021 at 00:20):
I've done a write-up of what I'm hearing as the use case, to try to move this ahead...
https://github.com/smart-on-fhir/health-cards/blob/main/rfcs/001-reissuance-endpoint.md
Feedback welcome here or in https://github.com/smart-on-fhir/health-cards/discussions
Vitor Pamplona (Dec 01 2021 at 02:18):
Hum.. why is the name of the file so big? smart-health-cards-configuration? :)
Josh Mandel (Dec 01 2021 at 02:18):
I know :-)
Vitor Pamplona (Dec 01 2021 at 02:20):
shc-config.json?
Josh Mandel (Dec 01 2021 at 02:22):
(General structure and leaving off the .json suffix is following the convention of openid-configuration and smart-configuration established in those published specs.)
Vitor Pamplona (Dec 01 2021 at 02:24):
Maybe clarify that the URL is a UI URL to be open in a WebView or directly in a browser. Some people might think this is an API call.
Vitor Pamplona (Dec 01 2021 at 02:29):
I am not sure if I like sending the Credential in the URL. There is some potential to steal the information from the Credential in transit, even when using a HTTPS call.
Josh Mandel (Dec 01 2021 at 02:30):
That's true for any submission protocol (in URL or otherwise), right? I do call this out in drawbacks... and I agree it's a concern
Josh Mandel (Dec 01 2021 at 02:31):
But yes, if we want to introduce an API step we could have a protocol where you POST an SHC (or an empty context) and get back an opaque URL to navigate the user to. That avoids having a SHC touch the browser at least.
Vitor Pamplona (Dec 01 2021 at 02:32):
Besides the man-in-the-middle HTTPS attacks and potential downgrade to HTTP, GET parameters are part of the url, and appear in the server logs, your browser history, website analytics, the page printing, an antivirus analysis of the page, etc.
Vitor Pamplona (Dec 01 2021 at 02:32):
Maybe POST is a must.
Josh Mandel (Dec 01 2021 at 02:33):
# avoids query parameters and isn't submitted to the server fwiw
Vitor Pamplona (Dec 01 2021 at 02:35):
true
Vitor Pamplona (Dec 01 2021 at 02:35):
What if we encrypt the card with the public key of the issuer in such a way that only the private key can decrypt it?
Josh Mandel (Dec 01 2021 at 02:38):
Current public keys in SHC protocol are only guaranteed to work for signing, not encryption. We could introduce more keys but I don't think it's worthwhile here.
I'll think on this and may update the proposal to "POST to issuance url and get back a 303 with an opaque location header" -- so apps can make this call, extract the location header, and open a browser context to that URL. Severs can populate this in a safe way (e.g., with opaque identifies).
Vitor Pamplona (Dec 01 2021 at 02:41):
Or just don't submit the card.
Vitor Pamplona (Dec 01 2021 at 02:41):
Let the user login with other info to re-download it.
Vitor Pamplona (Dec 01 2021 at 02:41):
Most sites already implement some form of login without the card anyway..
Grahame Grieve (Dec 01 2021 at 02:43):
That works fine if there's a login. It doesn't work if there isn't. What's important to me is the UX of passing the card to the issuer to establish the context of which card needs re-issuing, instead of trying to figure out how to describe that in human language
Vitor Pamplona (Dec 01 2021 at 02:44):
There should always be a login
Vitor Pamplona (Dec 01 2021 at 02:44):
Otherwise the server will be spammed by all verifiers.
Vitor Pamplona (Dec 01 2021 at 02:45):
Maybe a SHA-256 of the card?
Vitor Pamplona (Dec 01 2021 at 02:45):
If the Issuer stores the card, a SHA-256 would be sufficient to look up the record.
Grahame Grieve (Dec 01 2021 at 03:01):
that would work for me
Grahame Grieve (Dec 01 2021 at 03:01):
there is other solutions to spamming than login
Josh Mandel (Dec 01 2021 at 03:15):
I've updated the proposal to define a submission step via POST before the interaction, to avoid the concerns about whether cards need to be submitted into a browser context. Will revert if folks don't prefer :-)
Josh Mandel (Dec 01 2021 at 03:15):
When we land the revocation protocol, we could submit an rid here instead of an SHC :-)
Grahame Grieve (Dec 01 2021 at 06:14):
we could, and I considered proposing that, but rids do not always identify the card, only an revocation scope
John Moehrke (Dec 01 2021 at 12:31):
Vitor Pamplona said:
What if we encrypt the card with the public key of the issuer in such a way that only the private key can decrypt it?
No. The use-case is where the issuer cert has been revoked.. so using it as the encryption key is clearly a NO.
Grahame Grieve (Dec 01 2021 at 12:32):
I think @Vitor Pamplona meant the current key
John Moehrke (Dec 01 2021 at 12:33):
do we expect issuers to archive everything they have ever issued? Or do we think the design of SHC is such that they don't need to archive every card issued? I would hope the second. Not saying that they must not archive, but if the design requires archive of all issued cards then we move into needing to define functional and non-functional requirements of that archive.
John Moehrke (Dec 01 2021 at 12:35):
Grahame Grieve said:
I think Vitor Pamplona meant the current key
how do you get the 'current key'?
Note that https (TLS) will already be negotiating the current TLS keys, and using that to support encryption of the channel. Thus you get this for free. (recognizing the MITM risk if one does not do TLS (BCP195))
Grahame Grieve (Dec 01 2021 at 12:35):
current key is {issuer}/.well-known/jwks.json. If you can't get that, you can't communicate with them.
John Moehrke (Dec 01 2021 at 12:37):
okay, but you used TLS to get that... so... Why not just use TLS for things that TLS is useful for? Why invent a message security layer that is special for us? NO
Vitor Pamplona (Dec 01 2021 at 13:07):
@John Moehrke mostly to avoid URL tracking issues (and thus payload decoding) that TLS doesn't solve.
John Moehrke (Dec 01 2021 at 13:11):
so you are worried about a SHC issuer that has poor audit log management? This is such a ridiculous argument. Stop the fallacy promotion.
Vitor Pamplona (Dec 01 2021 at 13:12):
We have actually seen it. It's not a fallacy. Issuers of COVID credentials have been pretty bad.
Vitor Pamplona (Dec 01 2021 at 13:13):
But I am more concerned with those issues on the client level.
John Moehrke (Dec 01 2021 at 13:21):
so you would trust the client to be currently holding the card, and able to properly encrypt it... but you don't trust what? We are a standards organization, we should use the standards that the specialists (security) in that domain have produced. If we don't use others proven standards, why do we think we have any creditability to produce standards that others should trust of us?
The argument that "we have actually seen it [poor implementations]"... is not as helpful to your point as you might think it is.
Vitor Pamplona (Dec 01 2021 at 13:26):
I don't trust anything. Not the client, not the server.
Vitor Pamplona (Dec 01 2021 at 13:27):
If you think TLS solves everything, you clearly have never talked to a security specialist. There's a reason most hospitals use their own VPN and not rely on TLS.
Josh Mandel (Dec 01 2021 at 13:55):
Appreciate the discussion here; would love feedback on the updated proposal at https://github.com/smart-on-fhir/health-cards/blob/main/rfcs/001-reissuance-endpoint.md which:
- Provides zero or more complete SHCs as context
- Avoids putting SHCs into URLs so they're not part of browser history
- Avoids introducing any new keys or encryption schemes
Vitor Pamplona (Dec 01 2021 at 14:02):
@Josh Mandel Looking good!
Vitor Pamplona (Dec 01 2021 at 14:03):
On Should we also stipulate that (for context-less requests) a user can navigate directy to the issuance URL in a browser context? I think the answer is an easy yes.
John Moehrke (Dec 01 2021 at 14:07):
Given that the result will always be a Reject or Redirect to a browser interactive session.... what is the benefit of not just starting with a browser interactive session? I am not saying I have totally lost track of the value-add; but am unclear on specifically what that value is.
Vitor Pamplona (Dec 01 2021 at 14:11):
When the wallet submits the credential, it saves 1 screen of the interactive process (choosing which credential to renew)
John Moehrke (Dec 01 2021 at 14:13):
but it is optional.. and the wording around that card is "as a hint". -- Reiterate, just feeling like the value vs going direct to interactive session seems small.
Vitor Pamplona (Dec 01 2021 at 14:14):
The value is big if the issuer outputs several types of credentials
Vitor Pamplona (Dec 01 2021 at 14:14):
If the issuer only issues one type, then there is no need to know which credential the holder is trying to renew.
John Moehrke (Dec 01 2021 at 14:16):
good improvement.
Vitor Pamplona (Dec 01 2021 at 14:17):
Should the spec say something like: Issuers should not re-pack the incoming payload and simply re-sign it. Invalid cards are invalid for a reason (leaked keys, operator errors, etc) and thus incoming credential payloads are all untrusted.
John Moehrke (Dec 01 2021 at 14:17):
it likely helps the automation that might be initiated by a VC app. Allowing the VC app to do what it can to kickstart the workflow. right?
John Moehrke (Dec 01 2021 at 14:18):
wouldn't the server be well positioned to figure that out better than the client?
Josh Mandel (Dec 01 2021 at 14:18):
I am not saying I have totally lost track of the value-add; but am unclear on specifically what that value is.
The value is providing a specific workflow without having to submit the credential in a browser context; the credential can be shared between a mobile app and the issuer, and then the user can be safely transferred to a browser context where they don't have to supply any sensitive information in the URL
John Moehrke (Dec 01 2021 at 14:19):
I agree. that is not clear in the text.
Vitor Pamplona (Dec 01 2021 at 14:19):
Not adding the credential to the URL also makes it impossible for people to share the link on their WhatsApp groups :sweat_smile:
John Moehrke (Dec 01 2021 at 14:19):
I fully get why it should be optional.
Josh Mandel (Dec 01 2021 at 14:20):
I agree. that is not clear in the text.
That's fair, I call it out in the considerations or trade-off section but we can elevate it to the spec language.
Should the spec say something like: Issuers should not re-pack the incoming payload and simply re-sign it. Invalid cards are invalid for a reason (leaked keys, operator errors, etc) and thus incoming credential payloads are all untrusted.
Sure, some note to this effect would be good.
John Moehrke (Dec 01 2021 at 14:20):
failure-mode -- service determines the card is good?
Josh Mandel (Dec 01 2021 at 14:21):
If the service thinks the card is still good, it can nevertheless honor a reissance request. I think the server should treat this as a request to issue new card (s)
Josh Mandel (Dec 01 2021 at 14:21):
But keep in mind here, the fact that this is an interactive session is our friend. The service can say to the user "the card you supplied initially is perfectly valid, do you still want to proceed?"
John Moehrke (Dec 01 2021 at 14:22):
that is where I was back a day or so, but I was shouted down.
Josh Mandel (Dec 01 2021 at 14:22):
Then eventually we have caught up to you :smile:
Josh Mandel (Dec 01 2021 at 14:23):
(seriously though, it can often be difficult to understand somebody's idea until you rediscover the reasoning for it yourself...)
John Moehrke (Dec 01 2021 at 14:23):
more likely my spinning brain might have caught up to the context of design you all share
John Moehrke (Dec 01 2021 at 14:23):
no problem
Vitor Pamplona (Dec 01 2021 at 14:27):
@Josh Mandel not to overcomplicate things, but this configuration file could be a credential on itself, signed by the public key on the same directory. Why? It makes sure that the config file was not changed without authorization (say, man in the middle attack). In order to hack the system, the attacker needs to also replace the key file, which will activate alarms at the Trust Registry level.
Josh Mandel (Dec 01 2021 at 14:29):
We could do that but in all of the scenarios I know where an attacker can replace this configuration file, the attacker could also replace the sibling file called jwks.json (which is not signed) and introduce a new public key, so I'm not sure what this accomplishes.
Vitor Pamplona (Dec 01 2021 at 14:29):
correct, but the key file is being tracked by the Trust Registry verfiriers use.
Vitor Pamplona (Dec 01 2021 at 14:30):
If the key changes, it triggers several procedures to re-trust the issuer
Vitor Pamplona (Dec 01 2021 at 14:30):
Trust registries could also watch the config file for changes, but it's easier for them if it's all bound to the same anchor point (the key file)
Josh Mandel (Dec 01 2021 at 14:31):
If we introduce a new configuration file, the registry can also track that. Anyway, I think this is an interesting idea for an enhancement, but it would be great to get some more feedback on the basics here.
Vitor Pamplona (Dec 01 2021 at 14:31):
Agree
Vitor Pamplona (Dec 01 2021 at 14:33):
It's just a common request I make to everyone :) (everything should be a credential)
Josh Mandel (Dec 01 2021 at 14:34):
on that note https://datatracker.ietf.org/doc/html/rfc8414#section-2.1 is good precident for this general concept of signed metadata inside of a discovery file while also supplying"plain" values; other techniques replace the entire file with a credential.
Vitor Pamplona (Dec 01 2021 at 14:37):
I am going to be adding the re-issuance endpoint to our registry and getting other standards to follow this spec.
Vitor Pamplona (Dec 01 2021 at 14:45):
For other specs, there might be use cases beyond invalid cards. A common one is a valid (signature is valid, keys are good), but expired health status credential. I think they can all use the same entry point.
Josh Mandel (Dec 01 2021 at 14:55):
Absolutely agree. I tried to use invalid cards as just a motivating example here.
Vitor Pamplona (Dec 01 2021 at 15:06):
Is there any other information in this config file?
Josh Mandel (Dec 01 2021 at 15:07):
Not yet, but I'm expecting we're going to identify more use cases for discoverable configuration. There are a few candidates currently under discussion in the VCI directory which include things like informational websites, types of issue
Vitor Pamplona (Dec 01 2021 at 15:07):
I'd love to get the issuer's Display Name, Display Logo (Squared SVG) and Info Website for the wallet UI.
Josh Mandel (Dec 01 2021 at 15:08):
Exactly that kind of stuff.
Josh Mandel (Dec 01 2021 at 15:08):
We've been so far trying to discuss these metadata items in the context of the directory and then migrate them out to this kind of configuration, so I'm glad to be getting a scaffold for that in place here.
Vitor Pamplona (Dec 01 2021 at 15:09):
Nice! The only problem I foresee is if those display fields are per key. then the config file might not be a good fit.
Josh Mandel (Dec 01 2021 at 15:10):
Indeed. So far we have been putting any key specific information in JWKS.json, which so far has just been revocation details
Vitor Pamplona (Dec 01 2021 at 15:11):
Trust Registry-wise, we learned that every additional annotated information should be per key and not per issuer.
Josh Mandel (Dec 01 2021 at 15:12):
Can you help me understand what you mean here? Like the issuer name, for example? The way we have defined an issuer in health cards, and issuer would have one name and multiple keys as it rotates them over time. But I might be missing something among your lessons learned.
Vitor Pamplona (Dec 01 2021 at 15:13):
There's generally a reason to have multiple keys and holders generally benefit from knowing that reason.
Vitor Pamplona (Dec 01 2021 at 15:14):
For instance, let's say a state breaks keys per county. The signer is not the state, but a given county.
Vitor Pamplona (Dec 01 2021 at 15:14):
The state is just providing the general software infrastructure to help the counties.
Vitor Pamplona (Dec 01 2021 at 15:15):
Other systems assign keys to different levels of confidence. Keys for doctors, keys for nurses, keys for church leaders. The payload is all the same (immunization record) but it is granted with a different levels of legal/regulatory authority
Vitor Pamplona (Dec 01 2021 at 15:16):
Wallet and Verifier systems would love to expose those details to their users.
Josh Mandel (Dec 01 2021 at 15:17):
In the Health Cards context, We don't make any guarantees about an issuance hierarchy. So from your example either you have state-based issuance (perhaps with a national trust that ties these together); or you have national issuance.
Issueres are free to rotate keys or segregate keys as they see fit, and the abstraction barrier is such that consumers can be oblivious to this. I understand now the tension between this model and what you are describing.
Vitor Pamplona (Dec 01 2021 at 15:17):
I don't think you should have defined hierarchies.
Vitor Pamplona (Dec 01 2021 at 15:17):
But you could allow them to give hints of their work per key
Josh Mandel (Dec 01 2021 at 15:20):
Understood. But I don't think these would replace the top level issuer label, in this case; for example, a directory might only vet the top level issuer label, and any sub-issuer key-specific labels would be below the abstraction barrier. Of course, you could publish such metadata on each key and it might be worth exploring this. But I don't think it would obviate the need to do it at the top level, and the sort of metadata you would publish per key might be more in the realm of the hints. Anyway, probably worth starting a separate thread or proposal for this :smile:
Vitor Pamplona (Dec 01 2021 at 15:21):
The EU registry, for instance is quite interesting. Some countries have just one key. Those are easy. Others give individual keys to private corps that will in turn issue credentials. The EU Gateway also does not provide any information at the registry level beyond the keys themselves. Verifiers have to manually FIND and ask those companies for the appropriate way to represent the Issuer Name in their own certificates.
Vitor Pamplona (Dec 01 2021 at 15:21):
Anyway, it's certainly a much bigger discussion.
Josh Mandel (Dec 01 2021 at 15:22):
I would be in favor of packaging up some top level metadata that support wallet UI, and would prioritize that work over key-specific metadata, but these are separate points.
Last updated: Apr 12 2022 at 19:14 UTC
