...
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 Virginia Tech
Jeff Capehart, Univ. of Florida
Benn Oshrin, Spherical Cow Consulting
David Walker, Internet2
Emily Eisbruch, Internet2, scribe
...
Background: FICAM informed the Trust Framework Providers of the new FICAM 2.0 spec draft 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 may have minor changes, such as new terminology mapping. 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 There is a bundle of attributes that FICAM requires all Credential Service Provides to release . At this point those attributes are certain attribute bundles which contain legal name and date of birth . InCommon's position is that the Agencies will use to for identity matching. Since InCommon is focusing on business-to-government services and targeting key agencies most important to our constituency, InCommon is advocating the use of the attribute bundle defined in the Research and Scholarship Category. The next steps are to meet with Agencies of interest to determine if this set of attributes is sufficient for their use.
In addition, InCommon has all attribute release 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. The hope is that 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 see if an agreement can be reached. InCommon has also stressed in discussions with Anil John that the lack of federal services requiring assurance is a major issue.
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.
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 background is that 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 every category in the current specs . For example, they may care about incident response but not so much about privacy.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 you can take that the current InCommon Assurance Bronze and Silver profiles and can decompose them be decomposed into smaller chunk standards, so making it 's possible to pick and choose the relevant section, both on the IDP and SP side, providing more flexibility.
So service providers and can more selective
The AAC is starting to discuss this more modular approach to assurance, possibly using trustmarks. 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 current InCommon bronze and silver profiles were written explicitly to address requirements for federating with the federal government. The AAC recognizes that the research and higher education community has its own interests concerning identity assurance, such as multi-factor authentication. In response to this, the AAC is working on an overall framework for developing, promulgating and asserting community trust-related profiles.
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.
Comments:
Face to Face meeting in mid-August to discuss this topic.
Comments:
- Agree with the trustmark Benn: Looking forward to the trust mark approach conceptually, but will wait for the details
Tom: It's - Using the modular approach is a good idea to keep things moving 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 get thereachieve.
Also, must establish the use cases that this approach will address. Use cases are lacking in the current framework.
Shibboleth Multi-context Broker (MCB) Plugin Update (David)
https://wiki.shibboleth.net/confluence/display/SHIB2/Multi-Context+Brokerhttps://spaces.at.internet2.edu/display/InCAssurance/Multi-Context+Broker
David reported that the The Multi Context Broker was released in March 2014 and is getting use, moving into production in at some institutions. There are a few two enhancements coming up planned over the next few 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.
...
- 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
- Discussion is now underway on how the MCB will work with Shib v3.
- Shib
...
- v3 has some of the functionality of the MCB
...
- .
- A gap analysis is being conducted. Some issues around configuration files are being looked at.
- In about a month there should be a proposal around MCB and Shib v3
- The team is
...
- committed to a good upgrade / conversion path
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 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 InCommon assurance because it used a non-compliant algorithm. Is that still an issue? Discussion centered on how one authenticates people for eduroam. The decision on whether there is a problem around assurance for eduroam involves a management assertion and auditor judgement.
Failed Authentication Counter Work (Benn)
https://spaces.at.internet2.edu/display/InCAssurance/Failed+Authentication+Counter+Strawman
https://spaces.at.internet2.edu/display/InCAssurance/Component+Implementation+Guide
Benn reported that he will report on integration work on the Failed Authentication Counter database being done by UC Berkeley and Unicon on an upcoming Assurance Call.
Comment: would be interesting to compare the approaches to the failed authentication counter being used at UC Berkeley and Univ. of Nebraska.Some issues around configuration files are being looked at