FHIR Chat · Representing IAL in FHIR · Security and Privacy

Stream: Security and Privacy

Topic: Representing IAL in FHIR

---

Josh Mandel (Mar 02 2021 at 23:49):

Is there a well defined pattern for representing identity assurance level on a FHIR Patient resource?

https://github.com/dvci/vaccine-credential-ig/issues/1 discusses two ways to do this:

• custom extension;
• apply a security label borrowing from the http://terminology.hl7.org/CodeSystem/v3-ObservationValue Code System -- but that seems like a funny code system to be using in a security label, since it's documented as "HL7-defined values for the Observation value element, when it has a coded datatype"

Any advice (here on on the GH issue) would be appreciated (FYI @John Moehrke ).

Elliot Silver (Mar 03 2021 at 18:49):

@Peter Bernhardt ?

John Moehrke (Mar 03 2021 at 19:57):

I presume you mean specifically IAL? As in to what level of assurance has the Patient resource been confirmed to be specifically the identified human? This is the level of assurance of the identity provisioning. (Distinct from the AAL, which is the assurance that the user has been authenticated for the purpose of a transaction/action/etc.).

John Moehrke (Mar 03 2021 at 19:58):

Unfortunately NIST 800-63 defines the concept of IAL, and does define some levels by number; BUT they did not define a vocabulary. They tend to stay away from declaring vocabulary as that is seen as outside their scope.

John Moehrke (Mar 03 2021 at 19:59):

I don't have handy any vocabulary that someone might have made for IAL.

John Moehrke (Mar 03 2021 at 20:01):

There is this SAML spec http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-assurance-profile-cd-01.pdf It defines HOW to convey IAL, but does not define a vocabulary

John Moehrke (Mar 03 2021 at 20:03):

seems there is some stuff for LDAP -- https://ldapwiki.com/wiki/Identity%20Assurance%20Level

John Moehrke (Mar 03 2021 at 20:06):

Ill check with the security wg. Many good resources are there that don't participate here.

Josh Mandel (Mar 03 2021 at 20:23):

presume you mean specifically IAL?

Yes, the use case here is conveying identity assurance level (1, 2, or 3)

Josh Mandel (Mar 03 2021 at 20:23):

If this hasn't come up in FHIR before, I think using a dedicated extension is fine, but I'm open to any other suggestions! e.g., is an ad-hoc .meta.securitylabel better than an ad-hoc extension?

Lloyd McKenzie (Mar 03 2021 at 20:52):

Wouldn't that be an assertion per Patient.identifier? I.e. they might have definitively been shown to be person with drivers license number X, but not passport Y? If so, extension seems like the only way.

Josh Mandel (Mar 03 2021 at 21:05):

Generally the NIST guidance assigns an IAL to the overall identity proofing step -- so like if I check your name and dob based on two forms of ID that you provide, I can say I did an "IAL-2" identity proofing.

Josh Mandel (Mar 03 2021 at 21:05):

(You could try to communicate this at the attribute level, but honestly even getting orgs to assess IAL in a coarse-grained fashion is a challenge.)

John Moehrke (Mar 04 2021 at 13:11):

Where it is applied is very key to who did what relative to the proofing.

John Moehrke (Mar 04 2021 at 13:13):

I would tend to believe that an organization defines a policy for how they proof to 1, 2, and 3. That policy indicates what is looked at, what procedure is executed, and who is allowed to do the work. This is a policy. There is also the complexity of multiple organizations using a shared Patient resource registry, thus each might have proofed.

John Moehrke (Mar 04 2021 at 13:14):

I don't think that .meta.security is the right place, but am not sure why it is not. It is meta about the Patient resource...

John Moehrke (Mar 04 2021 at 13:19):

In the new DS4P IG that Kathleen is creating, she is adding extensions available for explaining who applied a specific .meta.security vocabulary value. This is needed for the CUI codes, as it is important to know who marked something later when someone else wants to remove that mark. That extension could be used to indicate who applied the IAL indicated.
http://build.fhir.org/ig/HL7/fhir-security-label-ds4p/branches/master/artifacts.html#1

John Moehrke (Mar 04 2021 at 13:20):

which lead me back to the Integrity codes... I wonder if your use-case can use the integrity confidence codes? reading them, and thinking about how they are intended to apply as meta.security and what that means about the elements in tagged Resource... it seems really close (might be not close enough)
https://terminology.hl7.org/2.0.0/CodeSystem-v3-ObservationValue.html#v3-ObservationValue-_SECINTCONOBV

John Moehrke (Mar 04 2021 at 13:21):

put all that together... you could use the IAL codes defined in LDAP, use them on the Patient.meta.security, and if people want to meta-the-meta they can use the extensions from DS4P...

Josh Mandel (Mar 04 2021 at 13:49):

For health cards, the answer to "who determined IAL" question is basically: the organization that performed the clinical service (immunization), because if you weren't confident in the patient's identity at that point, nothing that happens later can achieve a stronger binding to the Identity

You mentioned "codes defined in LDAP", but just to be clear, which codes are these?

I also share your concern that meta.security doesn't "feel right" for this kind of information about a Patient IAL, but I'm willing to squash that concern if there's a clear recommendation to use it.

David Pyke (Mar 04 2021 at 13:51):

meta.security should be about the resource, not about the patient, in my opinion.

Lloyd McKenzie (Mar 04 2021 at 14:20):

So Josh, you're saying that the assertion about identity of the patient would be made on the Immunization? In that case, would it be an extension on the Reference type? (And presumably you'd want the reference to be version-specific?)

Peter Bachman (Mar 04 2021 at 14:47):

While I am working on a MVP for Vaccination IG security requirements on https://pahisp.org I am planning on having the patient use a persistent XML XADES signature validated by ETSI based on what was developed at CMS ESMD by Bob Dieterle to prevent medical device fraud. That doesn’t address the IAL issue directly. However 800-63 doesn’t map internationally. Passports do work internationally and come under the UN trust framework ICAO with Country level PKI digital certificates. The source of the data such as a Pharmacy or Provider is known to the patient and in my case I uploaded a photograph of the CDC shot card into an Epic EHR and then downloaded it to Apple IPhone Health App. On the back end there could be a validation step against the vaccine registry which already is using HL7 v2.

