Authentication Context Reference (ACR) implementation does not follow standard practices

[cbertagnolli]

The Authentication Context Reference processing does not appear to follow standard or common practices during our implementation. We've tried various combinations to implement auth context step-up for AAL2, AAL2 Phishing Resistant, and HSPD12 as these all have unique access control requirements within the applications, but do not get back proper ACR handling or AAL values (it enforces the AAL but doesn't assert it back as what we sent).

For OIDC, it only returns the matched IAL, regardless of AAL match first in preference order. This means I have no way to send and verify the ACR meets my expected authentication context.

IAL is not a context of the auth event itself and shouldn't be the primary asserted value.

If IAL and AAL are intended to be in buckets of conditions, then those should be in joined ACR contexts. Authentication Context Reference does not mean "the log in will meet ALL these conditions", it should be "the log in will meet at least one of these contexts in the preferred order sent by the app and returned with a single value at first match".

The same is true for SAML as well. Login.gov requires sending multiple contexts, but that's not what "exact" comparison means nor common use. It means "meets at least one exactly in preference order" not "meets exactly all conditions". So app sends list 1, 2, 3 and gets back a single value of the context met from that list in order to make an access decision.

Combining IAL + AAL as separate "conditions" does not meet the intent of ACR. That should be handled via separate request like a claims challenge.

ACR should be all about the context of the auth event and if IAL is part of that calculation as a signal should still be a single "context" that encompasses both so that as an application we can properly send and verify one to one without further interrogations of disparate claims.

Example request / responses:

(1)
http://idmanagement.gov/ns/assurance/aal/2?hspd12=true+http://idmanagement.gov/ns/assurance/ial/2

This is accepted and user is forced to use a PIV/CAC. However, the returned token and UserInfo response does not match the request.

"ial":"http://idmanagement.gov/ns/assurance/ial/2", <-- Correct

"aal":"http://idmanagement.gov/ns/assurance/aal/2", <-- Incorrect. My request was not just AAL2 but AAL2?HSPD12=true which was enforced but not asserted back.

"acr":"http://idmanagement.gov/ns/assurance/ial/2" <-- Incorrect'ish if executed in preference order as AAL was first and "met" but IAL returned.

(2)
http://idmanagement.gov/ns/assurance/aal/2?phishing_resistant=true+http://idmanagement.gov/ns/assurance/ial/2

Logged in via Smartcard or Security Key.

"ial":"http://idmanagement.gov/ns/assurance/ial/2", <-- Correct

"aal":"http://idmanagement.gov/ns/assurance/aal/2", <-- Incorrect. My request was not just AAL2 but AAL2?phishing_resistant=true which was enforced but not asserted back.

"acr":"http://idmanagement.gov/ns/assurance/ial/2" <-- Incorrect'ish if executed in preference order as AAL was first and "met" but IAL returned.

(3)
Sending an unknown AAL doesn't fail since Login.gov only asserts back IAL into ACR? When I send an unknown AAL, the asserted aal claim back is the "30 day" PasswordProtectedTransport, but the default I have is the "AAL2" 12 hour one...

Using a bad unknown AAL but good IAL acr_values=http://idmanagement.gov/ns/assurance/aal/jajaja+http://idmanagement.gov/ns/assurance/ial/2

Default context set on application is "AAL2" which is supposed to be 12 hour browser save per the documentation. But what I get back is:

"aal":"urn:gov:gsa:ac:classes:sp:PasswordProtectedTransport:duo", <-- this per the doc is 30 days save "AAL1" (even though 2 but saves for 30 days).

"acr":"http://idmanagement.gov/ns/assurance/ial/2" <-- again, IAL is the ACR since it seems regardless of AAL it ties ACR to IAL.

[gitmijn]

Hello! Thank you for providing this detailed write-up of the issue. We have prioritized solving this issue and our engineers are currently working on a solution for it.