MFA Interoperability Profile Working Group - Scribing Document



Short URL for this document:

Dial-in numbers:

+1-734-615-7474 (Please use if you do not pay for Long Distance)

+1-866-411-0013 (English I2, toll free US/Canada Only)

PIN: 0148636#

NOTE WELL: All Internet2 Activities are governed by the Internet2 Intellectual Property Framework.

Index to Meeting Notes

Work Group Call - August 25, 2016




Agenda and Notes

Work Group Call - June 9, 2016



Agenda and Notes

  1. Welcome

  2. Agenda bash

  3. InCommon MFA Profile

    1. No changes. Considered “final” (with concerns about wording of the URI… “incommon” and “assurance”)

  4. InCommon Base Level Profile

    1. Changes accepted. Considered “final” (with concerns about wording of the URI… “incommon” and “assurance”)

  5. MFA Profile Usage Guidance

    1. Changes accepted (changes were last made on the previous call). Considered “final”

  6. Final Report of the MFA Interoperability Profile Working Group 

    1. Appears to be missing the following:

      1. Discussion of Entity Attribute, and distinction between “MFA” entity attribute and the alternate “authncontexts_supported” entity attribute discussed at June 2 meeting

      2. New “stronger authn” group charter

        1. Concern that this group might go “too far” and over-prescribe (InCommon Gold/Platinum)

        2. Perhaps approval of charter should be based on number of (existence of) SPs for which this is a real concern.

  7. MFA Threats and Usage Document 

    1. Volunteers (at least Eric) will look over and raise comments if any inconsistencies with subsequent work is found. Otherwise we will consider “final”.

  8. MFA Use Cases and MFA Use Case Descriptions

    1. Volunteers (at least Karen) will look over and raise comments too.

  9. Karen will contact Nicole to see about submission for REFEDS consideration once the above changes are made.

Work Group Call - June 2, 2016




Agenda and Notes

  1. Welcome

  2. Agenda bash

  3. Status of the possibility of a REFEDS consultation (Scott)

    1. There doesn’t seem to be a light-weight process that would get us a URI to use for the profiles.  We’ll have to go with the full Consultation process.

  4. Draft Charter for a Strong Identity Proofing Profile Working Group

    1. Please look it over for discussion next week.

  5. MFA Profile Usage Guidance

    1. Eric will accept all of Scott’s comments and call it done.

  6. Proposed changes for the next revision of Final Report of the MFA Interoperability Profile Working Group and the profiles

    1. What should we do about the profiles’ URIs?

      1. We’ll pursue REFEDS consultation and consider an InCommon-only interim if it looks like that will take too long.

      2. Karen and David will talk with Ann about bringing this to REFEDS.

  7. InCommon MFA Support Entity Category

    1. Scott:  This is an Entity Attribute, not an Entity Category.

      1. David will correct this.  [Added to notes after the call. - DHW]

    2. Scott:  Should we just define a metadata element that lists the authnContexts that the IdP supports?

      1. This satisfies purposes 1 and 3 in the draft spec.  It’s questionable whether 2 needs anything, anyway, since SAML says you can’t lie in your assertions.

      2. “Support” would mean something like “would reply successfully for at least one person”

      3. Consensus on the call was that this is a good idea that’s extensible to future profiles without inventing new entity attributes, however...

    3. The benefit of any flagging is marginal.  Should we do anything?

      1. Consensus on the call was no.

      2. Leave the decision up to the AAC by providing the draft entity attribute definition, but recommend it not be used.

      3. Discussion will continue next week.  Karen and David will discuss, too, and recommend a resolution.


Work Group Call - May 12, 2016