David Pyke (Mar 04 2021 at 14:53):

A large percentage of Americans don't have passports.

Josh Mandel (Mar 04 2021 at 16:44):

More context: We are talking about creating bundles that include a patient resource as well as an immunization resource that points to the patient. My goal is to decorate the patient resource with some appropriate extension or tag or label to indicate the level of identity proofing performed by the organization that created it.

Josh Mandel (Mar 04 2021 at 16:45):

I "just" want a vaccination clinic creating these bundles to have some easy way to convey the level of identity assurance they have established.

John Moehrke (Mar 04 2021 at 17:31):

I think that your use-case is indeed what a Patient.meta.security tag of the IAL would address. The IAL is a tag indicating the the data within the Patient have been assessed as level X. I disagree with Dave, this is about the data in the Patient resource.

John Moehrke (Mar 04 2021 at 17:33):

the AAL or FAL should NOT be found in the Patient resource. We are specifically talking about IAL... the level of proofing that has been done to assure that the data elements in Patient are accurate representation of the human they are describing.

Mohammad Jafari (Mar 04 2021 at 18:58):

One of the use-cases that @k connor has been working on for the FHIR DS4P IG is to be able to assign a security label to a subset or an attribute of a resource. I think this perfectly fits in that use-case; we need a security label (in this case from the Trust valueset which includes the LOA values) scoped at the particular patient identifier, the entire identifier block, or a reference.
This is not in the build yet but we have thought about two alternatives for doing this: either defining a standard security label extension that can appear anywhere in the resource, or defining a scope extension for the security labels in meta.securitywith a FHIRPath expression (or an array thereof) to specify where in particular a security label applies to.

k connor (Mar 04 2021 at 22:30):

The Trust valueset needs to be updated for the codes used in NIST Special Publication 800-63-3 https://pages.nist.gov/800-63-3-Implementation-Resources/.

John Moehrke (Mar 04 2021 at 22:44):

I don't see formal vocabulary. They have defined glossary terms, but not vocabulary with a system identification... that is what we are looking for.

k connor (Mar 05 2021 at 00:10):

Understood - the current trust codes are based on NIST SP 800-63 Rev 2 - we just need to create codes from the terms as we did before.

Lloyd McKenzie (Mar 05 2021 at 03:49):

Keep in mind that the Patient in the Bundle can be stored and then linked to all sorts of other things. It seems to me that the assertion you're trying to make is the strength of the linkage. I.e. "I'm very confident that the person I jabbed in the arm and pushed the plunger on is indeed the person with this name, gender and date of birth". Other entries subsequently linked to that same Patient resource might not be nearly so certain. Alternatively, you could put the stamp on the Bundle, not the Patient or Immunization, but then you'd somehow have to differentiate your confidence that "this was indeed the patient" from your confidence that "this was indeed the administering Practitioner".

John Moehrke (Mar 05 2021 at 14:03):

Lloyd, that is AAL (or FAL in some cases), not IAL. IAL is about identity provisioning. AAL is about authenticating at an incident of action.

John Moehrke (Mar 05 2021 at 14:34):

The need, as far as I can tell, is
Given a patient registry (which has a population full of Patient resources)
For any given Patient resource within that registry, some might have been provisioned for emergency use where there was no identity, some might have been provisioned based on walk-in with a declared name but no proof, some might have been proofed the individual having a government issued identity card that was properly reviewed, some might have been proofed by a postal mail confirmation, etc... Each of these are simply Patient resources, but some are higher assured provisioning (aka IAL).

John Moehrke (Mar 05 2021 at 14:38):

Certainly in clinical workflows like administering a vaccine or medication, there is the procedural steps commonly called "The Five Rights". The "right patient" in the Five Rights is a Authentication step (AAL). I don't say that there might not be some use to recording in the medication administration record the AAL steps taken by the practitioner executing the Five Rights. Typically there is a policy that indicates the process, and nothing happens unless all Five Rights (including Right Patient) are all executed to the satisfaction of the process.

John Moehrke (Mar 05 2021 at 14:41):

The situation where a patient is given a drug, in an emergency room setting, where the patient is not able to be identified, are exceptions. I would expect that the Patient identity in that case is not Identity Assured. I would expect that the Five Rights process still checks that the drug is about to go into the patient with the wrist band that the drug is intended for. Thus even in this case the IAL at the Patient resource level is what is needed.

John Moehrke (Mar 05 2021 at 14:41):

right?

Mohammad Jafari (Mar 05 2021 at 17:04):

@John Moehrke and @Lloyd McKenzie I think these are two separate valid concerns. Josh could explain better what their issue is but my understanding is that it is what Lloyd described. I may know for sure that the patient identified by name and drivers' license number was identity proof-ed at the time of check-in, but I may not be sure whether the person receiving a shot is the same patient because I didn't look at their ID.

However, I think the essence of all the of these cases is the level of confidence and trust in an attribute in a resource: the name or identifier on the patient resource, the contact information (e.g. "email or phone number was verified by call back"), or a reference that links a resource like Immunization a patient.

I think the general solution of being able to assign a trust security label to an attribute in a resource (i.e. a security label scoped at sub-resource level) can cover all of these cases.

John Moehrke (Mar 08 2021 at 19:00):

We discussed this a bit on the FHIR-Security call today. What we recognized is that there are two very different things that are needed by the original use-case ask.

1. IAL of the Patient Resource.
2. AAL of the link between the Immunization activity record and the Patient Resource. How sure is it that the immunization activity being recorded has correctly selected the indicated Patient reference. This is authentication, not identity provisioning. Thus this is AAL, not IAL. But it is based on the IAL of the Patient (1).

both of these seem to be needed. overall. The question is if they both must be recorded in the FHIR resources.. I had given the example of (2) being part of the process behind the Five Rigths. If you your procedure is strict, then recording that you followed the procedure with a (2) kind of record is not needed. The same can be said for (1), for example if a Patient Registry requires that the patient was highly proofed before they were given a Patient record, then the Patient resource does not need a (1).

