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 and questions you’d like to review responses for.
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?
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.
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!
The scope of 63C is federation and assertions that includes use of federation protocols to support enterprise SSO. When talking about using federation and federation protocols that encompass both the inter-organization case of exchanging identity attributes and information as well as within an organization to protect the SSO systems.
Agencies have asked “I’m not federating externally but I am using SSO and using federation protocols to support that, what is the expectation to apply federation levels to that particular use case?” NIST is attempting to make clear within the text and through their presentations that it is still something covered within 63c. That said, if your use case requires IAL3 and AAL3 it may not necessarily require FAL3. They are intended to vary separately. That needs to be determined on the specifics of the use case. With that in mind, if you are using federation protocols and systems in an internal enterprise system you should have some FAL, but it is not necessarily going to be the same number as the other dimensions.
One issue is understanding how equity in federation applies. Do you have any brief comments on how you think the inclusion of equity has impacted federation?
It’s a little bit of a different context than 63a and 63b because it’s more of an underlying protocol. There are certain aspects, particularly as you start to look at your trust agreements and other agreement components and the level of assurance expected from providers. Some of that information & documentation is going to be expected to be captured there but certainly not the same as 63a and 63b. Aspects of equity definitely need to be built into federation agreements – and potentially how to explain some of these things. More of an accessibility issue rather than equity. Ensuring the end-user understands what’s happening when federation occurs and explaining it in a way that a user can actually understand what is happening.
Some of this is referenced in the new equity section of the 63c rev.4 draft. A bit of a different case than proofing where there is a lot of fairly specific examples of issues that are discussed. There are equity considerations that need to be taken into account while developing the trust agreements and policies so that the impact the system may have on the users is understood. This is a place where the distinction between equity, accessibility, and privacy all start to blend together. Do not consider equity, accessibility, and privacy issues to exist in a vacuum – they are very much intersectional. If there is a privacy issue that lends itself to an undue burden/impact for a particular group, that is considered an equity impact. It might be talking about it in the context of privacy or security, but the point is looking at the outcome (what is happening across demographic groups or socioeconomic strata? Is it creating an inadvertent barrier to entry or access?). It’s more complicated as the issues start to overlap when you think about where this comes up in federation – and across all of the volumes.
In 63c there now appears to be requirements on the RPs. Previously, it’s been mostly requirements on the IDPs/CSPs. Any observations on this? Internally, Kantara will need to adjust their assurance program model is fit these new requirements.
The requirements on RPs are not new. Another example where 63c requirements were there but they were not laid out – only implied. The text has been reorganized to make it more obvious in rev.4. RPs have always been required to do the validation of the assertions, manage any sign-in keys they had, process things in a particular context/way (i.e., expired assertions), etc. All of this was already there it was just woven in a way that was not as obvious. This is one of the document structural changes NIST made a point to correct in this revision.
The importance from NIST’s perspective is that the requirements on the RPs are explicit and clear because there is the supposition that the vast majority of the trust lays with the IDP/CSP and not as much on the RP. NIST wanted to emphasize that there is a very critical role that the RP is playing and it needs to be done to a well-defined approach. Making sure those were clear was essential. Very specific to federal RPs and other organizations that choose to use this guidance that there is an expectation to do certain things and maintain certain expectations within the federation process. This is not an unprecedented thing – in the PKI world it is very common within a certificate policy for the template to lay out the responsibilities of the RPs there.
With the UK, EU, and Australia they managed to throw out anything to do with RPs because everything was protected by the data protection regulations which apply to everybody. The requirements set in those were relevant in those cases. At that stage that it did make sense to have some things about RPs for the U.S. because there were other RPs who would be coming along later who would be expected to do things that would not necessarily be covered automatically under the current U.S. approach to data protection. This is an unusual stance but never the less does make sense in this context.
In any conformity assessment program, you have to make decisions around what the scope is going to be for the different programs. In terms of performing an assessment, it doesn’t matter if it is a CSP or an RP. There is a set of requirements that are assessed and either they are being met – or not. The problem potentially with RPs is that if it’s a large community, how long will it take? How complex does that make it? How does one even manage the logistics? Do we end up with RPs entering into separate agreements? Or a blanket agreement? None of this is really NIST’s responsibility to answer but they will be the principal consideration when Kantara moves forward.
Equity
Is it correct in saying, from an equity perspective, that if a RP that requires all applicants to have a picture ID, that would be acceptable under the current rev.4?
Look to the trust agreements that those RPs enter into to see the level of specificity for requirements in order for authentication transactions to be asserted. As well as any accompanying information about the IALs or AAL performance that was conducted in order to participate in the federation arranged.
It’s more nuanced/complicated than that. A few elements were highlighted – one related to transparency. But more so, related to optionality. Example: A single RP and their function within the context of a broader service is limited to the scenario described above – but the broader service offers options, and conducts an impact assessment, and evaluates all the different risks – then that is the relevant portion and context that would come into play.
To extend the question, if that impact assessment occurs and it is resolved that requiring every applicant to have a picture ID meets all the equity and risk criteria – can I require that and conform? Commercial entities may have done that evaluation. For the population of applicants that they serve, they believe that they do not want to serve anybody that does not have a qualifying picture ID. Could that still conform to 800-63?
It’s not simply about having an image. There are steps in the ID proofing process – one that may be capturing/validating a document with an image and one may be verifying that – but it’s not as simple as asking for an image and now I’m conformant. There is a set of processes within 800-63a that lays out what evidence you are collecting, how you are validating it, how you are verifying it and how you are executing the whole process end to end. If that process is conformant and has been evaluated for the impacts of that process on the end user population to determine that there will not be any equity or substantial negative impacts – then you will have aligned with the guidance.
From a federal perspective, NIST is trying to create the ability for an agency to evaluate, assess, and implement their ID proofing and validation/verification processes consistent with their security risk and the potential risk and impacts with the end users. If agencies choose to modify or move away from a specific piece of identity evidence because of the risk to equity – it is reasonable. It needs to be documented and an understanding of the risks associated with it. Then they make that risk-based decision.
What does NIST mean by the term equity? Equality of access to services? Is there a main sense in the definition of equity that everything is based on? It’s a broad term with subtle meanings.
The way NIST has been thinking about equity is really focused on outcomes across groups. Any activities, treatments, or accommodations required to achieve parity across outcomes. That is the big picture definition. There is a very specific definition provided through Executive Order 13985 – “consistent and systematic fair, just, and impartial treatment of all individuals, including individuals who belong to underserved communities that have been denied such treatment, such as Black, Latino, and Indigenous and Native American persons, Asian Americans and Pacific Islanders and other persons of color; members of religious minorities; lesbian, gay, bisexual, transgender, and queer (LGBTQ+) persons; persons with disabilities; persons who live in rural areas; and persons otherwise adversely affected by persistent poverty or inequality.” Consult the definition that is included in the base volume of revision 4 draft where NIST basically cites the EO referenced above. That is what NIST conforms to.
Big picture is focused on issues around access and accessibility. Accessibility is one lens, but security should be looked at as something that everybody should have access too. Privacy as well. Usability. There are different treatments and then there are outcomes. Both of them have a role in the conversation around equity.
NIST isn’t making up what equity is. This is based on defined outcomes and goals set forth by the federal government with certain larger objectives attached to them. Each of the volumes has equity as a concept. And each volume looks through the lens of the processes appropriate. Then make that a more granular/implementable way of looking at it to facilitate the providers being able to understand the concepts and the intentions of equity applicable to their particular services. It’s very specific. In many of these processes, one can point to traditional inequities and inequitable outcomes, treatments and access. There are examples of certain outcomes or certain treatments that varies to the determent to certain groups. NIST is trying to level the playing field.
NIST is trying to take a practical and pragmatic approach. They know differences in performance within different groups are likely to happen. They are nearly impossible to eliminate. They’re asking agencies & organizations to actively evaluate, understand, assess and mitigate to the greatest degree possible those issues when they are identified. Previously people played by set it and forget it – and if a population couldn’t get through it was unlikely to even be identified because orgs weren’t going out of their way to do the assessment and determine those impacts and offer alternative pathways or mechanisms for id proofing (trusted referees). Making sure there are options presented to the user that still fit within the risk posture of orgs and entities doing the access management.
Risk
Are there any particular risks that an applicant’s reference takes on when they act as a reference for some other applicant – pertaining to the new concept of an applicant reference in 63a?
An applicant’s reference in 63a is used to help assist the id proofing for individuals who would otherwise have difficulty in meeting the process or technical requirements for id proofing. The applicant references are required to be id proofed because for information that they may provide or may even vouch for the applicant in the id proofing process needs to be trusted. So, the requirement in 63a is that they are id proofed at the IAL of the applicant – or higher.
NIST doesn’t apply any risks to the applicant reference in the documentation. It is fair question and something that NIST needs to think about as far as how the role of the applicant reference is conveyed to the applicant reference. (i.e. If you vouch for this person, but this person turns around and commits fraud, you may be contacted.) It’s a valid point to make sure that within that section NIST illuminates that if there is a risk to the applicant reference, it is at least conveyed to them. What that risk is is dependent on the application, the transaction, etc. from a legal perspective which would be slightly beyond what could go in the guidance itself.