Page History

The MFA Interoperability Profile Working Group discussed this issue in its call last week, and we'd like some more input from all of you.  Here’s a summary of that discussion, followed by some questions for you.

Summary of Last Week’s Discussion

There is a cost to creating entity categories.  While it is relatively easy to define them (what the group has to do), there is also a cost to InCommon to modify its documentation and Federation Manager software.  Further, assuming this becomes an international profile, all federations will bear that cost.  Finally, this startup cost may be dwarfed by the ongoing effort on the part of IdP and SP operators, who must understand an increasing number of entity categories and react as appropriate.

So, we need to ensure that new entity categories bring value.  These use cases have been identified for the use of an MFA entity category for IdPs:

1. Enable an SP to filter its discovery interface based on whether an IdP supports MFA.
2. Reduce the number of authentication requests an SP must issue to an IdP for certain types of error handling when MFA is desired, but other forms of authentication are acceptable.
3. Provide a formal mechanism for an institution to declare its compliance with the MFA profile (or perhaps a future stronger MFA profile).
4. Provide a workaround for SPs to avoid IdPs that do not behave as expected within the SAML spec.  For example, they respond incorrectly to requests for specific authentication contexts (or they do not respond at all), or they crash.

The group had not previously discussed the discovery issue, but recognizes its importance; it’s likely the most significant reason for defining an entity category.  The group had earlier decided that the potential additional authentication requests didn’t warrant an entity category, and that formal declaration of compliance was not necessary.  The fourth issue of IdP behavior is broader than just the profiles defined by this group, and so out of scope, but it was recognized that definition of an MFA entity category would address that issue in this narrow instance.

Questions for You

1. If we define an MFA entity category, what should its criteria be?  The group discussed the following:

1. What does it mean for an IdP to “support MFA?”  Is it the ability to issue assertions in compliance with the MFA profile for at least one member of its community?  Something else?
2. Should the ability to issue assertions in compliance with the Base Level profile also be included so that SPs that prefer MFA but will accept anything else can do that with a single authentication request?  This would imply that the ability to assert Base Level be required of all members of the IdP’s community.
1. Would a formal institutional declaration of compliance with the MFA profile cause you to trust its MFA assertions more?  Could that declaration be as simple as a box in the Federation Manager that would be checked by the site administrator, or should further documentation be required?

Thanks for your input,

Karen Herrington

Chair, MFA Interoperability Profile Working Group

Hi,

>What does it mean for an IdP to "support MFA?" Is it the ability to issue
>assertions in compliance with the MFA profile for at least one member of
>its community?

Yes.

In XSEDE we would conclude that researchers on that campus can use MFA for
federated authentication to XSEDE resources, so XSEDE doesn't need to
issue separate MFA tokens to those researchers. For more info on campus
researchers using XSEDE, see: https://www.xsede.org/campus-champions

>Should the ability to issue assertions in compliance with the Base Level
>profile also be included so that SPs that prefer MFA but will accept
>anything else can do that with a single authentication request?  This
>would imply that the ability to assert Base Level be required of all
>members of the IdP's community.

Yes.

I thought the InCommon Assurance program already defined a base LOA to
replace the POP. Any news on that?

>Would a formal institutional declaration of compliance with the MFA
>profile cause you to trust its MFA assertions more?

Yes.

>Could that declaration be as simple as a box in the Federation Manager
>that would be checked by the site administrator

Yes.

Sincerely,
Jim Basney
XSEDE's InCommon Site Administrator
> 

> >Would a formal institutional declaration of compliance with the MFA
> >profile cause you to trust its MFA assertions more?
> 
> Yes.

Can I ask why? What's the difference between self-asserting a category and self-asserting the same data in an assertion?

-- Scott

>>>Would a formal institutional declaration of compliance with the MFA
>>>profile cause you to trust its MFA assertions more?
>> 
>> Yes.
>
>Can I ask why? What's the difference between self-asserting a category
>and self-asserting the same data in an assertion?

I think my answer is the same for Base Level, MFA, Silver, or Bronze. Our
trust fabric is based on contractual agreements between InCommon LLC and
its participants, and that trust is operationalized via the federation
metadata. Knowing that an institutional representative made a declaration
to InCommon (either via an Assurance Addendum or via a checkbox on the
Federation Manager), subject to the Participation Agreement, gives me
greater trust in the organization's compliance with an InCommon standard
than I get from IdP-SP bidirectional communication alone.

-Jim

> >Can I ask why? What's the difference between self-asserting a category
> >and self-asserting the same data in an assertion?
> 
> I think my answer is the same for Base Level, MFA, Silver, or Bronze. Our
> trust fabric is based on contractual agreements between InCommon LLC and
> its participants, and that trust is operationalized via the federation
> metadata. Knowing that an institutional representative made a declaration
> to InCommon (either via an Assurance Addendum or via a checkbox on the
> Federation Manager), subject to the Participation Agreement, gives me
> greater trust in the organization's compliance with an InCommon standard
> than I get from IdP-SP bidirectional communication alone.

For the record, my counter-argument is that the the IdP is generally under the
control of the same individual who would have to check that box, and who already 
vouched for the key with which the assertion is signed, and so it creates an 
extra step for that person. Multiplied across the federation, I think that's a real cost.

-- Scott