Should including the `acr` value be optional?

[gffletch]

Currently the proposed SL1 draft in section 3.3.1 states:

shall contain acr claim as a string that identifies the Authentication Context Class that the authentication performed satisfied, as described in Section 2 of [OpenID];

The allowed values for the acr claim are defined this IANA Registry

There is no value for "simple authentication"? Are we requiring all IDPs to at least do an phr level of authentication?

[dhs-BI]

Good catch, @gffletch.

I read the levels again and they do not refer to anything other than the identity services enforcing MFA and communicating and acr claim to the app. A quick review of the IANA registry indicates that we might not have the right set of values to meet the requirement at SL1.

@aaronpk and I discussed this morning and will queue this issue up for the next call to find a path forward.

[mcguinness]

https://refeds.org/profile/mfa is already registered as a "mfa any" type of class.

The open question to me is whether we want/need to define a new class that allows any AAL2 set of authenticators. IIRC AAL2 doesn't strictly require phishing resistance.

My take is by the time IPSIE is finalized and adoption cycles play out, most enterprises that care enough to ask for IPSIE compliant deployments would already have rolled out a phr level of authenticator for their users due to the change in threat landscape and wide availability of phr solutions in the market. The ROI of getting broad adoption of a non-phishing resistant ACR is questionable.

I would support phr as the minimum supported acr for IPSIE SL1 as this is the new standard for the enterprise and is RECOMMENDED for AAL2 is most recent 800-63B draft.

Would love to hear from others as well.

[dhs-BI]

Thanks for catching the REFEDS mfa claim @mcguinness.

Binding this to AAL2 is dangerous IMHO, since AAL2 can and will change over time. For example, see the update to allow for synced passkeys at AAL2.

I would not recommend phr as the minimum value since orgs have struggled to roll out phishing resistant authentication. RPs can require phr at SL2, SL1 should allow for more open ended MFA mechanisms.

I look forward to discussing further next week.

[Tom-MITRE]

AAL2 baseline is meaningless. The baseline xALs are intended to be tailored in Digital Identity Risk Management process (800-63).
In USG, policy tailors AAL2 for public-facing apps is "must offer a phr option" (M-22-09). For defense industrial base, it's "replay resistant" MFA (800-171), and for USG enterprise, it's "mandatory enforcement of phr" (M-22-09/FISMA CIO metrics). All AAL3 is phrh, but can be further tailored...

[sbroddy]

FWIW, the referenced REFEDS MFA profile(s) are actively being worked on to update for prMFA.

https://wiki.refeds.org/display/GROUPS/MFA+Subgroup