You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

This consultation opens on 14 November 2022 and closes on 15 January 2023 at 17:00 CET.

Overview

The REFEDS MFA Profile v1.1 update, proposed by the MFA Subgroup of the REFEDS Assurance Working Group, continues our effort to make the REFEDS MFA Profile clearer and easier to adopt. With v1.1, we focused on clarifying key implementation details and making the Profile usable with multiple messaging protocols (SAML and OIDC), whilst staying true to the intent of the original Profile.

Along the way, we encountered issues that needed to be addressed, but fell outside the scope of this update. These issues are captured in an Editors' Notes for REFEDS MFA Profile v1.1 to help readers understand context and constraints of this profile. Where applicable, we also include recommendations for future actions. The Editor's Note is for reference and not part of the consultation.

Prior to this public consultation a community chat was held. The Community Chat was recorded and slides from the presentation are available.

Background

The REFEDS Multi-Factor Authentication (MFA) Profile defines a standard signal that a service provider may send to request an IdP to perform MFA during federated authentication. The IdP sends the corresponding signal in its response to indicate that MFA had occurred. The Profile also defines the criteria that an IdP must meet in order to claim successful MFA using the REFEDS MFA Profile.

The REFEDS MFA Profile is currently primarily used within SAML authentication. Its use is largely patterned from the OASIS Authentication Context for SAML.


A PDF for the consultation is available, REFEDS-MFA-Profile-v1.1-draft.pdf

Read the Editors’ Note for REFEDS MFA Profile v1.1 for additional background.

All comments should be made on consultations@lists.refeds.org or added to the comment log below, comments posted to other channels will not be included in the consultation review.

Comment Log


comment #Line/Reference #Proposed Change or QueryProposer / AffiliationAction / Decision (please leave blank)
14.3 Validity LifetimeSetting a hard limit on 12 hours isn't logical. A IdP could use different vectors (location, device, behavior) to determine if mfa is needed, and prevent MFA-fatigue by only requesting MFA when needed. When specifying a time-limit, a period greater than 24 hours is more practical, to spread the login-times over the (working) day. Proposal: Allow a maximum window of 8 daysPeter Havekes / SURF
25.1.3.3 ForceAuthnThere are use cases where a user must always preform MFA authentication. Examples are
  • SP's that require MFA on each login by policy
  • Use MFA authentication for signing a transaction, like entering a grade list

ForceAuthn is very useful in these cases.

Proposal: If both ForceAuth and an AuthnContextClassRef element containing the REFEDS MFA Profile are specified, the IdP MAY force the user to use his first factor, and MUST force the user to use his second factor.

Peter Havekes / SURF






























  • No labels