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