So it is important to understand which of these is going to be variable within your data. If you know that (1) is going to vary within your data, then you need a way to record which value of (1) each Patient resource has been proofed at. If you know that (2) is going to vary within your data, then you need a way to record the (2) for each reference.

1. can be handled with the Patient.meta.security with a valueSet of IAL vocabulary. This seems appropriate as it is "meta" about the contents of the "Patient" resource. The vocabulary is unclear, but the concept is clear. An IG specific vocabulary (which the vaccine-credentials project seems to be doing) seems reasonable.
2. seems this needs an extension on the Immunization.patient element to indicate the AAL of the patient binding to the Immunization activity. This would need a different vocabulary, as AAL is different from IAL. (Even though NIST 800-63 uses numbers for both).

Further (2) is not security meta about the content of the Immunization.patient element; it is specifically an AAL of the linkage confidence. Thus this is not a general extension carrying .meta.security at the element level (which is a task that DS4P is likely to add). The AAL need is different.

This (2) might be first needed in this Immunization use-case, but one could see that this is generalizable such that any Reference anywhere in FHIR might need some evaluation of level of assurance that the reference value given is absolutely correct. We surely expect that any Reference in FHIR is always highly sure, we all know mistakes happen. What is not clear is if there is a true generalized need for the FHIR DataType Reference to add a core extension for tracking the confidence of the reference values.

So, now that I have elaborated about the need for (1) and (2) theoretically... which ones are actually needed in the vaccine use-case, and which ones might be more generally needed? These both seem unusual to be needed as values, vs simply being baked into procedure/policy.

Josh Mandel (Mar 08 2021 at 20:04):

two very different things that are needed by the original use-case ask

In the original ask, these are the same (or more precisely: they can be unified), by virtue of the the narrow scope of a Health Cards bundle (includes a patient and the immunizations given for that patient, as signed by a single issuer). So solving "IAL of the Patient Resource" is sufficient.

John Moehrke (Mar 08 2021 at 22:24):

that is what I presumed.

John Moehrke (Mar 08 2021 at 22:26):

Josh, are you working on an international spec? or is it US specific? NIST is US specific. I was not sure if you were looking for vocabulary that was US or international. In the USA space, there is a vocabulary managed by Login.Gov for their OpenID Connect - https://developers.login.gov/oidc/

Josh Mandel (Mar 08 2021 at 22:36):

Aim here is for US-specific profiles on FHIR bundles. (The overall framework is international, but the FHIR data profiles are US-specific.)

Thanks for the link; I see

An IAL value must be specified.
http://idmanagement.gov/ns/assurance/ial/1 Basic identity assurance, does not require identity verification (this is the most common value).
http://idmanagement.gov/ns/assurance/ial/2 Requires that the user has gone through identity verification
http://idmanagement.gov/ns/assurance/ial/2?strict=true Requires that the user has gone through identity verification, including a “liveness” check (this is not available in production, only in int and staging environments)

... but it's not clear to me how this would slot into a FHIR security label or FHIR extension (I mean, I could invent something like system=http://idmanagement.gov/ns/assurance/ial, code=2?strict=true, but I'm not sure that's better than just creating a custom code system in our own IG, since ... we'd kind of be free-wheeling anyway.)

Julie Maas (Mar 09 2021 at 01:08):

In forming a response, I'm curious to hear what the relying party hopes to do with this information (for example, who needs to know that FHIR data is associated with an IAL2-proofed person and how does that change how they use the information? would there be a reason to exceed typical system of record type requirements?). I'm aware of other use cases where level of identity assurance is important when coming from a client app (individual access request without portal credentials on the system) or knowing the identity of the institution securing the data (a proxy for provenance/confidence in the data).

Josh Mandel (Mar 09 2021 at 01:32):

The goal is to convey how closely a vaccination record is tied to an individual identity. Some verifying parties might decide they are willing to trust these records at IAL1, and others might set a higher threshold. We want to support a variety of usage out of the box without dictating policy for verifiers.

Julie Maas (Mar 09 2021 at 03:34):

