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.

**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?

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 3^rd 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.

Kantara does not have any FAL approvals. For CSPS and assessors, does this revision 4 draft make the path easier to certification? Will CSPs become more likely to want to be certified for 63C now?

Kantara had to formally invent/define federation agreement and federation authority to make the current KIAF-1450 requirements in order to have something that could implemented and able to be assessed. With rev. 4 now formally addressing both of those concepts, it makes it easier/better to determine if an organization aligns. Individual organizations will need to have internal discussions if they conform and if not, what can be changed to conform.

NIST tried to ensure that the requirements that are included would cover both the large-scale formal federations (InCommon) as well as the much more dynamic point-to-point federations (logging into a new website where my IDP has never seen). When NIST says federation, they are talking about the use of federation protocols to convey authentication and attribute information about the subject to the RP. That is hopefully clear from the introductory text in both the base volume and 63c. In that narrow definition of federation, that pulls in that trust agreement, federation agreement, federation operators – and other types of things to make that happen. Fundamentally, when NIST talks about federation they are talking about a connection/conveyance of information. It is fully intended to spread across all of those different use cases – not just the formal ones.

Final note on federation from NIST:

There is also SP 800-217 (Draft) Guidelines for Personal Identity Verification (PIV) Federation out for public comment right now which is federation in the context of PIV - particularly driven PIV. NIST is also soliciting comments on that. It might be useful to look at in terms of a use case to which 63c applies.

Equity & Risk

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.

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.

63A

In 63a rev.4 we see IAL1 and IAL2 both calling for one FAIR piece of evidence and one STRONG piece of evidence. Then verification is the differentiator. What was the thinking around having the evidentiary requirements the same but the verification different between IAL1 and IAL2?

The evidence requirements for IAL1 and IAL2 allow for a presentation of the STRONG piece of evidence with one piece of FAIR evidence, which present requirements for an additive control at both levels that make it more difficult for an attacker to be able to subvert the id proofing process. NIST recognizes that in 63a that the concept of core attributes that are required for id proofing that need to be validated so that the id proofing process represents the additive value of evidence presentation along with core attributes validation in order to get to the point where id verification combined that evidence as well as attributes to the real life person in the application and id proofing process.

NIST is still seeking feedback on IAL1. They are pretty happy with where it is at – but if there is concerns or specific modifications that CSPs have as far as recommendations – it is new to the workflow. NIST is very much open to direct feedback on where NIST sits with IAL1.

Do you see the direction that the current draft is right now giving agencies the risk assessment to determine their appropriate IAL? Do you see IAL1 really being more applicable to some of the lower risk applications? And really focusing on taking away the need for the selfie-match or the biometric matching and being able to meet some of the more equitable requirements given that is one thing known as impacting equity?

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. Agencies will be the ones who decide their own risk tolerance. What NIST was trying to do was to give 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.

Sometimes there will be direct tradeoffs between security and equity objectives, but that will not always be the case. NIST wants to directly address that and say there is an unfortunate missed opportunity in thinking of this as a zero-sum game where we could be very creative and achieve both objectives simultaneously. Maybe the tradeoff is cost if you are engaging in a campaign to offset the cost for tokens for certain populations that are eligible - or to develop materials in multiple languages that will ultimately help everyone achieve security objectives. It’s one thing people just assume but NIST encourages everyone to think more creatively on how these objectives interact with one another to be achieved.

Rev.4 is really more outcome based rather than prescriptive. That’s the difference being noticed. Puts more onus on the agencies. One of the key things CSPs are seeing and having to talk through is the challenge of not being spoon-fed the requirements. It’s a new level of measuring that hasn’t been there previously. That’s not a strong point for agencies. It might warrant additional guidance and ways to measure these outcomes that agencies must have and publish. NIST requests thoughts on how to bridge the gap between setting outcomes and then how to achieve them – beyond 63 itself and other PIV related guidance.

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 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.

