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
Andrew Hughes, IAWG Chair, opened the meeting and allowed David Temoshok to introduce the NIST reps on the call. He then introduced IAWG leadership. Questions and responses from the call are outlined below. Please use the TOC below to jump to different topics.
Federation:
Q: 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?
R: When NIST was creating rev.3 there were already fairly clear paths for the content of what became Volume A and Volume B. But, the bits about federation and network connections were spread throughout rev.2. So, in creating rev.3 that was the first attempt at pulling that all together into a separate volume. With rev.4, NIST has been able to combine comments received over the last 5 years and their experience to realize they were implying several things that were required… but were not necessarily named (i.e. how connections were made, how trust was managed, how information was conveyed, etc). There was a lot left unsaid but now NIST is trying to be explicit.
Much of the new content are not new concepts. It was in rev.3 but under an assumption. Example: the trust agreement section was already implied by the previous registration section but in a round about way. Now it is explicit. Example: the identity APIs – specifically provisioning APIs – and how account provisioning happens. It was implied that it could happen but it was not explicitly said what the different expected models were and what to do under these models.
NIST also revised and defined how they laid out the different federation assurance levels. Some updates were for clarity in response to questions received around FAL2. This revision also better reflects some of the threats being seen against federation and SSO systems – particularly at the FAL2 level. FAL2 now requires injection protection – protection of the RPs from accepting injected assertions. The requirement now at FAL2 is that RPs need to be using controls so that they only accept assertions that are in response to a request that they made and are able to tie back. NIST recommends doing that through back-channel assertion presentation – though not required at FAL2. Additionally, in Rev. 3 FAL2 requirement was all about the encryption of the assertion. Was partially about protecting the data in transit but also about the stricter audience restriction. NIST received several questions about when to use FAL2 and how to use FAL2. NIST realized early on in the process that they were conflating the data protection requirements around the assertion contents with the overall trust of the transaction that FAL2 should be giving. The encryption requirement is still there if you are passing PII in the assertion through a 3rd party in rev.4, but now it’s been decoupled from FAL2 so you can apply that requirement where it makes sense and it is truly useful and needed.
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.