A PDF for the consultation is available, REFEDS-MFA-Profile-v1.2.pdf
All comments should be made on firstname.lastname@example.org or added to the comment log below, comments posted to other channels will not be included in the consultation review
|comment #||Line/Reference #||Proposed Change or Query||Proposer / Affiliation||Action / Decision (please leave blank)|
Section 4.2, lines 76-77
On the wiki page guiding IdP operators on REFEDS MFA ( https://wiki.refeds.org/display/PRO/Guidance+for+Identity+Provider+
Operators? ), in the section named "An SP is requesting MFA for a user. My IdP supports MFA, but the user in question has not activated or enrolled in my MFA solution. How should the IdP behave?", it says:
“Your IdP might inform the user that the resource they are attempting to access requires MFA, and they should enroll in MFA before continuing. You could then optionally trigger MFA enrollment if you have a self-service online MFA enrollment mechanism.“
Shall such initial self-registration of the second factor based solely on the first factor still be permitted under this new version of REFEDS MFA? Or is the proposed wording of the ‘Factor independence’ section (lines 76-77) meant to imply that even an initial self-registration of the 2nd factor on a password-only account shall be precluded under the profile?
|Mikkel Hald / WAYF.dk|
Yes, it is still permitted.
We have changed that paragraph to say "Initial enrollment of one or more additional factors MAY take place subject to authentication by only a single factor. Subsequently, the factors used MUST be independent; this includes processes to recover, replace, or add authentication factors." to make this clear.
|2||Section 1, lines 34-37||I think the text "strongly recommended not to use the value defined in this Profile to meet intra-organizational MFA request/response needs" is a little bit too strong. I would like to soften it with an "if not the same requirements are met" or something like that.||Pål Axelsson / SWAMID|
Changed to "When using this Profile, one must strictly adhere to the semantics described in Section 4. This Profile is specifically designed for a service provider and an identity provider to signal multi-factor authentication behaviour in an inter-organisational single sign-on transaction.
Using the value defined in this Profile to signal compliance with an organisation’s internal policies carries risk. Even if the organisation’s internal MFA policy aligns with the requirements of this Profile today, organisational policy could evolve over time and become incompatible with the requirements of this Profile. Conflating MFA signalling governed by local policies with federated MFA signalling will likely impede an organisation’s ability to conform to this Profile over time."
|3||Section 5.2||Some of the sub sections within 5.2 are mis-labeled as 5.1.x||Albert Wu / InCommon||They are fixed now|
|4||26||Delete "It should be noted that". Filler phrase - adds no meaning.||John Scullen / AAF||The phrase has been removed now.|
|5||31||"This Profile is specifically applicable when" > This Profile specifically applies when||John Scullen / AAF||Updated.|
|6||39||Table uses lowercase for all terms except "Multi-factor authentication". Make consistent. Also the description for MFA says, "Multifactor refers to ...". Recommend changing to "Multi-factor authentication refers to ..."||John Scullen / AAF||Fixed.|
|7||111||Random "cv" at the beginning of the sentence to be removed||John Scullen / AAF||Fixed.|
|8||120||shall not > SHALL NOT?||John Scullen / AAF||Fixed.|
|9||128||must > MUST||John Scullen / AAF||Changed to SHOULD.|
|10||134||must > MUST?||John Scullen / AAF||Changed to SHOULD.|
|11||113, 116, 239 and 248||I'd prefer to see the actual name used instead of "this value". eg. When the REFEDS MFA Profile is used (listed/presented) ... Need the editors to check this is the correct terminology here||John Scullen / AAF||We believe "this value" is clear enough as the value is defined in the immediate previous paragraph(s).|
|12||254||shall not > SHALL NOT||John Scullen / AAF||Fixed|
|13||262||must > MUST||John Scullen / AAF||Replaced by SHOULD|
|14||This is looking pretty good overall. Congratulations to the authors and editors for getting it this far 👍||John Scullen / AAF||Thanks.|
|15||Many thanks from SWITCH for this MFA profile revision. We very welcome the many clarifications. We will be able to fulfil all requirements in the future, and the SHOULDs allow us to still be compliant in a transitional period.|
SWITCH intends to define a flag day in 9-12 months by when the REFEDS MFA deployment on SWITCH managed IdPs & OPs will meet the now clarified requirements currently not satisfied, like the earliest time of authentication.
|Thomas Lenggenhager / SWITCH||Great.|
Overall, I support the changes in the 1.2 - which I interpret as primarily:
|Vlad Mencl /|
Almost. The profile is now clear on that authninstant SHOULD be updated to the earliest time of the factors, and that all factors SHOULD be re-authenticated on forceAuthn.
The wording is chosen to make the updated version backward compatible but still clear on what the intention of the profile should be.
|17||One concern: I'm not sure reusing the same profile identifier with new semantics is the right way to go. This would mean SPs cannot be sure which version of the specification did the IdP issuing the assertion follow.|
Vlad Mencl /
|The 1.2 consultation version is made to not add new mandatory semantics and not include any breaking changes from the 1.0 version of the profile. All changes regarding requirements are advisory.|
|18||Second concern: I'm surprised the OIDC requirements for dealing with authentication instant and forced re-authentication in sections 126.96.36.199 and 188.8.131.52 are given as a SHOULD and not a MUST. (I also observe version 1.1 of the specification used a MUST in this part, though for different wording).|
Vlad Mencl /
|We have softened the OIDC section in line with the SAML section. Both are built on Section 4 in the profile which is softened compared to the 1.1 version of the draft.|
typo: the compound sentence is missing a pronoun to refer to the attribute: I'd insert a "which":
The SAML specification allows the Comparison XML Attribute in the <RequestedAuthnContext> element,
Vlad Mencl /
change "return" to "returns"
that an IdP unable to satisfy the requirements expressed
Vlad Mencl /
|21||264, 274||typo: section numbers 184.108.40.206 and 220.127.116.11 should be 18.104.22.168 and 22.214.171.124 respectively.|
Vlad Mencl /
|They are fixed now.|
"to qualify the user to access the organisation’s critical internal systems."
This sounds to me as exaggeration not suitable for a normative section. The profile is about authenticating to other organisations' systems and has nothing to do with the user's home organisation's critical internal systems.
Vlad Mencl /