Consultation: MFA Profile v2.0

"In general terms, multi-factor authentication refers to the use of an additional, non-password challenge included as part of login, typically in combination with a password".

I think the use of 'additional' is a bit confusing. Additional to what? In section 3.1, it says any two or more factors. 

So maybe → "In general terms, multi-factor authentication refers to the use of multiple distinct factors during login, often a password in combination with another factor"

#3 - I think it would be useful for the longevity of this specification and to aid in the current transition away from passwords if the specification didn't mention "passwords" as being "generally" part of the authentication, how it reads to me now it guides the implementer towards the idea of an MFA to be used after the use of password in the authentication flow. This to promote and highlight the use of "Something the user is"/"Something the user knows" to be used in combination with "Something the user has" to complete the requirements in one step instead of two (pin or biometric to unlock the Passkey in the same authentication flow). This is probably the better user experience and promotes the use of "Something the user has" as the first and default factor. For example:

• Multi-factor authentication refers to the use of challenges of two different types as part of login. This could happen sequentially as one challenge being completed, followed by a second challenge of a different type, or combined as one challenge that completes the requirements for a multi-factor authentication because it includes the use of two types of factors. 

#3.2, 129 & 130

The requirement for the factors independence while novel will in practice be more difficult to navigate since login managers (i.e. password managers) now create and host both Passwords and Passkeys. Would it make sense for it be changed to Should for general MFA, and Must for phising resistent MFA?

#3.5 and how it relates to 3.3 & 4.2.4

Would it be worth considering that SSO cannot be utilized for instances requiring Phising-Resistent MFA (preventing a third party using the users signaled Phising resistent SSO)?

When asking for PHR a service provider Should also signal to re-authenticate, before signaling PHR the identity provider Should re-authenticate the user using their phising resistent factor at a minimum

Regarding Section 3.5, Phishing-Resistant MFA, the text states:

"MUST NOT rely on authentication secrets (e.g., passwords, one-time codes, or challenges) that a remote attacker could capture, replay, or instruct the user to reveal."

Could this phrasing be clarified? Strictly speaking, no system is entirely devoid of secrets. Even with FIDO/WebAuthn or Passkeys, cryptographic secrets exist and could (at least theoretically) be compromised, especially when using platform authenticators or password managers with synchronization features. Is the intention here to specifically exclude secrets that are accessible to or revealable by the user, rather than the underlying cryptographic keys?

Guide 55-56
"If the IdP cannot meet those requirements, it must return a protocol-appropriate error indicating"
that the requested authentication context was not satisfied
   Problematic to make that a "must". If the IdP hands off the user for PHR, they may not get them back to be able to return that error.

Lines 59-62 state it correctly:
"If the authentication event did not meet the requirements of either General MFA or
Phishing-Resistant MFA, and the SP requested one of them, the IdP must not assert either
signal and should return a protocol-appropriate error indicating that the requested authentication
context was not satisfied."

So 55-56 seem to conflict with 59-62, unless 55-56 are meant for an IdP that cannot satisfy PHR for anyone -- and if so, that should be stated.

I'd say taht 74-78 have the same problem (i.e. MUST on returning an error), although there is wiggle room with 75-76 -- if the IdP hands the user off to a MFA serv ice that does not end up returning the suer, then one could claim the IdP "followed the path of 75-76 by at least "attempting to re-authenticate the user at the right strength".

In general, it can be problematic to have MUSTs around returning an error meessage, because if you are handing off the user, from the IdP, to another service (e.g. Duo), you may or may not "get the user back", If you don't, you cannot return the error message to the SP, you simply never return the user to the SP.

"IdPs and SPs should consider publishing an errorURL in their SAML metadata, as defined in
the SAML V2.0 Metadata Deployment Profile for errorURL [ErrorURL] . "

  What errorURL for an SP? And did I just miss it, or is a reference for [ErrorURL] missing?

This sentence is a bit awkward. How about?:

The authentication strength identifier asserted by an IdP/OP must both reflect the authentication method(s) actually performed during the session and comply with any values requested by the SP.

or

The IdP/OP must assert an authentication strength identifier that reflects the authentication method(s) actually performed during the session, subject to any constraints expressed by the SP.

You might want to revise the word "identifier" to something else as discussed earlier.