<div dir="ltr">Thanks a lot Scott. I think I got it working, using the document you referenced:<div><br></div><div><a href="https://shibboleth.atlassian.net/wiki/spaces/KB/pages/1474297850/Supporting+the+REFEDS+MFA+Profile">https://shibboleth.atlassian.net/wiki/spaces/KB/pages/1474297850/Supporting+the+REFEDS+MFA+Profile</a></div><div><br></div><div><br><div><br></div><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 1, 2023 at 1:25 PM Cantor, Scott via users <<a href="mailto:users@shibboleth.net">users@shibboleth.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Conceptually, the point is...you want the IdP to decide whether to reuse the previous result(s) based on whether they already meet the SP's requirements, and if not, run the flow and then decide within the flow whether to run Duo based on whether the Password result meets the requirements or not.<br>
<br>
None of this is based on the service, it's based on the requirements for authentication policy that may apply to any service.<br>
<br>
The shipped examples already illustrate this (with IPAddress and Password instead of Password and Duo).<br>
<br>
See also, the HowTo article in the KB about supporting REFEDS MFA.<br>
<br>
Things are only complex if you also have to take into consideration other factors such as the user or a group the user is in. That requires more complex scripting but you start from the baseline.<br>
<br>
-- Scott<br>
<br>
<br>
-- <br>
For Consortium Member technical support, see <a href="https://shibboleth.atlassian.net/wiki/x/ZYEpPw" rel="noreferrer" target="_blank">https://shibboleth.atlassian.net/wiki/x/ZYEpPw</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a><br>
</blockquote></div>