MFA flow with TOTP plugin

[Cantor, Scott]

The supportedPrincipals values look kosher, and so there is absolutely no way that Password running alone could return TimeSyncToken unless you deliberately manipulated something in code to alter things. If it reported TimeSyncToken, it ran a flow that produced a final Subject at the end that contains that Principal.

Basically this is flat out impossible without deliberate subversion:
" If I add a "RelyingPartyByName" override to relying-party.xml, specifying "defaultAuthenticationMethods" as ...TimeSyncToken for selected SPs, then that's what's always reported to those SPs, even if TOTP wasn't used."

It is the case that you cannot have the SP request PPT or configure the IdP to act like the SP requested PPT and ever get anything but PPT or an error.That is dictated by the standard. So no, that's impossible to end up with TST in that case, but you should never need to have an SP request PPT so it doesn't matter.

If the SP requests TOTP or a relying party rule says TOTP, it should get TOTP and that's all that should matter. But it will not get that if the IdP didn't run a flow producing a Subject with a TOTP context class principal.

Perhaps you have XML lying around from pre-4.1 days with different settings for the flows.

The default for Password and TOTP will be to populate the Subject with exactly what is claimed as supported, so it's automatic, and the MFA flow will just merge everything. You can't get TOTP out in that scenario without running TOTP then or during an earlier request, it's really that clear cut.

-- Scott