These are FAQ items discussed by the MFA subgroup for possible addition to the FAQ or a future reworking of that document.
Is the REFEDS Profile Suitable for Internal/Enterprise Use?
It is, but this is a poor chocie in most cases because it ties internal practices to an externally-imposed definition that may create problems down the road. Within the enterprise, there can be constraints on MFA usage due to issues such as a need to fail open during outages, special treatment for VIPs, very long "Remember Me" bypass policies with solutions like Duo, and so on. Maintaining flexibility is usually paramount, while federated interoperability requires more strict adherence to externally defined rules.
Serving both ends is difficult or impossible with a single <AuthnContextClassRef>, so the advisable course is to create a local value in the organization's own URL namespace and use that value when interacting with internal or contracted services, reserving support for the REFEDS MFA profile value for federated use. While in many cases this may be trivial because they may be handled identically by the IdP, having the second value allows them to be treated differently if they have to be.
How Should "Exceptions" to MFA Policy be Handled?
This is related to the previous question. It is common in an enterprise for most "rules" to be broken under all sorts of exigent circumstances when there are documented or informal processes in place to deal with them. MFA deployments are no exception to this rule. As a specific example, there are sometimes union contracts that make it impossible to impose requirements for the use of personal devices in order to carry out essential work functions, and the workarounds for this can often involve compromising on sound practices for the use of MFA to even outright exemptions to its use. Sometimes whole networks are exempted from MFA for various reasons.
These cases should genrally NOT be hidden behind the expression of the REFEDS MFA profile <AuthnContextClassRef> when issuing assertions. The kinds of give and take that exist within an organization do not scale beyond the boundaries of the systems under that enterprise's direct control. As such, it is important that the REFEDS MFA profile context class only be included when actual successful completion of MFA has occurred within a reasonable time frame. If in doubt, the value should not be asserted.
It is a direct violation of many federations' participant agreements and rules of the road to ever assert anything that an IdP operator knows to be false, and configuring support for the MFA profile context class without actually configuring the necessary controls to ensure that this is always appropriate would be such a violation.
How Recently Must MFA be Performed in Order to Comply with the REFEDS MFA Profile?
There are a number of different interacting pieces that contribute to "reuse" of authentication without constantly pestering the end user. These pieces are often used to soften the impact of broad MFA requirements in mamy deployments by compromising between requiring MFA for relatively low-value/risk systems in return for reducing the frequency with which it has to be done. Examples of these interacting pieces include SSO sessions and various solution-specific mechanisms for "skipping" MFA for some period of time after a successful use. Duo's "Remember Me" feature is a common example.
Because SSO is a largely inherent assumption of protocols like SAML or OIDC, it is understood that "MFA happened" is not necessarily an indication that it happened immediately prior to the issuing of an assertion. In most protocols, SAML included, there is a field used to signal when authentication actually happened, but even that value can be somewhat ambiguous when different factors are involved, since at best it might indicate when the most recent use of a factor happened. In most cases, this is a reasonable enough approximation that it can serve as an effective signal to applications that care about this sort of "freshness" issue, giving them the ability to control this theshold to meet their needs.
Unfortunately it is a common problem with some of the MFA solutions that their reuse features often happen in ways that don't allow the IdP software to properly distinguish whether a user actually was challenged, though this is improving a bit over time. This can lead to false claims that the time of authentication is much more recent than it actually is.
The REFEDS MFA profile does not provide any specific guidance about how long a use of MFA should last before being refreshed. It would probably seem reasonable to most people that a day is fine, but a year is not. A month? A week? That's more gray.
The only feature in SAML that can compensate for this problem is the ForceAuthn flag in requests, which itself is a long history of misuse and difficulty in specifying its exact meaning. What is most commonly understood is that the use of this flag probably should cause an IdP to force the re-execution of all the factors of authentication it would normally apply to a request and that the authentication "timestamp" in the assertion be updated to reflect this. In practice this should mean that the bypass features of particular MFA solutions be disabled for such a request, or at least detected in order to prevent ForceAuthn from being mishandled (e.g., returning an error).
However, SPs should be cautioned that relying on the ForceAuthn feature is not likely to be as interoperable as even the <RequestedAuthnContext> feature is and use of it is likely to cause problems with some IdPs.