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