*Participants*
Keith Hazelton, U. Wisconsin-Madison (chair)
David Walker, UC, Office of the President
Scott Cantor, OSU
Paul Hill, MIT
RL “Bob” Morgan, U. Washington
Tom Barton, U. Chicago
Rob Banz, UMBC
Mark Jones, UT Houston
Bill Weems, UT Houston
Renee Frost, Internet2
Steve Olshansky, Internet2
Jessica Bibbee, Internet2 (scribe)
New *Action Items*
[AI] {Bill} will share a whitepaper addressing global Identity Management.
Carry-over *Action Items*
[AI] {Keith} will craft a survey question to understand what is going on within the eduCourse space in the real world, as it pertains to Section, and share with relevant mailing lists. (22-Oct-07)
*Agenda*
1. Identity Assurance Profiles (was LOA) in SAML assertions; Establishing Conventions for URI-based representations.
* See < https://spaces.internet2.edu/x/Jhc > for a revised draft document on this topic
* See also the extensive discussion on the MACE-Dir thread, "RE: how to express a LoA/IAP"
* Attendees at the 5-Nov meeting recommended limiting these recommendations to apply only to InCommon, specifically for the Bronze and Silver Identity Assurance Profiles. The revised draft above reflects that recommendation.
2. Discussion of Cantor redraft of attribute profiles document
* See < http://middleware.internet2.edu/dir/docs/draft-internet2-mace-dir-saml-attributes-200711.pdf >
* With revisions marked < http://middleware.internet2.edu/dir/docs/draft-internet2-mace-dir-saml-attributes-200711-diff.pdf >
*Discussion*
- Identity Assurance Profiles (was LOA) in SAML assertions; Establishing Conventions for URI-based representations-
Attendees at the 5-Nov meeting recommended limiting these recommendations to apply only to InCommon, specifically for the Bronze and Silver Identity Assurance Profiles. The revised draft, Identity Assurance Qualifiers, reflects that recommendation, < https://spaces.internet2.edu/x/Jhc >. Cf. also the extensive discussion on the MACE-Dir thread, "RE: how to express a LoA/IAP" (beginning 14-Nov.)
{Keith} asked the Group if the above revised draft is acceptable or if it is in need of still further revisions. {Mark} did not object that there be an identity assurance profile, but rather what the draft suggests it will do. He was interested in asserting level of assurance and attribute assurance separately.
{Bill} shared a few examples where collaboration across organization boundaries demands another approach to authentication. In vetting the identity of a person, which personal identity attributes may be associated? Credential providers (e.g., ProtectNetwork) may not always be associated with the home institution. An example is Shibboleth-enabled Blackboard; even if the provider is recognized, entitlements are still needed to let a person into a course or particular roles of a course. The question is whether the source of authority is known and can be trusted. It is reasonable to keep the identity profile separate from a set of rules that allows the handling of personal attributes, as it comes up from the authority record. The difficulty arises when trying to interpret the complexity of the assurance profiles.
What is the best way to handle personal attributes? A current challenge is how to associate the authentication identifier in a meaningful way. A use case is the Patient Identity Information; there is no single identifier that matches one of the six Institutional Review Boards (IRBs). The Service Provider must get an entitlement from each of the IRBs before it can proceed. Here, the IRBs are handling things using an agreed upon object class, as this allows them to move on to the next step. There are different rules for different attributes; the defining of requirements is not to make an absolute demand, but more so, to set the bar in terms of how information should be maintained.
The Group continued discussion on all that assurance entails, beyond the identification/registration aspects, e.g., various attributes. Currently, there is no way to package identification/registration, etc. up with the identifier to have a high-level authentication assurance that did not require much assurance on particular attributes. This would be preferable to presenting the Service Provider with a list of assurances for each of the attributes of a person’s unique identifier.
These issues point to the need for a global identity management that can scale; multiple personal attribute authorities will be key. {Bill} spoke of their current work, where identity is essentially two parts: 1) physical (i.e., same authentication each time) and 2) personal attributes (i.e., name, affiliation with institution, etc.) Critical issues will be handled in ways not addressed by the draft proposal.
{Bob} further discussed the complexities of scope. It is impossible to quantify who might be saying what and how. Still, it is better to have modest progress on the few known entities, as opposed to pausing in wait of a total solution. Assurance ought to be capable of layering atop existing policy.
{Keith} summarized the 2 main use cases: 1) Blackboard, and 2) caBIG and multiple IRBs. Further discussion is needed to explore what is just the beginning of many scenarios and use cases.
A service, such as Blackboard, may be made available to anyone in a federation, though it still may not have the required authorization. How to provide the source of record necessary to move forward? It soon becomes evident that a multiple attribute authority is needed. The challenge is to make the [process] of accessing of restricted resources as simple as, e.g., doing public web pages, while at the same time protecting privacy.
The authentication aspect is much less a concern than is the idea of how to consume attributes. Open-ended statements about attributes could be problematic. Shibboleth presents attribute release as well as attribute acceptance policies. This is to accommodate various Service Provider requests, which never will be the same.
{Keith} captured the vast problem space by saying it will be good to identify some of its boundaries; a complex use case will enable others to take part in its solution, while the MACE-Dir Working Group can continue its focus on the practical items.
- Discussion of Cantor redraft of attribute profiles document-
For {Scott’s} recent version of the attribute profiles document, see: < http://middleware.internet2.edu/dir/docs/draft-internet2-mace-dir-saml-attributes-200711.pdf >.
This draft can be viewed with revisions marked < http://middleware.internet2.edu/dir/docs/draft-internet2-mace-dir-saml-attributes-200711-diff.pdf >. {Keith} described this as a win for not treating ePPN as an attribute, i.e., sending an ID is not the same as sending attribute statements. {Scott} announced that there will be a newer draft forthcoming.
The next MACE-Directory Working Group call will be held on Monday, December 3, 2007 at 4:30pm EST.