NIST presents characteristics for evidence in a new section of 63a. NIST requests particular comments that Kantara/assessors would make to that new section. NIST is trying to be more explicit and list the determination of whether evidence that is being presented can be accepted. That’s the purpose of that section. NSIT welcomes review and comment on that.

NIST has heard already in feedback to better align the assurance levels to the specific threats for risk that they are intended to mitigate. Seems close to what is suggested above. If you selected IAL2 and are implementing the controls as laid out in IAL2, here are the common sets of threats and risks that we have designed to help mitigate. NIST is trying to figure out how to do that – they have some ideas – but they’d’ take recommendations on how to structure that.

We have two types of CSPs– Identity verification companies approved at IAL and then Full CSPs that offer both IAL and AAL. Can an ID proofing company exist as a stand-alone service offering and actually provide services that conform to 800-63-3 Volume A? Or does an ID proofing company always have to be paired up with an authenticator provider to become the CSP? If an agency requires proof of legal name and they ask for evidence to a certain degree, there doesn’t necessarily have to be an authenticator in play.

There is no reason that the agency/organization may or may not act as the authentication component of that. And then the full CSP set of services would be whoever is offering that authentication plus whoever is offering that identity proofing service. It’s a reasonable criticism in that many of the requirements are targeted toward a structure called a CSP – when in practice, that CSP may be a number of different conglomerations of different subservices and sub-capabilities. It gets hard for NIST to try and break those down too far – simply because of the potential combinations, but if you are packaging just the ID proofing component of what would fit into a larger CSP – whether that is run by another 3^rd party or the agency/organization – it can easily be determined what falls within the scope of the ID proofing services offered by the organization to be assessed and evaluated.

NIST does not specify how any assessing organization or certifying organization requires conformance. NIST deliberately tries to allow for componentization of services that are described across the volumes. By separating the volumes, NIST recognized that they are addressing different components in the overall identity management for an identity service. But, NIST’s purpose was to be able to allow for components to address the requirements however those components are arranged in an overall identity service.

Still the option to permit the scanning of identity evidence or do a live capture. Based on what we are seeing on the fraud/threat landscape, it may make sense to not permit scanning of identity evidence for anything above FAIR because of the threat of replay. Thoughts on that topic?

There is a line that currently exists that mandates the physical validation of fair evidence – which NIST plans to remove. It was intended to be removed to begin with. There is not an expectation for someone to take a picture of their printed-out bank statement, scan it, and send it to someone. That is not what NIST is expecting from a FAIR evidence perspective. Once that line is removed, the concern hopefully disappears.

Beyond FAIR, NIST welcomes comments on that topic. There are current discussions happening about what is live document validation and the capabilities needed to validate live capture of the actual document.

Has there been any consideration for the opportunity to validate the core attributes and then apply a probabilistic approach in terms of advanced analytics that would create a likelihood similar to the way we look at the likelihood of the match of the biometrics in 63b? But more around the actual identity itself. The identity is not stolen – and validate that through some measurement. Has that been something NIST has actively discussed or considered being open to?

 Yes, something NIST has been exploring. Looking for pathways to better understand - typically some type of score/threshold is established that gives sufficient confidence to say that everything does equal a positive outcome. In reality, probabilistic processes are occurring, they are just not as measured or standardized as some of the things done for biometrics. NIST is open to feedback. They are also actively doing work to explore what can standardized, what can’t be standardized, how can it be tested? However, for the most part, such probabilistic efforts are highly proprietary right now. Figuring out standardized common ways to evaluate and understand them is going to take some time. There are also challenges from the perspective that the tools will require evaluating PII and real data that is fraudulent or has been used for synthetic attacks. There are a lot of challenges and complexities with putting together a project to evaluate them. But NIST is actively exploring it.

 Less about the proprietary things that go into the algorithm – it’s more about how the algorithm performs. And how that can be standardized and measured. The challenge becomes the thresholds of what is and is not acceptable (i.e., 90%? 85%? 30%?) and what does that look like. NIST can’t say whether this will be for rev.4 or something that comes after rev.4.

