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