Adding an identity assurance level to the resource seems like a good idea in general. We have talked about similar questions in the FAST Identity tiger team so some of those materials might be relevant to your use case. It seems knowing the assurance level would soon be followed with the question "what is the verified name, DOB, & DL# or passport #" of the identity this vaccination relates to (or do you not think so?). Related topic: the big vaccination supersites are not doing IAL2 today that I am aware of, so we probably want to also be able to express more granular levels including LoA-2 In Person which is certainly better than IAL1 (no proofing) but not as strong as IAL2. My point is: it may matter more to indicate which evidence and attributes have been verified, than to just know a level of assurance and having only IAL1 and IAL2 as options might not be as meaningful as other levels could be in the short term (happy to hear more & try to help tho'!).

Josh Mandel (Mar 09 2021 at 03:47):

So we're only conveying two attributes in the Patient resource in our basic profile (name, dob) and we want to communicate the level of assurance obtained by the immunization provider. Indeed there may be targets <IAL2 that are still worth delineating from IAL1; that's a great point @Julie Maas . (Realistically we want a clear way to get at "did you check an ID at the visit where you administered the vaccine".)

Josh Mandel (Mar 09 2021 at 03:58):

I've been looking at this as an IAL1 vs IAL2 distinction, and my reading of the NIST guidelines suggests this isn't massively far off, but if there's a clearer or more accurate set of concepts we should consider using, that'd be A-OK (we just want to give issuers a way to codify their practices with a single well specified code on the Patient).

FYI @Alan Viars in case you have a perspective on this.

John Moehrke (Mar 09 2021 at 12:53):

and to confirm... you are indicating the IAL value in the Patient.meta.security. You are defining your own vocabulary that you define as mapping to NIST 800-63 IAL levels. This seems right to me. Especially since in this use-case is not much unlike the use-cases that drive the .meta.security vocabulary for integrity https://terminology.hl7.org/2.0.0/ValueSet-v3-SecurityIntegrityObservationValue.html

Alan Viars (Mar 09 2021 at 13:26):

Interesting conversation. I've been calling this (jokingly) this NIST "IAL 1.8" Is ...more than 1 but less than a full 2. Could be a "soft 2". As @Julie Maas points out we really do not expect a true IAL2 at a vaccination site.

Chris Shawn (Mar 09 2021 at 13:27):

Regarding the difference between IAL1 and IAL2, I see a huge difference. IAL1 is self-asserted. According to 800-63A, the credential service provider does not verify or validate identity attributes. IAL2 requires either remote or in-person proofing with well-defined documentation requirements. IAL1 is unsuitable for establishing identity. That said, I agree IAL2 might be overkill in some use cases. But a level of assurance greater than self assertion is needed.

Alan Viars (Mar 09 2021 at 13:31):

Call it "IAL 1.5"? In my state, NC, asking for driver's license does not occur at vaccination points.

Alan Viars (Mar 09 2021 at 13:33):

but if a REALID was scanned and the person is in front of you, that's an IAL2 in my opinion.

Alan Viars (Mar 09 2021 at 13:33):

That's how our OIDC Identity Provider works anyhow.

Alan Viars (Mar 09 2021 at 13:38):

This keeps coming up so I think there is a need for a slightly different codeset than NIST's. I am interested in about how this is represented in IdPs like OIDC LDAP and SAML......not just FHIR.

John Moehrke (Mar 09 2021 at 14:05):

this is exactly why NIST does not define vocabulary. The vocabulary tends to need to come from an organization closer to the real-world where they can tie each code to a specific policy rather than a conceptual concept.

Jenni Syed (Mar 09 2021 at 14:10):

Are there any concerns that we're representing something that is very "instance of a visit" specific on something that has a longer lifecycle? This seems like a mismatch

Jenni Syed (Mar 09 2021 at 14:11):

just because 1 person in the record on 1 visit did this identity assurance, it doesn't mean that it always applies

John Moehrke (Mar 09 2021 at 14:19):

Jenni. That is the distinction that I have made between IAL of the Patient resource, vs AAL of the linkage between the Immunization record and that Patient resource. The AAL is session specific (authentication), vs the IAL which is identity proofing. It is very important to differentiate and be specific about what is being represented.

Julie Maas (Mar 09 2021 at 15:14):

And isn't this use case for identity assurance just about the vaccination event details?

Alan Viars (Mar 09 2021 at 15:29):

Right @Julie Maas

Alan Viars (Mar 09 2021 at 15:30):

Okay how about this? https://github.com/TransparentHealth/healthcare-trustmark

John Moehrke (Mar 09 2021 at 15:30):

I think that is why Josh is focusing on IAL. The IAL of the Patient is critical, and that is what they recognize they need to accept that some patients will bring a government issued picture ID, thus able to get to IAL3; while other patients will not have access to that so might only be able to be assured to IAL2. Thus they need to record the actual IAL achieved.

Alan Viars (Mar 09 2021 at 15:31):

right IAL can be communicated without IAL. Thats why LOAs were deprecated.

John Moehrke (Mar 09 2021 at 15:31):

the AAL they can fix at a specific level through procedures like "The Five Rights". Thus never allowing an immunization happen unless a specific AAL has been achieved.

Alan Viars (Mar 09 2021 at 15:32):

I think AAL is irrelevant to immunization situations.

John Moehrke (Mar 09 2021 at 15:33):

Alan Viars said:

right IAL can be communicated without IAL. Thats why LOAs were deprecated.

what? did you mean to say IAL can be communicated without AAL?

John Moehrke (Mar 09 2021 at 15:34):

Alan Viars said:

I think AAL is irrelevant to immunization situations.

I disagree... see my statements on "The Five Rights". It is true I am transferring the purely IT concepts that AAL is often focused on, into a procedural mechanism. But it is important to be sure you have the "Right Patient"

Alan Viars (Mar 09 2021 at 15:34):

Identity assurance is a separate concern from authenticator assurance. This is why NIST split them up.

Alan Viars (Mar 09 2021 at 15:35):

What authenticator (AAL) must a person use at time of poke? Its just not part of this flow.

Julie Maas (Mar 09 2021 at 15:35):

That being said (this is intended to only be relevant to the vaccination record), I'm wondering how useful it would be to be able to express how (name, dob) is validated & that could apply to this use case and then also to a record more generally. Presently DL or Passport might be indicated as the method for validating (name, dob). Later, IAL2 may be possible. Alan, your 1.5 for self assertions seems generous. John, I'm not seeing how IAL2 is done at a supersite, certainly not IAL3. Today they're LoA-2 In Person maybe because you also have to confirm the home address.

John Moehrke (Mar 09 2021 at 15:35):

Alan Viars said:

Identity assurance is a separate concern from authenticator assurance. This is why NIST split them up.

thanks. agreed. just that your original sentence did not say that

Alan Viars (Mar 09 2021 at 15:36):

@Julie Maas I would not use the term LOA. Just.. IAL/AAL

Julie Maas (Mar 09 2021 at 15:37):

Alan, while it's still in practice LoA-2 In Person in a deprecated NIST pub is more accurate than IAL 1.5 defined as a "self assertion" in GitHub 30 minutes ago. :)

Alan Viars (Mar 09 2021 at 15:38):

@Julie Maas Would you suggest a more sensible IAL1.5 definition.

Alan Viars (Mar 09 2021 at 15:39):

Self asserted and in person is different than just self asserted?

Julie Maas (Mar 09 2021 at 15:45):

I would like to think about that a little but so that others may give feedback, what first comes to mind is LoA-2 In-Person language minus mailing notice to address of record (the a,b,c part), unless we believe confirmation of an associated electronic or home address is being performed. At least referencing this may give more context: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63-2.pdf (see p. 33).

Alan Viars (Mar 09 2021 at 15:46):

I guess I'm saying, when a person shows up and gets a vaccine, in most cases that would be a 1.5. Maybe 2 in some cases, but usually not. @Josh Mandel ^^

Since there is no password or authenticator in a vaccination site visit that would not meet LOA2? I could be wrong..I often am :-)

Julie Maas (Mar 09 2021 at 15:47):