Agenda and Notes

  1. Welcome

  2. Agenda bash

  3. No call next week?

  4. Recommendation for next steps

    1. Propose as a REFEDS profile

      1. Scott Cantor will check with Nicole Harris about process.  We may want to ask for a REFEDS URI, if approval of the profile would take a while.

    2. Create group to create “strong identification/registration” profile

      1. The new 800-63-3 should be considered in this work.

      2. We’ll recommend that the current group be rechartered (and perhaps renamed) to continue the work.

    3. Encourage adoption

      1. Incentives to use MFA in popular services (e.g., CILogon, Certificate Manager)

      2. Communications campaign

      3. Encourage people to contribute ways they address the “VOIP” and other deployment issues

  5. Eric’s proposed edits for the Usage Guidance

    1. Everyone please review Eric’s proposed changes, particularly with respect to AuthnContextClassRefs he calls out.

    2. In general, we should review the document to make sure the language doesn’t sound normative, as opposed to guidance.

  6. Public comments:  Entity categories revisited

    1. Comments from Dean Woodbeck - 2016-05-11

    2. Comments from Jim Basney - 2016-05-04

      1. We’ll make our final decision on this in our next call.  David will draft a spec to help the discussion.

Work Group Call - May 5, 2016




Agenda and Notes

  1. Welcome

  2. Agenda bash

  3. Who’s going to Global Summit?

  4. Public comments:  Entity categories revisited

    1. Comments from Jim Basney - 2016-05-04

      1. Issues are filtering discovery, IdPs that “trap” the user and not return an error to the SP, and IdPs that crash.

      2. Currently, InCommon would have to modify the Federation Manager to enable an MFA entity category, and IdP administrators would need to check the box.

        1. This applies to each federation in eduGAIN.

      3. The long-term issue is that we’re likely to create a lot of entity categories, and people won’t understand how to use all of them.

        1. => We should recommend some future study of this issue.

      4. Eskil : I would say that it is a key point in the ability for one university to trust another university’s MFA that it is marked by the Federation (and for example involves some sort of certification and for example prohibits incorrect onboarding processes)

        1. SWAMID will be defining an entity category for this. Would be useful to link to their documentation when it becomes more ready for comment/sharing.

      5. The discovery use case is probably the most important.

        1. How many SPs will require federated MFA, as opposed to asking for it and providing their own MFA if the IdP does not provide it?

      6. Criteria for an entity category

        1. “Support” MFA profile

          1. Assert for at least one person? (See R&S discussion of “some population”)

          2. IdP does not “trap” users, but returns error to SP (or another requested context) (Is this specific to “if the user does not have MFA registered”? Many IdPs trap users under PPT use cases.)

            1. Our scope is MFA, so this would apply only to MFA.

            2. What is “our scope” if a request includes /mfa OR /ppt (/mfa preferred)?

            3. => We won’t require this.

          3. Does it have any implication that campus administration has “signed off” on it?

          4. Include Base Level profile somehow?  For all users?

        2. Concern about defining an entity category that is used to infer behavior beyond what the formal definition states.

          1. E.g., using it to determine that the IdP can process arbitrary RequestedContexts without crashing (non-mfa specific)


Ran out of time at this point...


  1. Recommendation for next steps

    1. Propose as a REFEDS profile

    2. Create group to create “strong identification/registration” profile

    3. Encourage adoption

      1. Incentives to use MFA in popular services (e.g., CILogon, Certificate Manager)

      2. Communications campaign

      3. ???

    4. ???

Work Group Call - April 28, 2016




Agenda and Notes

  1. Welcome

  2. Agenda bash

  3. Public Comment Threads received to date from

    1. Please add any additional comments you’d like prior to the call.


  1. Recommendation for next steps

    1. Propose as a REFEDS profile

    2. Create group to create “strong identification/registration” profile

    3. Encourage adoption

      1. Incentives to use MFA in popular services (e.g., CILogon, Certificate Manager)

      2. Communications campaign

      3. ???

    4. ???


Work Group Call - April 14, 2016




