search

smart-on-fhir / health-cards

Health Cards Framework: implementation guide and supporting material
Other
261 stars 84 forks source link

Request change to use only NIST IAL Levels 1, 2, and 3. #180

Closed aviars closed 3 years ago

aviars commented 3 years ago

The notion of "between 1 and 2" could and should be addressed and it looks like it will be by NIST in revision 4. See https://github.com/usnistgov/800-63-4/issues/1

For this use case, I am strongly recommending using NIST IAL levels ( 1, 2, or 3) as they are. Remove 1.x codes. This bit is optional anyway. When a "low identity assurance" is given, use IAL1.

Another issue with the 1.x is the . in the string. It will cause issues when an attempt is made to codify these values within the Vectors of Trust format. See https://datatracker.ietf.org/doc/html/rfc8485.

This PR that sets the codes to just use NIST codes. --> https://github.com/smart-on-fhir/health-cards/pull/179

jmandel commented 3 years ago

Thanks for pointing out upcoming work from NIST!

The current https://smarthealth.cards/ial defines its own system specifically to avoid compatibility issues (e.g., name/code conflicts) with other in-flight efforts. Would be great to align on updated values when there's something new available and widely supported; in the meantime, our "ial" valueset reflects the result of extensive discussion at https://chat.fhir.org/#narrow/stream/179247-Security-and.20Privacy/topic/Representing.20IAL.20in.20FHIR . Indeed, reviewing the discussion, you yourself suggested:

Call it "IAL 1.5"?

In the meantime, this spec is supporting production implementations in multiple countries and we don't want to break implementations without a very clear justification (to be clear, I don't think most implementations are supporting these tags in a robust way, but it's not the easiest thing to track.)

aviars commented 3 years ago

Yes guilty as charged! I was on the 1.5 bandwagon, but later changed my opinion because it will be addressed in version 4. These tags are not being supported in a robust way to my knowledge, but that change at this point may break some implementations. Either way its not the end of the world, but I wanted to point it out.