...

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

...