Agenda and Notes

  1. Welcome

  2. Agenda bash

  3. Documents for Public Comment

    1. We will place our documents here after this call for inclusion in the TIER version 1 announcement.

    2. Call for comments by May 16.

  4. Final review of our documents before opening for community comment

    1. InCommon MFA Profile

      1. We reworded the bullet about independent factors.

    2. InCommon Base Level Profile

      1. We left the language that says the session has been authenticated, not necessarily the user.

    3. Multi-Factor Authentication (MFA) Interoperability Profile Working Group Final Report

      1. Everyone, last chance for comments is Friday (4/15) morning (Eastern).

    4. MFA Profile Usage Guidance

      1. Scott made a number of edits to firm up SAML-related issues.

      2. Last chance for comments is Friday (4/15) morning (Pacfic).

    5. MFA Technologies, Threats, and Usage

      1. No changes

    6. Note that we are not finalizing these documents right now, only opening them for community comment.

      1. David will export the profiles and MFA Technologies, Threats, and Usage to Documents for Public Comment today.  The other two documents will be exported tomorrow afternoon (Pacific) after he gets OKs from Karen and Eric.


=> There will be no call next week.

Work Group Call - April 7, 2016




Agenda and Notes

  1. Welcome

  2. Agenda bash

  3. Let’s try to be ready for public comment after next week’s call.

    1. Review final report next week.

    2. TIER v1 release is April 16.

  4. MFA Profile Usage Guidance

    1. Please review and comment before the call.

    2. Do we have the right names for the profiles?

      1. How about "InCommon Base Level" and "InCommon MFA"?  Yes.

    3. We won’t modify the normative text to indicate “persistent” threats, as opposed to short-term.

    4. We’ll keep offline cracking and online guessing on the same bullet.

    5. Is a phone number acceptable as a second factor?

      1. Yes, if it’s not authenticated (only) with a password.

      2. It’s acceptable for an enterprise to mitigate bypass of this by end-users through policy, education, and enforcement.

      3. The usage guidance will indicate these things.  No change to the profile is needed.

    6. Should re-registration be required to require both factors (or not just first factor)?

      1. We’ll want to add concepts of “independence of factors” to profile, as well as controls for re-registration.  Eric will propose wording.

    7. We won’t include a section about a factors that are not directly verified by the IdP (e.g., a password-protected X.509 cert).  They’re allowed in our profile.

    8. Scott suggested some cleanup of SAML-specific language.

  5. We ran out of time at this point.  Watch for potential announcement of an additional call...

  6. Issues for the Profiles

    1. Walter’s clarifying language about session length

    2. Should we add a comment that a factor (e.g., a VOIP service) that’s unlocked with a password is not distinct from username/password?


Work Group Call - March 31, 2016




