Add biometric acr_values for OIDC protocol

[Sgtpluck]

🎫 Ticket

https://gitlab.login.gov/lg-people/lg-people-appdev/Melba/backlog-fy24/-/issues/43

This change builds off the changes in #10948

🛠 Summary of changes

This is the initial work to replace our public-facing Vectors of Trust (VOT) API interface(s) with acr_values. This work is focused on the OIDC implementation; we will follow up with whatever changes we need to make for SAML in the next week.

This change:

• Maintains the current VoT implementation and API for current SPs
• Adds support for selecting proofing with biometric comparison using new Authentication Context Class Reference values (ACR values) in our OIDC API
• Does not change other ACR implementations

📜 Testing Plan

Acceptance testing detailed here
Release plan details here

[zachmargolis]

wait can't we do this?

Suggested change

	result.
	component_values.
	map(&:name).
	include?(Saml::Idp::Constants::IAL2_BIO_REQUIRED_AUTHN_CONTEXT_CLASSREF)
	result.biometric_comparison?

[zachmargolis]

and if not, maybe we need to split into result.biometric_requested? vs result.biometric_required? (could be a follow-up but my expectation is that the point of the result class is to define capabiltiies so we don't have to check for specific ACRs throughout the codebase)

[Sgtpluck]

we definitely could do something like that! the initial implementation did add a biometric_comparison_required, but hooper thought that was a little confusing as someone trying to work downstream with the code. but maybe requested vs required would be clearer? what do you think?

[Sgtpluck]

the reason we need both is because we need a way to "fall back" onto our base identity proofing for partners who don't want to force their users to go through it again.

[zachmargolis]

yeah I think the fact that this PR defines biometric_is_required? means definitely we need a way to distinguish, so I would vote to rename the existing one, so yes there are both required + requested, but that could def be a candidate for a separate PR to keep this one focused

[Sgtpluck]

okay yeah -- i can add this thought to the SAML implementation ticket (which, work on that can start as soon as this is merged in), since i think there won't be a ton of work in that, so it can focus a little more on optimizations like this.

[vrajmohan]

Some minor comments, all to do with tests.

[vrajmohan]

When does this case arise?

[Sgtpluck]

if you trace the self.no_sp_result method back in the Vot::Parser, you can find this PR that explains it better #10092 but basically some requests don't include service provider details.

[vrajmohan]

Isn't the context really "when an IAL without identity proofing is requested"?

[Sgtpluck]

the context is that the requested IAL ACR value takes precedence. but happy to change it to your wording if that's helpful

[Sgtpluck]

actually, looking at the rest of the context blocks within this one, i think that this is correct. we do include a test for when identity proofing is requested, so i am going to leave it as-is

[vrajmohan]

I find this expectation surprising. Don't we only support aal2's? Requesting no AAL results in an aal1?

[Sgtpluck]

we require aal2 for identity proofing. for ial1 we only require MFA, which is not aal2. https://developers.login.gov/oidc/authorization/#aal_values

[Sgtpluck]

(also this test includes aal/1 as part of the request, if you look at the acr_values fixture)