When biometrics or other PII is used for proofing, an agency may or may not record all of those details. They may just make a decision and record a decision. In 63A, if an agency were going to record all of those details – or not – is there something the agency needs to do to justify the recording or to clarify why they are not doing that? How is that backend capture of proofing PII handled from a 63A perspective? What level of additional risk are they taking on by not capturing any of that data?

NIST directed review of the privacy risk assessment requirements in 63A. For ID proofing purposes, if the identity service collects, uses, retains PII the rev 4 draft specifies that a privacy risk assessment is performed for that capability. Also, directed review to the use of biometrics section. While biometrics is a form of PII, there are additional requirements for the collection of biometrics that requires a specific notice for the collection, use, retention, or deletion of biometrics information – and also consent. Similar to any piece of PII that would be collected, used, processed, and retained - there is privacy risk assessment completed that would indicate the capability for the user to access that information and request deletion of biometric PII.

 NIST feels that is context specific. NIST can put out guidance but there is a part of the policy and legal landscape of a given jurisdiction that is beyond NIST’s scope. In the federal space, there are laws and policy in place. NIST is not regulatory, they provide guidance. In the U.S. there is going to be a pathway of floors and ceilings from a policy perspective that NIST is working within. This is why focusing on outcomes and impacts and driving towards those types of questions rather than a checkbox approach is desirable.

 NIST defers to regulatory policy in place. There is not an easy minimum that NIST can set for mandating what information is captured, what is stored, what is retained, and for how long. NIST understands the question but there isn’t a foreseeable point where NIST will provide these guidelines.

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.

It is organized the way it is in order to offer that componentization – to create some separation between the roles in the proofing process versus the roles in managing the authenticator. If there is something unclear about how it is laid out, please include that in the comments. NIST is open to ideas on the requirements themselves and also clarifications within the document itself.

Has NIST considered that binding might include an actual agreement? Some text talks about authenticator binding as creating an association between the authenticator and the account. It implies that there is an agreement that legally binds the two parties together. But, it isn’t explicit. Is it necessary to call it out?

NIST tends to focus on the technical means. There is sort of a half agreement in the sense that it is up to the CSP what types of authenticators they want to allow. There is a whole menu of different types of MF authenticators, especially if you count the ones that are not phishing resistant, that are described in the guidance. But there is no obligation on part of the CSP to provide any particular type of authenticator - other than maybe indirectly in terms of what types of authenticators are required to meet equity/usability requirements.

When NIST talks about binding, it’s adding that new authenticator. Any kind of agreement would be part of the account establishment/enrollment process and the notice/consent with the user registering for the service. It doesn’t’ seem like adding an authenticator would change that legal agreement in any way. Again, if NIST is missing something, please note it in the comments and/or provide recommendations.  

An issue with providing multiple credentials is that if they are only used for account recovery, then chances are the individual is likely going to get confused (i.e. can’t find the credential). There is another alternative, which is to periodically verify that the additional credential is usable. Does that play a role in any form in this improvement of the recovery process in rev 4?

Not at this point. There is no requirement for this. What NIST is talking about is adding additional authentication mechanisms for the individual to use (i.e., phone for SMS, a YubiKey around the house, and backup code in a drawer). NIST already does require someone to prove they can use it in order to enroll it. True for both the post-enrollment binding but also a topic for bound authenticators for FAL3 – they follow a similar pattern when it’s self-service.

The notion that occasionally asking someone to use a particular authenticator is impractical. (i.e., One may have multiple YubiKeys in different locations. If a specific YubiKey is being requested when you aren’t in the same location as that specific authenticator, you are stuck). There are a lot of usability considerations to what seems like a fairly straightforward security and robustness check.

Account recovery is hard. One of the reasons why SMS based recovery ends up being common is that it is something that tends to follow you between different devices. From a long-term perspective, this is certainly something that needs addressed – usability challenges around account recovery is a good topic. But there are no normative requirements along those lines.