Agenda and Notes

  1. Welcome

  2. Agenda bash

  3. MFA Profile Usage Guidance

    1. Are there issues that should be moved to the profiles?

      1. EricG: Everyone should review, and if there are things we all agree on, then they should probably be moved into the profile.

      2. AI: Full group look through guidance on call, work through it, find issues - EricG walk us through it.

      3. There is overlap between this and Jim Jokl’s matrix, and that’s good.  How much detail here is useful?

      4. Should we wordsmith ‘a persistent threat to user authentication’ back into the MFA profile?

      5. Discussion of being normative vs. not - being very prescriptive is difficult (see: Assurance program), but some of this needs to be an absolute requirement, or it’s not worth doing.

      6. Hot button issue: any second factor which is accessible via a first factor should be explicitly called out as something that is not acceptable.

      7. Consensus: Anything that’s a MUST must be put into the profile

      8. SHOULD doesn’t mean anything in a spec

      9. Might want to include accessibility considerations in the guidance

      10. Discussion of SAML flow guidance - may not want to put shibboleth-specific material/examples in this section.

      11. Not valuable to put something in the guidance unless it refers to a normative requirement of the profile?  Not helpful to give advice the IdP can’t do anything with.

      12. Should take out guidance on trusted devices unless they are explicitly forbidden by the profile.  Profile says ‘user’s current session’ - that needs to get strengthened/clarified in the profile.

      13. AI: Walter will propose new language for the profile about what it means to have done MFA in the context of the user’s current session.

    2. Should this be discussed in next week’s Assurance Implementers call?

      1. Mention that we’re working on this, but don’t explicitly share it yet until we’re out of heavy drafting mode.

      2. Will be open to community review of the profiles/guidance when they’re out of draft.

  4. InCommon Base Level Profile

    1. Should this have a criteria to comply with the Participation Agreement?

    2. Should this not be InCommon centric to enable use by other federations?

      1. These two things are diametrically opposed

      2. Proposal - this is a ‘null’ profile that you get to ask for, and it should be nothing more.  That would allow it to be useful to other federations.

      3. If it’s explicitly unspecified, that means deployers asking for ‘base level’ you don’t get to see, e.g. passwordProtectedTransport

      4. If you allow ‘anything’ - you could get back ip-based or other really weak authN, and you would not know.

      5. If you rule something out, it’s no longer base-level.

      6. Eric will capture this distinction in the usage guidance, for now.

        1. Do we really need three profiles? (that was mostly intended to be facetious)

          1. Null

          2. Wrapper for password protected transport (or - just not ‘really bad authentication - like IP-based’)

          3. MFA base profile

  5. Status of final report

    1. Karen has started on it

  6. Other items

    1. Brett - prepare ourselves for moving this to REFEDS?

      1. David, Ann and Nick discussed. Yes, likely should take to REFEDS for review/etc.

      2. REFEDs recent discussion for SIRTFI seems somewhat analogous and so could be a good approach to take.

      3. - may want to contact ahead of time to bounce ideas off her/get her take.

Work Group Call - March 24, 2016




Agenda and Notes

  1. Welcome

  2. Agenda bash

  3. Complete language for our profiles, based on comments received during the week

    1. InCommon Base Level Multi-Factor Authentication Profile

      1. We’re editing and resolving comments.

      2. After review of the usage guide, we’ll consider if some of its issues should move into the profile

        1. In particular, the issue Walter raised about whether Duo’s “trusted devices” are allowed.

        2. David mentioned that Duo will be asked to review what we’ve done, probably recommend configurations that comply.  (Nick Lewis, who has Duo in his Net+ portfolio, knows about this and participates in our group.)

      3. We got through the document and resolved all comments (for now, at least).

    2. InCommon Base Level Profile

      1. We resolved all comments, except for whether we should have any criteria for this profile.  What’s there doesn’t require anything other than InCommon membership, but maybe we should have nothing at all.

      2. We’ll continue this discussion next week.

  4. MFA Technologies, Threats, and Usage

    1. This document is complete.

  5. MFA Profile Usage Guidance

    1. Everyone is asked to read and comment on Eric’s draft for discussion next week.

  6. If there's time, brainstorm an outline for our report

    1. There was not enough time.


Work Group Call - March 17, 2016




Agenda and Notes

  1. Welcome

  2. Agenda bash

  3. Review of our Use Cases

  4. MFA Technologies, Threats, and Usage

      1. [I’m still unclear on difference between static and dynamic Phishing - matters most for Duo push]

      2. Are we trying to require mitigation of the user bypassing authentication processes (e.g., configuring your voicemail to respond to Duo requests)?

        1. It needs to be included in security awareness training.

      3. What phones are allowed?  Not VOIP that authenticates with a password.  Phone number should be tied to a specific outlet or device (cell phone).

        1. The IdP/institution will have to have a process to figure this out

  5. Complete language in the profiles


Work Group Call - March 10, 2016




Agenda and Notes

  1. Welcome

  2. Agenda bash

  3. Plea for use cases descriptions

  4. Please read Jim Jokl’s MFA Technologies, Threats, and Usage for discussion next week.

  5. Finalize InCommon Base Level Multi-Factor Authentication Profile for public comment.


                Low Security                    High Security


