Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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.

Authenticator Binding

There is binding at enrollment and then post-enrollment binding. Is the description of the boundary of enthrallment in the draft? 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.