Child pages
  • Minutes of Assurance Call of 12-Feb-2014

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0


Trust framework providers, such as InCommon, have 6 months to comply with the new FICAM spec. There are  discussions underway to determine the impact of FICAM 2.0 to the InCommon Assurance program and the community. An important question is: what are the service providers FICAM will be working with first? The Veterans Admin is a big one. InCommon is aware that many campuses don't want their faculty and staff to leverage their campus credentials to interact w with consumer based services like the VA. They Campuses want to use their the campus credentials to be used for grant submissions and teaching resources or for interactions  interactions with the  the Dept of Ed. InCommon is hoping to find out from FICAM, what is the ETA for FICAM to bring on board the services that are more related relevant to higher ed? The answers to these questions will help the AAC determine how to support FICAM 2.0.


Benn reported that UC Berkeley has been interested in counting failed authentication attempts as a way of looking at password entropy and reset policies for the bronze and/or silver profiles. A strawman proposal was posted to the wiki is seen at


The scope of the work involves an aggregator that writes failed authentication events to a database that logs the subject, the time, and IP address and a service. The monitor periodically queries this.  Actions will be triggered at a given threshold. So for example, the system might be configured so that after 10K events, email a particular address. The email might go to the subject, or to an another email address such as the security team. Another action that could be triggered might be to generate a ticket to an issue tracking system. End goal is ability to stop asserting an IAQ for someone. There may be the ability to add or remove somebody from a group (such as Grouper group), where removing somebody from the group would effectively remove them from LDAP.  There would be an API into this system for user level and admin operations, such as obtaining current counts for a user. That could be tied into the user identity portal, so it would be possible to show a notification when a user logs in. Obtaining and setting thresholds   Thresholds will be configurable. Benn will send links to keep the Assurance list informed as portions of the work are released publicly.