I see what you mean. Communities exist today which use LoAs only for identity assurance and not authentication; in that case they state "LoA-2 identity verification" (etc.) and do not then require an authenticator, so long as language is clear authentication level of assurance is not specified. Self asserted means I'm telling you my name and dob without substantiating that through evidence. LoA-2 In-Person means someone looked at me next to my photo ID to confirm my name, address and dob (plus this extra a,b,c part that's achieved by mailing notice to home address of record, verifying electronic account associated with me in records, etc). But address doesn't seem to be verified in the workflow as I understand from Josh. At any level of assurance, it's not as simple as what we are discussing here but I'm trying to distill down to the pieces of identity evidence involved so we are even in the right ball park...

Alan Viars (Mar 09 2021 at 15:49):

Id say that if someone looks at my photo ID and that is a REAL ID, then it would be "IAL2" and expressed in vot as "P2". No AAL No C.

Julie Maas (Mar 09 2021 at 15:49):

If the person doesn't have a real ID or passport, they would need a utility bill and certified copy of birth certificate (for example) or another strong ID in addition to regular driver's license to be verified at IAL2.

Alan Viars (Mar 09 2021 at 15:50):

In Europe maybe

Alan Viars (Mar 09 2021 at 15:51):

There is some disconnect between REALID and NIST 800-63-3 and "Identity Assurance for OIDC".

Alan Viars (Mar 09 2021 at 15:57):

If its a REALID, that vetting has already been done.

Alan Viars (Mar 09 2021 at 15:58):

https://www.ncdot.gov/dmv/license-id/nc-real-id/Pages/requirements.aspx

John Moehrke (Mar 09 2021 at 16:06):

and that is why it is needed to record the IAL for the Patient. There is variation

John Moehrke (Mar 09 2021 at 16:20):

this is also why the NIST concepts of IAL1, IAL2, and IAL3 are not vocabulary... because they are not specific enough to the setting, process, and policy. So this is why it is good that the IG try to create a specific vocabulary

Josh Mandel (Mar 09 2021 at 16:46):

This has been an enlightening discussion. I'd been hoping to align with existing terms and practices to avoid this kind of ad-hoc-ery, but after reviewing this discussion, I'm thinking there's nothing "out there" that comes very close to what we want. Am I crazy to think the "low hanging fruit" would be essentially a coding system with values like:

• code-a "name and birthdate were self asserted"
• code-b "we checked some kind of ID or other evidence to verify name and birthdate"
• code-c "we checked a US state or nationally-issued photo ID to verify name and birthdate"

... and we'd ask issuers to assign the "highest" value that applies?

Julie Maas (Mar 09 2021 at 17:03):

Of course you're not :) I see how this makes sense if we can't meet the address verification piece. One question...what is an example of evidence that might fall under "code-b"? Birth certificate perhaps? Elements are lost such as apparent document authenticity, expiration, etc. when not pointing to the NIST pubs obvs., but I see the rationale for this as a starting point.

Josh Mandel (Mar 09 2021 at 17:11):

For (b), I was thinking that something like a university ID might fall in this category, or a combination of utility bills and an old photo ID or something. I mean, basically just "we checked something" vs "we didn't" vs "we checked a government photo ID".

Julie Maas (Mar 09 2021 at 17:14):

That makes sense. I'm wondering if you want to treat the case where you confirmed the name but couldn't confirm dob -is that useful to the relying parties or no?

Josh Mandel (Mar 09 2021 at 17:16):

I worry that none of the usage is going to be super precise; like, I can totally imagine a scenario where relying parties want to make this distinction and might have different rules, but how accurately are issuers really going to convey this nuance? The simpler the model the better from that perspective.

Julie Maas (Mar 09 2021 at 17:48):

Agree. It might be very useful to make a list of recommended code-b ("other") identity evidence if there were possibility of a little more structure though. For example: "confirm name and dob using NIST 800-63-3a strong or fair identity evidence that includes both items" (there are a few lists circulating & additional guidance is expected to be forthcoming). This would also help rule out things like SSN on its own and show the relationship to that standard.

John Moehrke (Mar 09 2021 at 17:58):

or, just make sure the vocabulary valueset is extensible... and don't use numbers so as to imply some fixed priority to the values you do have.

John Moehrke (Mar 09 2021 at 17:58):

and now... you know why NIST refuses to get into the vocabulary business... sticking with concepts

Josh Mandel (Mar 09 2021 at 17:59):

If these are examples, I think that'd make good sense. Any chance you'd want to propose specific codes and definitions for these three concepts @Julie Maas ? I have a feeling your intuitions are a lot better honed than mine... We could even start in comments on https://github.com/dvci/vaccine-credential-ig/issues/1, and feed these into a fsh file as they settle out.

Julie Maas (Mar 09 2021 at 18:27):

I don't know about that but I will add some content in comments as you suggest.

Alan Viars (Mar 09 2021 at 20:05):

Perhaps look at the https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html
I think these sorts of identity assertions should live outside of FHIR when possible.

Josh Mandel (Mar 09 2021 at 20:15):

A SMART Health Card is a Verifiable Credential; other than inside the fhirBundle claim, is there a different place in the VC payload you're suggesting for these identity assurance assertions @Alan Viars ?

Alan Viars (Mar 09 2021 at 20:42):

@Josh Mandel Alongside the "credentialSubject'? or in the "vc"? Add "vot" and "vtm" claims there?

Josh Mandel (Mar 09 2021 at 20:56):

I'm not seeing these in https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html; can you maybe share an example of what this would look like, starting from https://smarthealth.cards/examples/example-00-b-jws-payload-expanded.json ?

Alan Viars (Mar 09 2021 at 21:01):

smarthealthcard-example.json Here you go @Josh Mandel

Alan Viars (Mar 09 2021 at 21:03):

the vtm defines the actual rules. In that example I used the straight NIST one. Honestly I think in many cases an IAL of 1 is good enough for this use case.

Alan Viars (Mar 09 2021 at 21:04):

As I mentioned, requiring identity proofing at point of poke only slows down the process and deters some people from vaccination. I'm sure it wouldn't fly here in NC.

Alan Viars (Mar 09 2021 at 21:07):

Oh I may have been confusing, The https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html is a different animal altogether. Its where you actually record the kind of docs used fo ID verification...such as government issued ID, utility bill, etc. The vot/vtm is just a simple codification, which is all that is needed IMHO.

