Minutes NOT YET FINAL as of July 14, 2014
Assurance Implementers Call of July 9, 2014
...
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 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. 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.
...
An issue under negotiation is that FICAM 2.0 requires all Credential Service Provides to release certain attributes. At this point those attributes are attribute bundles which contain 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 thisthat 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 stressed in discussions with Anil John that the lack of federal services requiring assurance is a major issue.
...
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 more modular approach to assurance, possibly using trustmarks. At the same time the AAC is also working on a community profile. The current InCommon bronze and silver profiles were geared toward written explicitly to address requirements for federating with the federal government. The use cases for federating with the federal government have not developed to date, and in fact, the The AAC recognizes that the research and higher education community has its own interests concerning identity assurance. One major area of interest is , 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 Face to Face meeting in mid-August ., 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.to discuss this topic.
Comments:
Benn: - Agree with the trustmark approach conceptually, but will wait for the details
Tom: - 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 achieve.
Also, must establish the use cases that this approach will address. Use cases are lacking in the current framework.
...
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?
Jacob: I can't respond on behalf of AAC, however with my Indiana University hat on, an important issue is how you authenticate 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.
...
https://spaces.at.internet2.edu/display/InCAssurance/Component+Implementation+Guide
Benn reported that at an upcoming Assurance Call he should have a 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.