Assurance Implementers Call of July 9, 2014
Ann West, Internet2
Steve Devoti, University of Wisconsin, Madison
Jacob Farmer, University of Indiana
Tom Golson, Texas A&M
David Walker, Internet2
Benn Oshrin, Spherical Cow Consulting
David Crotts, Virginia Tech
Mary Dunker, Virginia Tech
Karen Harrington, VA Tech
Jeff Capehart, Univ. of Florida
Emily Eisbruch, Internet2, scribe
FICAM let the Trust Framework Providers know about the new FICAM 2.0 spec last fall.
InCommon sent a lengthly set of comments. Most were addressed in discussions afterwards.
FICAM released their new 2.0 spec early in 2014.
Ann is working on analyzing the impact of the FICAM 2.0 documents on InCommon Assurance IDPs. The InCommon Bronze and Silver specs will most likely remain unchanged. There are some changes in terminology. The new FICAM spec refers to "Identity Providers" as a "Credential Service Providers." A Credential Service Provider handles assurance, and can do token management and credential issuance and can assert identity attributes on behalf of the individual.
There is a bundle of attributes that Credential Service Provides must agree to release. At this point those attributes are legal name and date of birth. But InCommon's point of view is that all attribute release should be handled by membership in the federation. InCommon is working with FICAM to negotiate away the requirements for InCommon Credential Service Providers to release attributes to FICAM. The hope is that it can be agreed that InCommon will release a standard set of attributes (perhaps the R&S bundle) to agencies operating within the FICAM framework.
FICAM decided that their previous document did not do enough to facilitate federation, and under FICAM 2.0, a federation like InCommon or Kantara must provide more info to FICAM about how their federation works, such as how the change management process, testing and interoperability, are handled, etc.
InCommon has told FICAM that Higher Ed community is not primarily interested in the consumer to government interaction, the way AT&T or Verizon might be. For the most part, the higher ed community is interested in a model that is more like a business to government interaction.
Anil John of FICAM will be setting up a meeting with NIH and NSF to see if an agreement can be reached.
Concerning services offered by the Federal Govt that require assurance, there are rumors about a ScienceCV for grad students and others applying for grants. Assurance might be required in spring 2015.
No services right now are requiring assurance.
Assurance Advisory Committee (AAC) Update (Jacob)
The AAC has heard from the community that it would be beneficial to have more modular standards in the InCommon assurance program. The current Bronze and Silver profiles were modeled off a monolithic government document (NIST 800-63). Some Service Providers have stated that don't care about everything in the current specs. For example, they may care about incident response but not so much about privacy.
Conversation nationally and within the IDESG focuses on developing modular units, called Trustmarks, for assurance.https://www.idecosystem.org/wiki/Trust_Frameworks
The idea is you can take the current InCommon Assurance Bronze and Silver profiles and can decompose them into smaller chunk standards, so it's possible to pick and choose, both on the IDP and SP side, providing more flexibility.
So service providers and can more selective
The AAC is starting to discuss this approach.
At the same time the AAC is also working on a community profile. It's said that bronze and silver, being based on NIST 800-63, took the federal government view of the world. In fact, the higher education community cares about a smaller subset of the identity universe. One major area of interest is multi-factor authentication.
The AAC will have a F2F meeting in Aug. The goal will be to create a structure around which we can create community-based profiles. The AAC hopes to lay out the framework so community members can create profiles and get them into
consideration by the AAC.
Benn: Looking forward to the trust mark approach conceptually, but will wait for the details
Tom: It's a good idea to keep things forward.
For an IDP to implement Bronze and Silver, it can happen that 80% of the requirements are not too difficult, but the last 20% is challenging. A mechanism to keep things moving is good.
Karen: Agree, we need to fine a way to make Bronze and Silver more meaningful to people and easier to get there.
Also, must establish the use cases that this approach will address. Use cases are lacking in the current framework.
Shibboleth Multi-context Broker Plugin Update (David)
David reported that the Multi Context Broker was released and is getting use, moving into production in some institutions. There are a few enhancements coming up over the next months
The MCB has not been honoring the default authentication context that can be specified for a relying party if the relying party does not request an authentication context in the protocol. So support for that will be added
2. U Chicago raised some concerns around how forced reauthentication occurs, This is related to how we have implemented Duo and Duo-like technologies in the MCB. There will be an option to keep the current behavior of the MCB or change it.
Discussion is now underway on how the MCB will work with Shib v3
Shib V3 has some of the functionality of the MCB
We are doing a gap analysis
A month from now we will have a proposal around what to do for Shib v3
We are committed to a good upgrade / conversion path
Some issues around configuration files are being looked at