Josh Mandel (Mar 09 2021 at 21:08):

And does P2 here mean IAL2, or something else? How would you convey something like what we've been calling IAL 1.5 (i.e. "we looked at a driver's license but didn't verify your address etc")?

Alan Viars (Mar 09 2021 at 21:08):

P2 precisely means IAL2...according to the trustmark.

Josh Mandel (Mar 09 2021 at 21:09):

Right, but can you suggest how you'd write the 1.5-ish thing?

Josh Mandel (Mar 09 2021 at 21:09):

Honestly I think in many cases an IAL of 1 is good enough for this use case.

The challenge is that IAL 1 doesn't provide any indication of whether a vaccination checked IDs at all. I don't disagree with you that it's good enough for many relying parties, but it doesn't technically convey any binding between vaccine record and a person's identity.

Alan Viars (Mar 09 2021 at 21:09):

Create a different trustmark. Let me make another with that in mind.

Josh Mandel (Mar 09 2021 at 21:10):

And is this practice of vot claims in a VC standardized somewhere? Is there a full URL associated with vot (in a JSON-LD sense)? And is there a standardized concept published for P2 or P1.5 or a place where such concepts would be published?

Josh Mandel (Mar 09 2021 at 21:10):

Just trying to make sure I understand the intention behind your example (which is helpful!)

Alan Viars (Mar 09 2021 at 21:10):

smarthealthcard-example-IAL-1-5.json Like this?

Josh Mandel (Mar 09 2021 at 21:12):

Ok! (Questions above to check my interpretation.)

Alan Viars (Mar 09 2021 at 21:12):

Putting "vot" in a VC? Not 100% sure, but vot is a standard. You can define your own trust mark, which is the purpose of including the vtm claim alongside.

Alan Viars (Mar 09 2021 at 21:14):

vot is really designed to be contained in an id_token in OIDC, but it could be used in other contexts. An id_token is a credential that can be verified, but maybe not a VC as being discussed here

Julie Maas (Mar 09 2021 at 21:16):

Earlier we identified two new levels of assurance that seem relevant to vaccinations: b) name and dob verified through some evidence other than c) name and dob verified through a US driver's license or nationally issued passport. So, adding a 1.5 "to be defined" would collapse that into just one option that is more ambiguous and that level 1.5 would still need to be defined.

Alan Viars (Mar 09 2021 at 21:17):

Those would be published in the Trustmark, which is just a URL that points out what the P and C values in the vot claim mean.
For example, an IAL of 2 and an AAL of 2 would like vot= P2C2" / vtm="https"//example.com/trustmark". I dont think the C would apply at all in this use case since there is no password and no transaction. That only makes sense in an OIDC/SAML login event.

Alan Viars (Mar 09 2021 at 21:19):

@Julie Maas consider the 1.5 thing I created just a placeholder for discussion. But yes there could be a 1A and 1B instead of a 1.5.

Alan Viars (Mar 09 2021 at 21:20):

Here is the Vectors of Trust Spec. https://tools.ietf.org/html/rfc8485 Check out Appendix A. This came out before 800-63-3.

Alan Viars (Mar 09 2021 at 21:24):

I have a question about the QR code in the example. When I scanned it, my phone said there was no useable data. Is that to be expected?

Alan Viars (Mar 09 2021 at 21:26):

I just think putting this data in a standard claim, vot, recognized by the OIDC world is better than encoding it in a FHIR Bundle.....more generic that way.

John Moehrke (Mar 09 2021 at 22:00):

I just checked with a senior in my family. To signup for a timeslot for COVID-19 vaccine, their identity was proofed by their healthcare provider portal login, which likely was proofed by way of a postal-mail challenge. This is when they filled out the typical medical questionnaires too.
At the vaccine time, they were identity proofed by way of their state issued drivers license, and they did not have the REALID qualifying drivers license. procedurally this was likely quickly linked to the scheduled timeslot above.
When the vaccine was administered they were asked to state their name, birthdate, and address. Typical of a "The Five Rights" process.
They did observe few (one) person was filling out the forms on-site, so everyone knew to do the above steps prior to showing up. What level of authentication the one person registering on-site is unknown.
So, none of this seems to fall nicely into the given IAL levels. But we certainly know that healthcare accepts a much wider IAL in the name of safety and care for health.

Alan Viars (Mar 10 2021 at 16:25):

In my case, here in NC, my identity, and date of birth was self-asserted when I went to get vaccinated. No checking whatsoever. Just to widen this conversation a bit, I asked folks on LinkedIn . Here is a link to that thread.... https://www.linkedin.com/posts/videntity_healthcare-identityproofing-digitalhealth-activity-6775258397467000832-Lx7n

Funny that someone else said "we need an IAL 1.5".

Josh Mandel (Mar 10 2021 at 16:57):

In my case, here in NC, my identity, and date of birth was self-asserted when I went to get vaccinated.

This is fine; we just want sites to indicate whether they're following this practice vs checking an ID.

Josh Mandel (Mar 10 2021 at 16:58):

This comment from LinkedIn (thanks for creating the post) is spot on, to my mind:

A requirement to achieve IAL2 before receiving any healthcare services including a vaccination cannot be mandated. This is not like voting or getting a passport. However, a HC provider needs to do their best to confirm the identity of the patient. And public health needs to do their best to keep accurate vaccination records. There will always be a number of people who can’t or won’t provide sufficient evidence around their identity. And there will be those who provide fraudulent identity info.

John Moehrke (Mar 10 2021 at 18:38):

on the security wg call, we concluded that healthcare needs to step forward and provide our own concepts of 'identity proofing'. This has been done in the past, but I don't know of anywhere that these discussions have moved into a standards organization. This discussion was specific to separate the Policy decisions for the various grouping, from the technical discussions on how to convey it and what the expectations are. We reminded ourself that NIST 800-63 is specific to Remote access to Information Technologies. It is neither intended for healthcare, nor intended for physical or telehealth situations. Thus alghough it is a useful model, it is not one that fits healthcare well.

Alan Viars (Mar 10 2021 at 20:09):

