Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Update as of July 2015: Wiki for the MFA Interoperability Profile WG is here

 

Colleagues,

On behalf of the InCommon AAC, I would like to invite your participation in a new InCommon Multi-Factor Authentication (MFA) Interoperability Profile working group; the charter is below for your review.  This working group is being initiated based on substantial community interest in the topic of interoperable MFA.

If you are interested in participating, please send an email directly to me (and not the list), indicating your area of expertise and a brief summary of the reason for your interest in participating.  Please send these no later than Friday, June 26, 2015.  Please note the timeline for deliverables and ensure that you are prepared to allocate the appropriate amount of time to this effort.

Sincerely,

Jacob Farmer

Chair, Assurance Advisory Committee


 

InCommon MFA Interoperability Profile Working Group Charter

Mission

The Assurance Advisory Committee (AAC) invites the Community to participate in the InCommon Multi-Factor Authentication (MFA) Interoperability Profile Working Group.  The mission of the working group is to develop and document requirements for creating and implementing an interoperability profile to allow the community to leverage MFA provided by an InCommon Identity Provider.

 

Deliverables

1.  Assemble use cases that will motivate the deliverables of this working group

2.  Develop short list of widely deployed MFA technologies that will be in scope for the profile

3.  Define requirements for and draft MFA Interoperability Profile

4.  Develop and recommend scope and plan for adoption

5.  Present draft in session at Technology Exchange in October 2015

6.  Publish final profile by November 30, 2015

 

Principles

1.  Profile should be constrained to address the articulated need for distributed MFA.

2.  Ability to implement with current technology should be a core design constraint.

3.  Support for this capability should be exposed in the Federation Metadata.