Assurance Level 1        WiFi-login                    “Facebook MFA”


Assurance Level 2        Normal login to a university system        Login to invoice

system/student administration


What I meant to illustrate is that we view MFA as something different than Assurance Levels. “Facebook MFA” is something that we so far haven’t found a need for. This is for private “consumers” which value their Facebook accounts. The good thing is that we on the other hand see a high value of aligning the discussions and use the same MFA profile if possible (and of course provide this as a part of the official Shibboleth IdP branch)



Work Group Call - March 3, 2016




Agenda and Notes


Work Group Call - February 25, 2016




Agenda and Notes



Work Group Call - February 18, 2016




Agenda and Notes

  1. Welcome

  2. Agenda bash

  3. FYI:  GTRI Trustmark Pilot.  Specific trustmark definitions are at 


As an example Lund University is implementing the bootstrapping of a second factor (in the first wave Google authenticator) like this:

  1. User logs in with uid/password to the account management self service portal

  2. User chooses to add second factor

  3. User is presented with a form to enter cardnumber (16 digits) of campus card (physical card distributed to all employees and students, card number is only available to a user by looking at the physical card) and PIN code for the card.

  4. User is considered verified if the information is provided correct

  5. User is allowed to add Google Authenticator

  6. User is unable to remove token and can only add a new Google Authenticator by physically visiting a directory administrator and have them erase the token through the account management portal


  1. FYI:  The use cases we’ve identified so far:

  2. Answering our current questions

Current Questions




Base-Level MFA Requirement

Stronger Level Requirement

Base-Level with Mutual Authentication

Future Optional Spec


Do we want to call phishing out specifically? There are, of course, other risks, such as man-in-the-middle. - What are the risks we address?  How do we state them in the spec?

Improperly disclosed (unprotected) transmitted secrets not usable (a) more than once; or (b) after an X minute window after disclosure.

Threats addressed: password phishing

Protects against man-in-the middle attacks (verifies agent requesting credential is the correct agent)

BS:Not as a requirement of the spec, but as a statement of the means of the authentication and the means of the registration process



Do we allow "trusted" access devices (PCs, phones, etc.)?


maybe -- perhaps limited to exclude netblock-trust?

BS: Splitting hairs between saving a cookie for trusted, and registering a device to get SMS/Soft Token/Voice access. Both are providing something you have.  So this needs to be addressed by looking at provisioning process (Q 7)



How long can the SSO session be?

EG: Any the authenticating organization allows anyway.

EG: 8 hours with support for ForceAuthn for re-authning both factors (I had to say it!)

BS: An AuthN Instant seems to allow the SP to decide. Better would be metadata extension or AuthN Request statement that states how long the SP will allow  



Do we allow "fail open?"

Yes, with appropriate signaling

No! (Not without signalling!) +24 EG: for me, signalling “fail open” means saying “didn’t do second factor”, which is equivalent to “no”

DL: Operational realities will require business continuity which will win every time over our desires.  public/well-known location posting of fail-open periods will allow services to more carefully scrutinize actions done during the fail-open period.

(+1, we have built this option into our MFA deployment for SSO)

BS: Yes, if the campus fails the 1st factor open as well ;)

Definitely no.



Is a second factor that is unlocked with the first factor (e.g., VOIP phone) really a second factor?

No, but how is that specified? (EG: Out of scope/advisory for base level? +1)

BS: This really needs to be treated the same as question #6



Can a second factor be registered solely on the basis of the first factor?

EG: Allowed with an initial registration period?

DL: Allowed for initial registration open anytime / Denied for re-registration device-recovery?

EG: Allowed only with separate vetting?



In general, is the registration process "strong enough?"


EG: Duplicate of #6 above?



Do we want to identify technologies?














