spaces.at.internet2.edu has been upgraded to Confluence 7.11.1. If you have any questions and/or concerns, please contact us at techsupport@internet2.edu
Child pages
  • Comments from Jim Basney - 2016-05-04
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Subject:Re: [Assurance] comments on draft MFA Interop WG documents
Date:Wed, 4 May 2016 12:41:24 +0000
From:Basney, Jim <jbasney@illinois.edu>
Reply-To:assurance@incommon.org
To:assurance@incommon.org <assurance@incommon.org>


On 4/21/16, 3:23 PM, David Walker wrote:
By the way, for those of you who may not have seen Monday's TIER release announcement, the MFA Interoperability Profile Working Group has asked that comments on its draft profiles and other documents be sent to assurance@incommon.org.  Please take a look and weigh in on the conversation.
I think this MFA profile is potentially very useful for enabling federated authentication to high-value scientific resources and instruments. I'm really glad to see this work progressing.
What process does the group envision for IdPs to be approved to assert http://id.incommon.org/assurance/mfa? Will it simply be a new checkbox on the Assurance Addendum like http://id.incommon.org/assurance/bronze following the lightweight "Representation of Conformance" process?
Thanks,
Jim


Subject:RE: [Assurance] comments on draft MFA Interop WG documents
Date:Wed, 4 May 2016 13:19:04 +0000
From:Paul Caskey <pcaskey@internet2.edu>
Reply-To:assurance@incommon.org
To:assurance@incommon.org <assurance@incommon.org>

 



I hope we don't need to require an addendum for MFA...

I think the intent was for self-assertion.

 
 
Subject:RE: [Assurance] comments on draft MFA Interop WG documents
Date:Wed, 4 May 2016 13:48:10 +0000
From:Cantor, Scott <cantor.2@osu.edu>
Reply-To:assurance@incommon.org
To:assurance@incommon.org <assurance@incommon.org>


> I hope we don't need to require an addendum for MFA... > > I think the intent was for self-assertion. I won't speak for the WG, but while working on the material, I had been operating under the assumption this was not an assurance category at all but a self-asserted AuthnContextClassRef (in SAML terms), just like many others defined in SAML already. Thus the idea of a self-asserted category to go with a self-asserted AuthnContext seemed redundant (but that may prove not to be the case for other reasons). I didn't actually notice the naming convention in the URI included the word assurance, and tend to think that may be confusing as a result and worth reconsidering before this finalizes. Sometimes the obvious doesn't hit you when you're staring at it closely. -- Scott

 
 
Subject:RE: [Assurance] comments on draft MFA Interop WG documents
Date:Wed, 4 May 2016 14:00:43 +0000
From:Jokl, James A. (Jim) (jaj) <jaj@virginia.edu>
Reply-To:assurance@incommon.org
To:assurance@incommon.org <assurance@incommon.org>


+1 I made it to many of the calls and always had the self-asserted picture in my mind as the basic perspective -- that this was about passwords no longer being adequate and what is the new baseline authentication. I still think of this stuff as "Standard Assurance" - good for whatever applications you used to just use and ID/Password for - but I get Scott's point too about the name. Note that this work took a nice low bar on the technical side - almost anything that you can call a second factor is acceptable -- and there is no discussion about identity proofing. All good for self-asserted, perhaps less so if people were thinking differently. Jim

 
 
Subject:RE: [Assurance] comments on draft MFA Interop WG documents
Date:Wed, 4 May 2016 14:38:18 +0000
From:Paul Caskey <pcaskey@internet2.edu>
Reply-To:assurance@incommon.org
To:assurance@incommon.org <assurance@incommon.org>


+1 to all of that and yes, IMHO, we should not use the word 'assurance' to refer to this context.

 


Subject:Re: [Assurance] comments on draft MFA Interop WG documents
Date:Wed, 4 May 2016 09:24:57 -0700
From:David Walker <dwalker@internet2.edu>
Reply-To:assurance@incommon.org
To:assurance@incommon.org

 

I'll take responsibility for putting the work "assurance" in the URI.  I
did it without much thought, and it certainly can be changed.  In fact,
the plan is to replace it with a URI in the REFEDS name space, anyway.

I agree with everyone that the MFA authentication context should be
self-asserted.  I think the real question is whether IdPs that support
the MFA profile should also be given a (presumably self asserted) entity
category in metadata.  The current draft does not recommend an entity
category, as the group didn't see use cases where it would help.  We
have since, however, heard of SPs that would like to tailor their
discovery interfaces to exclude non-MFA-supporting IdPs, and there are
situations where an entity category can save an SP from issuing a second
authentication request when it prefers MFA, but will accept anything else.

Do others have use cases for an IdP entity category that it supports the
MFA profile?  It's certainly not too late to define one.

David

Subject:RE: [Assurance] comments on draft MFA Interop WG documents
Date:Wed, 4 May 2016 16:35:02 +0000
From:Paul Caskey <pcaskey@internet2.edu>
Reply-To:assurance@incommon.org
To:assurance@incommon.org <assurance@incommon.org>

 

It was the discovery use case I had in mind...

 

 
  • No labels