Background
The REFEDS MFA Profile was developed out of the work of the InCommon MFA Interoperability Profile Working Group. The group developed a Mutlifactor Authentication Profile for InCommon but with a strong recommendation that the proposal be furthered developed at REFEDS to ensure international interfederation interoperabilty for MFA signals. REFEDS is very grateful to InCommon for allowing us to reuse their work in the context of this profile development.
The MFA Profile has been further developed by the GÉANT Joint Research Activity on T&I Future Technologies and through discussion and prelminary consultation with the REFEDS Assurance Group. Particular attention has been paid to ensure the MFA Profile makes sense within the context of the upcoming Assurance Framework proposal. For more information, see the Assurance Working Group space.
Overview
The consultation opens on Tuesday 28th February 2017 and will close at 5pm CEST on Monday 27th March 2017.
Participants are invited to:
- Review and comment on the proposed REFEDS MFA Profile and its suitability for publication as a REFEDS profile. Comments on the naming convention and the requirements for signalling in the document are particularly welcomed.
- Reflect on the requirement that each factor used must be independent: is more guidance on specific use cases needed in the core text or can this be supported by FAQ documentation?
Following the consultation all comments will be taken back to the Assurance working group for review and if appropriate the Profile will then be forwarded to the REFEDS Steering Committee for sign-off and publication on the REFEDS website as per the REFEDS participants agreement.
The document for the consultation is available as an attachment to this page. Background on the Assurance Working Group is available. All comments should be made on: consultations@lists.refeds.org or added to the change log below. Comments posted to other lists will not be included in the consultation review.
Change Log
Change Log for the REFEDS MFA Profile Consultation. Please fill in your comments and change requests below. Line numbers are available in the document for ease of reference.
| Number | Line / Reference | Proposed Change or Query | Proposer | Action / Decision (please leave blank) |
|---|---|---|---|---|
| 1 | Section 5 | "listed in order of preference". While what is listed here is consistent with the SAML standard, it may not be feasible in practice to use ordering to select the correct context, especially for 2-step MFA implementations. Part of the problem I think is that there's a presumption that the list is prioritized but while that's superficially true, it isn't really true in practice, it's too hard to implement that in an IdP. I had all I could handle getting such a complex system to just make sure it didn't violate the request. It works pretty cleanly when the methods are all independent, but when Duo requires Password first, I think it's unavoidable that requesting Password is going to bypass Duo even if Password is at the bottom of the list. This may mean that the "listed in order of preference" comment may need to be removed, or extra guidance provided. | Eric Goodman / Scott Cantor | |
| 2 |