@John Moehrke I agree healthcare needs its own model, but I don't think doing it in FHIR is a good idea. Best to use standard non-healthcare specific identity constructs like vectors of trust and make a healthcare specific set of codes for healthcare there. Representations of identity should be compatible with things like OIDC, SAML and LDAP in my opinion.

John Moehrke (Mar 10 2021 at 20:43):

Yes, that is what I was proposing. The need is a Policy Standard, much like NIST 800-63 is a policy standard. These policy standards then have implementations in technology such as FHIR.

Alan Viars (Mar 12 2021 at 15:43):

Yes @John Moehrke after sleeping on it i think putting this info in the patient resource seems okay, but would like to suggest using the "vot" as a field name and define a health-specific Trustmark. Here is the Vot spec: Here is the Vectors of Trust Spec. https://tools.ietf.org/html/rfc8485

John Moehrke (Mar 12 2021 at 15:49):

interesting spec (vot). not sure that adding an extension for this is so much better of a solution than using the element that we already have for the purpose. the .meta.security is intended to hold integrity evaluations, there is a valueset available for this use in other contexts. We do have LOA codes in that valueset, we just have not added IAL codes into that valueset. So seems like this proposal for a vot extension seems unnecessary.
Also, the IAL need is not a transaction, it is an assertion of fact. So I am also not sure it fits our need.

Alan Viars (Mar 12 2021 at 15:52):

I took another pass on an "IAL 1.5", and think this might cover the bases more. Please have a look @John Moehrke @Josh Mandel @Julie Maas https://github.com/TransparentHealth/healthcare-trustmark

Alan Viars (Mar 12 2021 at 15:53):

Revised criteria for 1.5 https://github.com/TransparentHealth/healthcare-trustmark/blob/main/ial-1-5-definition.md

John Moehrke (Mar 12 2021 at 16:01):

your 1.5 seems closer to a 1.2.. Is this really the set of criteria that people are willing to accept is higher than 1 ? I am especially not liking

• a successful login wiht an associated account -- associated with what? Twitter? I think you mean a medical portal account?
• a cryptographic key verification -- like a zero trust cert ? Just because I have a self-signed cert should not be useful for anything (PGP). Just because I have a TLS cert issued by lets-encrypt should not mean anything... I suspect you may have implied a certificate proof with certificate root in a trusted root (like Direct Trust).
• Presentation of a state or federal (sp?) id.... if it is REALID , then doesn't that rise to IAL 2? I think the gap is when that ID card is not REALID compliant. Right?

John Moehrke (Mar 12 2021 at 16:02):

what about identity verified through postal-mail round-trip? This is the most common healthcare portal validation.

John Moehrke (Mar 12 2021 at 16:03):

other than that... I like the IAL stuff. clearly I think this can just go into Patient.meta.security

Peter Bachman (Mar 12 2021 at 19:14):

So in my simplest use case just to walk through the logic the subject makes an appointment (might be done by proxy that has some identifiers provided patient) and the data is further refined to a specific IAL level as required by the relying party.At the appointment the pharmacy or injection site verifies ID for billing purposes and to create the CDC shot card while taking any other pertinent medical information such as allergies etc.

Peter Bachman (Mar 12 2021 at 19:39):

The output of that verification process is a shot card.

The patient photographs that and the lot # etc is entered into the EHR after upload through the patient portal.

At that point the patient is already registered with the provider and has a login.

The binding of the patient and immunization record happens in the EHR at a sufficiently defined IAL to prevent liability in HIPAA context. Notably my smart on FHR application that I use notes that they are not HIPAA compliant. What was lost in translation, versus a HIPAA defined transfer of data? Seems like any data flow to a patient comes under HIPAA rules?

The provider processing the shot card data into FHIR has a reasonable IAL level expectation of identity quality and potentially verify the immunization encounter with the pharmacy /injection site out of band if necessary. However the registry is the ultimate source of ground truth.

The patient then downloads the same data (now in FHIR format) as “self reported” and it is present in the smart on FHIR app and can be exported I am assuming the connection to the provider was not spoofed. That’s a big assumption considering recent personal testing and issues surrounding JWT token theft as well as general OWASP vulnerabilities.

At that point the patient/subject seals the FHIR data with a 800-63 identity since it was not included with the immunization resource. The patient has the data, they have the provenance for the data in terms of an audit, and the next step is to digitally sign the data as the owner.

Even a simpler approach would be to use Adobe scan for the shot card and apply a digital signature in Acrobat using a valid x.509v3 certificate to the image of the shot card. Of course if the image is altered from the original they could sign garbage but that can be checked via a verification loop to the registry. I don’t think identity is the problem here except it’s not passing through from the EHR so if this was done before the patient got the data, that would save the patient having to attest to it with additional steps. Personally signing the actual XML seems to be simplest.

Alan Viars (Mar 14 2021 at 20:18):

@John Moehrke Yes this "1.5" is just a placeholder to facilitate discussion, it definitely could be revised. And yes presentation of a REALID would normally mean IAL2, but not necessarily. How would someone verify the REALID? If the person is not properly trained, but still presents an ID , then may this in-between designation, 1.5 may be better more suitable

Alan Viars (Mar 14 2021 at 20:21):

@John Moehrke Good point RE the crypto-key and login. Key needs to be issued from a trusted issuer. Likewise login would need to be from some trusted source, I was imagining logging into to a MyChart or similar. Also logging into a state/federal IdP. Not Facebook, or Twitter.

Alan Viars (Mar 15 2021 at 13:01):

I think the "Validation Requirements " for IAL2 are what make it hard for organizations to call it a 2.... Here is an excerpt from: NIST 800-63-3 "The CSP SHALL validate each piece of evidence with a process that can achieve the same strength as the evidence presented. " In the common case where a driver's license is presented, but not really verified, that would not count as a 2. To count as a 2 the license verification process would need to be "STRONG" according to NIST. The person inspecting the license would need training/technology to achieve a true 2.

Alan Viars (Mar 15 2021 at 13:04):

For STRONG
The evidence has been confirmed as genuine:
*using appropriate technologies, confirming the integrity of physical security features and that the evidence is not fraudulent or inappropriately modified, OR

