New *Action Items*
[AI] {Keith and Jessica} will draft a use-case template regarding support for multiple levels of assurance and will schedule a call with {Tom}. Those who would like to volunteer ideas/content for a use case should email the MACE-Dir mailing list.
Carry-over *Action Items*
[AI] {Group} will draft a proposal for InCommon to clarify MACE-Dir efforts. (31-Jul-06)
[AI] {Keith] will raise discussion on the next InCommon Technical Advisory Committee call about the role of MACE-Dir efforts in the Information Model. (31-Jul-06)
[AI] {Keith} will revisit the mailing list archives to mine for possible uses cases. (31-Jul-06)
[AI] {Keith} will begin work on eduPerson (2007??). (31-Jul-06)
[AI] Group will review the work on eduCourse and give feedback on how to proceed similarly or otherwise. (31-Jul-06)
[AI] Keith will email the list with a summary of recent developments in the eduPersonEntitlement space.
[AI] {Keith} will work on simplifying the URN MACE and OID registry page. (27-Mar-06)
[AI] {Keith} will contact (Walter Cohen and Jon} about contributing towards requirements. (27-Mar-06)
[AI] {Bob} will email the list with an informative sentence regarding an additional spec. (13-Mar-06)
[AI] {Steven Carmody} will write up use cases on requirements for provisioning systems, and send to {Walter}. (9-Jan-05)
Future *Agenda Topic*
– MACE -Dir & EDUCAUSE – how might/should they work together on IdM issues?
*Agenda*
1. An additional work item for 2006 (an oldie, but a goodie)
- Attributes from multiple attribute stores (affectionately known as the IEEE membership scenario)
- A couple seed use cases to follow before the call
- One place this is coming up is support for VOs in a Grid+Shibboleth environment
2. Sketchy, seed use cases on the elements needed to support multiple levels of assurance (LoAs) in the Identity Provider - Service Provider interaction
3. Dividing work duties appropriately TAC-InCommon (cf. Keith's email 14-Aug) Keith emailed the Group
*Discussion*
{Keith} raised a long-standing issue of attributes from multiple stores in a given service exchange. An example draft use case was shared on the mailing list (cf. email 14-Aug), detailing a radio-astronomy observatory being exposed as a grid resource: a designated subset of members of the "Stellar Nursery" virtual organization are authorized to schedule, control, and acquire data from the observatory if they are current faculty or graduate students in good standing at an identified set of universities.
- How can the observatory resource gather the attributes it needs from the VO and the
universities to make the allow/deny decision when someone requests online access?
- What arrangements are needed between the universities, the VO, and the observatory?
- Which are handled out of band?
- What is done over the wire and what is done via metadata?
{Nate} suggested that VOs may not need to maintain the actual principles, but that they would simply extend the information passed on by other institutions. {Scott suggested} that the use cases be as concrete as possible, i.e., beyond the data level and more about the user-flow. The focus ought to rest on the various alternatives, including pre- and post-conditions, e.g., the data and the links, as opposed to the solution - how that link is established, how it is used by which software, and where. The gap between existing standards and existing software needs to narrow, which can then be applied to these use cases. Beyond IEEE and the radio-astronomy example, there will be other situations where there is a need to manage too many policies in order to manage the information. A desired output of these efforts could take the form of best practices, in hope it is supported by others.
Following the upcoming TeraGrid event, [AI] {Keith and Jessica} will draft a use-case template regarding support for multiple levels of assurance and will schedule a call with {Tom}. Those who would like to volunteer ideas/content for a use case should email the MACE-Dir mailing list.
A request from {Keith} to gather use cases pertaining to the elements needed to support multiple levels of assurance (LoAs) in the Identity Provider - Service Provider interaction (cf. email, 14-Aug) led to other threads discussing the nature of the issue and its relevance. {David Bantz} from U. Alaska provided a number of real cases at UA. MACE-Dir is looking for additional business-function level descriptions describing possible support for multiple level of assurances.
Keith emailed the MACE-Dir and TAC-incident mailing list requesting feedback on whether there is a proper balance between roles and division of labor between MACE-Dir and InCommon (cf. email 14-Aug.) The current presumption is that InCommon looks to MACE-Dir for technical advice on information models, attribute semantics and syntax, and protocol bindings in support of federation activities. Are there additional implications stemming from the fact that InCommon is US-based and MACE-Dir is international? Feedback on this issue should be fed to the MACE-Dir mailing list until a more appropriate venue has been decided upon.
The next MACE-Dir WG conference call will be held on Monday, August 28, 2006 at 4:30pm EDT.