Assurance

[Tom Barton <>]

Hi Colleagues,

It looks like an impressive group has done some really impressive work, and I'm, well, impressed!

I have a few questions and suggestions.

1. Since these profiles should eventually be adopted internationally in order to have greatest effect, I suggest addressing two aspects to remove potential barriers:

• Choose an identifier from the REFEDS namespace, and of course gain support and approval for allocating that value from REFEDS. Eg, "http://refeds.org/profile/mfa" and "http://refeds.org/profile/base-level".
  
• Remove "InCommon" from the names of the profiles themselves.

2. What is the source of the data in "MFA Technologies, Threats, and Usage", or, if it is sourced by the WG, what methodology and standards were used to arrive at this data? Associated suggestion is to put that material into the doc itself.

3. Big +1 for the manner in which you limited scope and focused!

4. Re the second main bullet in the "Independence of Factors" section of "Usage Guidance". What is the basis for the statement "Processes that allow a user to immediately register a new second factor (reregistration)
using only their “first factor” enterprise password are not secure." in the context of the specific risks identified in the "Risks that must be mitigated" section? Ie, should there be an analysis of those risks that is used to reach the conclusion that such reregistrations do not mitigate those risks, rather than an a priori statement of it being not secure?

5. Perhaps related to #4, the first main bullet in the "Independence of Factors" section of "Usage Guidance" contains the statement "Any factor that is directly accessible using the first factor is NOT considered a second
factor." Should that statement be sharpened to say something like "Any factor that is directly accessible by *unauthorized* use of the first factor ..."?

6. Did the WG consider whether or not it would be good to also define a corresponding entity category, signifying something like "this IdP supports this profile for some significant segment of its user population", or "this SP supports this profile for users in some of its security roles"? If so, would it be worthwhile to add a brief discussion of that proposition and the WG's conclusion to the Final Report, or if not, might that be an area for future work, to be added to the Recommendations section of the Final Report?

7. I understand that the base-level authncontext enables an SP to express that it prefers but does not require MFA, but I don't understand how it establishes "a base over which other profiles could be defined." Could you enlighten me?

Many thanks,
Tom

-- 
Tom Barton
Senior Director for Architecture, Integration, and Security
Chief Information Security Officer
IT Services
University of Chicago
+1 773 834 1700

-- 
Tom Barton
Senior Director for Architecture, Integration, and Security
Chief Information Security Officer
IT Services
University of Chicago
+1 773 834 1700