Participants:
IAWG Voting Members: Andrew Hughes, Denny Prvu, Jimmy Jung, Mark King, Michael Magrath, Richard Wilsher, Mark Hapner
IAWG Participants: Eric Thompson, Lorrayne Auld, Marc Aronson, Max Fathauer, Varan Lal, Chris Lee, Jason Addis
Guests: Ben Piccarreta, Scott Perry, Simone Alcorn, Tom Barton, Lewis Lott, Noreen Whysel
NIST Reps: David Temoshok, Ryan Galluzzo, Andy Regenscheid, Connie LaSalle, Jim Fenton, Justin Richter, Sarbari Gupta, Christine Abruzzi
Kantara: Lynzie Adams, Kay Chopard

...

**Note, NIST tries weekly to review and respond to questions submitted to dig-comments@nist.gov. They encouraged the group to submit anything else that comes to mind!! Please submit all comments that you would like included WITH the Kantara submission to comments_iawg@kantarainitiative.org.

Federation:

It is noted that Volume C has more material in this revision. What is the rationale for beefing it up? Is it related to the maturity of federation in federal government over time? Or in response to certain incidents that NIST has been dealing with the last several years?

...

Significant changes were made around FAL3 as well in order to accommodate for different types of proof of possession assertions. FAL1 is still pretty similar to rev. 3.

People conveyed concern because

...

FedRAMP said you must do everything in 800-63 for all three (A,B,C) at the same level. These are often organizations that are not federated except to themselves. Have any of those comments made it to NIST or into these updates?

There were comments about FEDRAMP doing that very early on in the rev. 3 lifecycle. Things were split up into volumes (A,B,C) so that they could stay split up! Stop tying them back together!

...

NIST wants to be careful not to say they are going to be the arbiters of the actual impact determinations that the agencies will make. They Agencies will be the ones who decide their own risk tolerance. What NIST was trying to do was to give them agencies the flexibility to have more lower-level sets of controls to deal with applications that didn’t necessarily need to go all the way up to IAL2 and involve that biometric match/additional friction. The goal was to have something that could give a degree of confidence in identity, but not necessarily the same degree as IAL2. The target would be those lower risk applications. NIST is saying that cautiously, not implying there is something wrong with IAL1. It’s an attempt to give more granularity in risk management processes to agencies and organizations rather than what it was before – 0-100. The option remains to not identity proof. You can still have IAL0 (no id proofing). You do not have to identity proof if the application does not mandate it. Just because IAL1 is not ‘no proofing’ anymore does not mean the option was eliminated.

...

NIST has already seen in comments the wildly different interpretations and views on where they have gone with rev.4 in the risk management assurance selection. Some love it while others are terrified. There will need to be a balance of outcomes between the guidance itself but add-on in the implementation guidance and feedback to the agencies other components and artifacts to help them through. Again, thoughts to help communicate and fit those into a broader construct is are requested!

If 800-63 is suggesting that agencies have the flexibility to determine alternative ways to perform their proofing/authentication while achieving the same degree of risk mitigation, then one of the difficulties in rev.3 is that it does not list anything for a given assurance level (i.e., here is how we have gauged the risk in order to come up with these requirements for steps that should be taken to perform proofing/authentication). In that absence, it is difficult to list an alternative approach and how it achieves an equivalence of rigor. Making the determination of what would constitute acceptable evidence for IAL1 as opposed to IAL2/3, would be helpful in trying to maintain accordance with the guidance. It gives a baseline in which to measure any variation and justify it.

...

While not a requirement, NIST points out that account recovery process outlined in 63b calls for an abbreviated id proofing process to occur. Whether the CSP retains that data will have an impact on how abbreviated that is. The verification step needs to be done gain if the data is there to repeat that part.

Authenticator Binding

There is binding at enrollment and then post-enrollment binding.

...

Is there actually a difference between when you bind during enrollment versus at some later time? Or is it the type of authenticator you are binding to that makes the difference?

Enrollment is the tail end of the identity proofing process. There needs to be some way of associating authenticators with the person that was just ID proofed. Binding afterwards is something that tends to be much more self-service – where the subscriber decides that they need another authenticator for another end-point they have that has different interface requirements or they want to bind an authenticator that is part of one of their endpoints. They can do that at post-enrollment. It also has to do with a separate, new section on account recovery. There was a lot of confusion on that previously since rev.3 did not address it very prominently. That’s the case where someone loses an authenticator or forgets a memorized secret or something of that nature and needs to recover from that situation. NIST is very much trying to encourage the binding of multiple authenticators and allow people to use those authenticators to do self-service recovery. NIST is troubled by a lot of things that are commonly done – like email recovery and so forth – because in the case of MF authenticators, email is typically not a MF process. It’s not very secure internally either. So, NIST is trying to make that point clearer. NIST does not believe the requirements have substantially changed from rev 3 to rev 4 – but they’ve tried to state things more plainly in terms of things people will be looking for.

...