• by trained personnel and appropriate technologies, confirming the integrity of the physical security features and that the evidence is not fraudulent or inappropriately modified, OR
  *by confirmation of the integrity of cryptographic security features.
  *All personal details and evidence details have been confirmed as valid by comparison with information held or published by the issuing source or authoritative source(s)

Alan Viars (Mar 15 2021 at 13:08):

Even in cases where some identity proofing is occurring, such as showing a license, this rigor of document inspection is probably almost never occurring in practice. I think IALs would be be mostly 1s and "1.5s" at any mass vaccination sites, with very few 2s.

Alan Viars (Mar 15 2021 at 16:35):

Updated based on your feedback @John Moehrke https://github.com/TransparentHealth/healthcare-trustmark/blob/main/ial-1-5-definition.md

Alan Viars (Mar 18 2021 at 12:48):

For background/FYI I am providing these links to efforts in the Linux Foundation

Alan Viars (Mar 18 2021 at 12:49):

https://www.covidshield.app/
https://www.covidcreds.org/
From Raphael Richards: https://www.linkedin.com/in/rafaelrichardsmd/

Peter Bernhardt (Apr 01 2021 at 20:28):

(deleted)

Peter Bachman (Apr 20 2021 at 02:19):

Seems like the discussion about representing IAL is more relevant to identity providers than actual vaccination providers.

Certainly is relevant to validated vaccination credentials.

I am still looking to get a electronic validated vaccination list for my use case as an after the jab UX to build something at a specific IAL level.

I presented a valid but non real ID DL at my two appointments which was acceptable.

I was able to get a print out from a different branch of the same pharmacy chain after presenting the same DL.

So now I have the shot card, which the second pharmacist changed to add the phone number of the first pharmacy, some print outs of the vaccination record, another record from the original pharmacy, a Yellow Card from the 70’s they didn’t want to update and multiple failures of an unknown origin based on Credit KBA on their website to get anything electronically.

The data never made it to my provider EHR, still have check the state IIS. I formerly had LOA3 credentials before NIST changed the standards to IAL. It’s not clear to me that electronically, exactly where validation is passed to the consumer for reuse.

Alan Viars (May 04 2021 at 13:17):

@Peter Bachman I generally agree that "IAL is more relevant to identity providers than actual vaccination providers". I don't think a presentation of a DL (even if its realID), is necessarily IAL2 according to NIST.

Peter Bachman (May 04 2021 at 14:49):

I am learning more about the digital vaccination use case day by day and it has a lot of moving parts. Mostly it indicates the complexity in keeping the system open. Right now the use case involves FHIR data that is valid and sourced from the EHR because I photographed the CDC card and they loaded it into my personal record where there has been multiple forms of identification already. So I got the data from the Pharmacy and using the patient portal, uploaded it and then got the same data back. Is it suitable to use for a EU Covid-19 certificate or some kind of ZKP? It is self reported since my provider never got a fax from the Pharmacy. I have other options, I can convince EPIC to sign the Immunization Record first before I get it downloaded to Apple Health. The provider is supposed to have a bilateral data relationship with the State IIS, so they can validate the Immunization Resource or I can work on the Pharmacy to Provider Link. I can also walk a copy of the Pharmacy vaccination history over to my provider but is the FHIR record still self reported?

It is very likely Epic and Cerner are planning to send signed data to me which is a vast improvement if it is usable in the right format and I can keep the validation linked to my identity to create the European Covid-19 certificate. My goal however is to take the patient obtained XML and sign just the relevant parts for data minimization. Right now Xades XML signatures. Then present it using Verified Credentials and possibly ZKP. I also could reach the necessary IAL by convincing the stakeholders to put in a e-passport and real Id reader to merge the Pharmacy data into a VC and then package it or use ISO Micov digital id for those who wanted a EU compatible object with ID verification and the immunization record.

John Moehrke (May 04 2021 at 15:54):

see discussion #smart/health-cards

Douglas DeShazo (Jan 05 2022 at 19:47):

Is there any relationship or representation of IAL2 within SMART on FHIR?

John Moehrke (Jan 05 2022 at 19:52):

There is not specific IAL/AAL in SMART; I would expect it to come from the OpenID-Connect, as that is the authority for identity and authentication. SMART is focused on authorization.

John Moehrke (Jan 05 2022 at 20:01):

https://openid.net/specs/openid-connect-4-identity-assurance-1_0-08.html -- focuses on making claims about identity, but stops short of rolling up these assurance claims to a overall value as discussed in NIST-800-63

John Moehrke (Jan 05 2022 at 20:01):

@Luis Maas or @Josh Mandel do I have that right?

John Moehrke (Jan 05 2022 at 20:56):

@Joe Lamy has some details on OpenID-Connect on this

Josh Mandel (Jan 05 2022 at 21:19):

SMART profiles OIDC and indeed any standardized properties can be included as claims in an id_token. But the doc John referred to is quite new, so in addition to the limitation he identified, I also wouldn't expect to see real world support for such capabilities in SMART enabled EHRs anytime soon. This would likely need quite a bit of consensus work.

Josh Mandel (Jan 05 2022 at 21:21):

(new as in 2019 era draft; latest draft is at https://openid.net/specs/openid-connect-4-identity-assurance-1_0.html)

Josh Mandel (Jan 05 2022 at 21:22):

Not sure if UDAP is looking at profiling this more directly @Luis Maas

Douglas DeShazo (Jan 05 2022 at 21:54):

Thanks @John Moehrke and @Josh Mandel , much appreciated. I was missing the OAuth piece. Thanks again.

Josh Mandel (Jan 19 2022 at 22:20):

For FHIR-31702 image.png does someone from #Security and Privacy want to provide a one-sentence description to include at https://hl7.org/fhir/modules.html#modules ? @John Moehrke ?

Josh Mandel (Jan 19 2022 at 22:21):

Or possibly this comment has the intended text?

The Security and Privacy Module describes how to protect a FHIR server, how to document what permissions a user has granted, and how to keep records about what events have been performed.

Josh Mandel (Jan 19 2022 at 22:21):

I'll use that :-)

---

Last updated: Apr 12 2022 at 19:14 UTC