Work Group Call - February 11, 2016




Agenda and Notes

  1. Welcome

  2. Agenda bash

  3. Use cases

  4. Continued discussion of Paul Caskey's language for the base-level MFA profile.




Work Group Call - February 4, 2016




Karen Herrington, David Walker, Emily EIsbruch, Scott Bradner, Scott Koranda, Bradley Schwoerer (U of Wisc-Whitewater), Mark McCoy (UTSA), Roger Safian (Northwestern), Nick Roy (I2), Sean Sweeney (PITT), Jim Jokl (Virginia), Nick Lewis (Internet2), Eric Goodman (University of California), Tommy Doan (Southern Methodist University), Eskil Swahn (SWAMID, Lund University), Stefan Metzger (DFN), Mike Grady (Unicon),Theresa Semmens (NDSU), Brendan Bellina (UCLA), Helen Fankhauser (U of NE), Rob Pierce (Sewanee), Ayesha Benjamin (UCF), Mary Dunker (VA Tech), Russell Beall (USC), Keith Hazelton (UW-Madison)


Agenda and Notes





This working group is chartered by the AAC, InCommon Assurance Advisory Committee.

Previously Jacob Farmer, Indiana University led this working group in 2015.

There were two subgroups


Previous Subgroups for the MFA Working Group

Link to Charter for this Working Group


scope - need to have common understanding of limited scope for 1st phase of work


David Walker: Much interest in the output of this WG


There is urgency to deliver.

We should deliver a really simple MFA profile for phase 1 (in early April).  An “MFA was Done” profile.

Then we could modify the charter to continue to more complex issues.


Eric, UCOP: that makes sense. Focus on “what’s the signaling.”  

Need to be able to indicate “Failed (MFA only)” or “Unable to comply” to the SP or IDP.

  May be a functional requirement of SP or IdP that they be able to send (or consume and rationally reply to) such messages in order to claim “compliance” with profile. E.g., an SP that requests MFA MUST also accept Password; even if response is just “sorry you need MFA” when Password is provided (This is an example, not a specific proposal)


David: Limit the scope for now  to SAML Authentication Context signaling

Nick Lewis - agree with David’s point about simple and leave complex issues out (that might be service provider specific like Duo)


Mike Grady: may want understanding of “remember me”

Karen: getting to that level can be complex


Scott K: Expressed desire for a single approach across SAML higher ed identity federations, for example eduGAIN (not just InCommon-focused)


Eskil: I’m here at least. SWAMID (Sweden). We are currently starting to roll out MFA in our federation. We are interested of course to end up with a similar profile to yours/ours


David:  Here’s Paul Caskey’s language that I just mentioned:  “When SAML Authentication Context ‘xyz’ is used in a SAML Authentication Request or subsequent SAML Authentication Response, the meaning of that value is that a discrete second factor will always be (or was) used in the initial authentication event for the current web SSO session.  Such second factor will be resistant to phishing attempts and will be used regardless of the user’s device or location.  Normal SSO session options (duration, etc) are allowed.”


Outcomes of today’s call


Questions we’ll have to answer…




Action Item Summary


Next Call: Thursday, Feb. 11 at 4pm ET


Use Cases Subgroup Agenda - September 8, 2015


Other things we might want to signal (at least conceptually, but perhaps not really…)


Use Cases Subgroup Agenda - September 1, 2015


Mountain Time Zone



UC SP-01

Description: SP require MFA for all users. Typical situation includes a SP handling sensitive research information with requirements for IT/IS-security.




Advantages: The SP is in complete control of the business logic.

Disadvantages: No fallback for users lacking MFA capability.

Distinguishing characteristics of use cases (SP-signalling oriented):

Use Cases Subgroup Agenda - August 25, 2015


Archived notes from full group meeting on 8/5/15


Agenda - August 5, 2015


Blank Template for Reuse


Group Type Agenda - Date