There was further discussion of the interrelationships among the subgroups. There are natural overlaps, both in terms of topics and personnel. We may want to consider combining or retiring some subgroups, or suspending them during periods when the activity is more in other subgroups. This will be discussed more at the next full Cohortium meeting.
We discussed comments elements of a business case justification for multi-factor authentication, based on Nathan's summary for the University of Washington.
Will 2-factor become the norm? (or, at least, not passwords)
Want to be vendor agnostic, avoid vendor lock-in. (could be part of a justification statement, even if not really a justification itself)
There are, of course, applications that won't fit into our architecture.
Being proactive with a central MFA service can reduce rogue implementations.
Cost Components
Training, education, service center
Operation
Capital
One-time vs. ongoing costs
Life-cycle of products and refreshing product set.
Why refresh?
New features, vendor support (usual reasons for refreshing technology)
More secure (longer key lengths)
What's the right number of tokens? You want to minimize, but not always practical to reduce to 1.
We want to be careful this subgroup isn't over-representative of sites that already have MFA. We can test by asking institutions that haven't implemented MFA if this is what they need.
We'll want to address funding models, as well as justification and cost models.