...
| comment # | Line/Reference # | Proposed Change or Query | Proposer / Affiliation | Action / Decision (please leave blank) |
|---|---|---|---|---|
| 1 | 4.3 Validity Lifetime | Setting 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 days | Peter Havekes / SURF | |
| 2 | 5.1.3.3 ForceAuthn | There are use cases where a user must always preform MFA authentication. Examples are
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 | |
| 3 | Section 4.1, line 60-61 | Redaction is a bit ambiguous. My reading of it is that it disallows using two factors of the same kind (i.e. two passwords of different providers, thus disallowing solutions like alternative e-mail OTP), but would allow authentications with a single step that ensures the conditions of more than one type (i.e. certificate authentication with a smartcard, which both entails having the card and knowing the card PIN). Proposal: add a "Guidance" section further developing which interpretations of the section are right, which are not, and which are close to the grey zone. Maybe also include practical examples? | Francisco Aragó / RedIRIS | |
| 4 | Section 5.1.3.4 | This section hints that if a SP requests refeds/mfa in the authnContextClassRef, and only this one (as recommended in section 5.1.3.1), if the IdP cannot satisfy conditions of section 4.1 in the authentication, it must return a failure state and never a successful response. Also, the profile does not specify how the SP should verify that the requirement has been met: by the presence of the refeds/mfa classref on the response or implicitly by the fact of the response being successful?. If it's the second case, it renders the signalling of the refeds/mfa ClassRef on the response mostly superfluous; if it's the first case, the fact of forcing an error response (instead of allowing a response without the refeds/mfa classref signal) rules out the possibility to implement a proxy use case where the principal has different factors enrolled on the IdP (refeds/mfa compliant, can be accessed independently other than from the proxy) and on the proxy, and can choose between providing the second factor at the IdP (in which case the response will already be refeds/mfa compliant) or at the proxy (in which case, the IdP would have to fail for not being able to satisfy refeds/mfa context, as the IdP is standalone refeds mfa compliant). Proposal: state clearly if this is the expected behaviour (and that the exposed proxy scenario should not be supported), or otherwise clarify that not satisfying conditions of section 4.1 is not a cause for response failure, but only to NOT signal the refeds/mfa authnContextClassRef on the successful response, leaving the SP to check that the response did not fulfill the conditions and allow it to act accordingly. | Francisco Aragó / RedIRIS | |
| 5 | Introduction, lines 31-37 | The issue here is not really about intra- vs. inter-organizational MFA signalling, but rather about deviation from this profile. I suggest rewording to something like "Deployments of this Profile must adhere strictly to its requirements and cannot override them with local policy requirements. Because this Profile cannot anticipate unique organisational authentication practices and nuances, it is strongly recommended not to use the value defined in this Profile to meet local MFA request/response needs." | David Walker / InCommon | |
| 6 | Not present | Due to that some commercial Identity Provider softwares, for example ADFS, is handling not known authentication context classes very bad or even breaks the log in flow with a software error it would be good to add an indication that this Identity Provider is techhnically capable of handling the REFEDS MFA authntication class signaling, or the other way around. An entiy support category sound wrong but it may be the best fit. | Pål Axelsson / Sunet | |
| 7 | 4.1 Multiple Factors, lines 59 - 63 | The EU Revised Directive on Payment Services (PSD2) Strong Customer Authentication requirement has an elegant definition of MFA. Suggest we adopt that text: Ref: Wikipedia article on Strong Customer Authentication | Albert Wu / InCommon | |
| 8 | 5.1.3.3 | In section 4.1 it is stated that when loging in the user must use a combination of at least two factors when authentication. This means that under section 5.1.3.3 it must the full authentication even in the case of a forced authentication. That ForceAuthn is unspecified in SAML is irrelavant for the section. | Pål Axelsson / Sunet |