Assurance Implementers Call of July 9, 2014

Attending

Ann West, Internet2
Steve Devoti, University of Wisconsin, Madison
Jacob Farmer, University of Indiana
Tom Golson, Texas A&M
David Crotts, Virginia Tech
Mary Dunker, Virginia Tech
Karen Harrington, VA Tech
Jeff Capehart, Univ. of Florida
Benn Oshrin, Spherical Cow Consulting
David Walker, Internet2
Emily Eisbruch, Internet2, scribe

DISCUSSION

FICAM 2.0

http://info.idmanagement.gov/2013/11/ficam-trust-framework-solutions-tfs.htmlhttp://www.idmanagement.gov/sites/default/files/documents/FICAM_TFS_TFPAP_0.pdf

Background: FICAM informed the Trust Framework Providers of 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 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 in FICAM 2.0. For instance,  FICAM 2.0 refers to Identity Providers as a Credential Service Providers (CSP).  A Credential Service Provider handles assurance, can do token management and credential issuance and can assert identity attributes on behalf of the individual.

http://www.idmanagement.gov/approved-identity-services

An issue under negotiation is that FICAM 2.0 requires all Credential Service Provides to release certain attributes. At this point those attributes are legal name and date of birth.  InCommon's position is that attribute release for InCommon IDPs should be handled by membership in the InCommon federation. InCommon is working with FICAM to remove the requirements for InCommon Credential Service Providers to release attributes to FICAM. Hopefully as a result of these discussions, FICAM will agree that InCommon will release a standard set of attributes (perhaps the R&S bundle). Anil John of FICAM will be setting up a meeting with NIH and NSF to discuss this.

In addition, InCommon has stressed in discussions with Anil John that the lack of federal services requiring assurance is a major issue.

Assurance Advisory Committee (AAC) Update (Jacob)

The AAC heard from the community that it would be beneficial to have more modular standards in the InCommon assurance program. The background is that the current Bronze and Silver profiles were modeled off a monolithic government document (NIST 800-63). Some Service Providers don't care about every category in the current specs and some IDPs find it very difficult to implement 100% of the spec requirements.

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 that the current InCommon Assurance Bronze and Silver profiles can be decomposed into smaller chunk standards, making it possible to pick and choose the relevant section, both on the IDP and SP side, providing more flexibility.

The AAC is starting to discuss this approach. At the same time the AAC is also working on a community profile. The current InCommon bronze and silver profiles were geared toward  federating with the federal government.  The use cases for federating with the federal government have not developed to date, and in fact, the higher education community has its own interests concerning identity assurance. One major area of interest is multi-factor authentication.

The AAC will have a F2F meeting in Aug., at which the goal will be to create a structure around which to create community-based profiles. The AAC hopes to propose a framework under which community members can create profiles and get them into consideration by the AAC.

Comments:

Benn: Agree with 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 assurance more meaningful to people and easier to achieve.
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)

https://wiki.shibboleth.net/confluence/display/SHIB2/Multi-Context+Brokerhttps://spaces.at.internet2.edu/display/InCAssurance/Multi-Context+Broker

The Multi Context Broker was released in March 2014 and is getting use, moving into production in some institutions. There are two enhancements planned over the next few months:

  1. 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. University of  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.

MCB in view of the upcoming release of Shib V3

New Alternative Means for SHA-2

  https://spaces.at.internet2.edu/display/InCAssurance/2014/07/01/New+SHA-2+Alternative+Means

Alternative Means is now approved for campuses needing to move to SHA-2. It states "Identity Provider (IdP) Operators may continue to use SHA-1 to sign assertions through_ January 15, 2015 _ without compromise to their InCommon Assurance certification"

Question regarding eduroam:
At one point, eduroam was not compliant with SHA-1 because it used a non-compliant algorithm. Is that still an issue?
Comment: Now there is the AD alternative means
Jacob: I can't answer on behalf of AAC, With my Indiana University hat on, it makes a difference how you authenticate people for eduroam.
It involves a management assertion and an auditor's judgement.