New *Action Items*
[AI] {Keith} will draft a document covering registered MACE entitlement values.
[AI] {Tom S.} will send a link to a wiki topic with a description of the nanoHUB use case.

Carry-over *Action Items*
[AI] {Von} will prepare a summary of the upcoming TeraGrid meeting and share on the mailing list. (28-Aug-06)
[AI] {Nate} will send a link to his attribute aggregation developmental work. (28-Aug-06)
 [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. (14-Aug-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 ask {SteveO} to revisit the mailing list archives and mine for possible uses cases for trusted email addresses. (31-Jul-06)
[AI] {Keith} will begin work on eduPerson (2007??). (31-Jul-06)
[AI] Group will review the work on eduCourse as model eduPerson 2007 and give feedback on how to proceed similarly or otherwise. (31-Jul-06)
 [AI] {Keith} will work with {SteveO} to simplify the URN MACE and OID registry page. (27-Mar-06)
[AI] {Keith} will contact (Walter Hoehn and Jon} about contributing towards Nexus requirements regarding provisioning. (27-Mar-06)
[AI] {Bob} will email the list with an additional document containing registered entitlement values. (13-Mar-06)

Future *Agenda Topic*
– MACE -Dir & EDUCAUSE – how might/should they work together on IdM issues?

*Agenda*
1. Information needs of Grids:
   a. Report from TeraGrid meeting (Tom?, Von?)
   b. Report from European Grid for E-Science (EGEE Design Team) meeting (Keith)
       i. Pull (late attribute value binding) vs. Push (early attribute value binding)

          in SAML scenarios, especially in multiple job-spawning grid workflows
2. Crafting entitlement values in federated scenarios: good practices and bad
3. Level of Assurance use case/usage scenario template

*Discussion*
The Group discussed assertions of attributes beyond the Shibboleth Classic scenario. Given that a Service Provider picks up assertions from the Identity Provider and further sends them down the line to other services, {Keith} asked 'who may authoritatively say what', with respect to aggregating attributes or data from multiple speakers. {Tom Barton} wanted to know which information is used to manage the use cases; there are 2-3 attributes that stem from the TeraGrid use cases; the matter is not simply how attributes should be moved from the source to the point of consumption. {Nate} offered that this is dependent on the trust relationships involved, though it is further dependent on how each of these entities will decide to trust each other.

{Tom Scavo} shared details of a use case involving nanoHUB <http://www.nanohub.org/>, pushing attribute certificates to a GRID Service Provider: <https://authdev.it.ohio-state.edu/twiki/bin/view/GridShib/NanoHUB>. There, you will find a description alongside diagrams detailing the GridShib attribute pull and push. This will be of importance as a prototype TeraGrid use case, as well as provide useful information to the MACE-Dir working group. {Keith} summarized this discussion as representing the concerns around delegation; when the portal (nanoHub, ScienceGateway, etc.) is trusted by the grid resources behind it, and then we are not dealing with delegation.  It is IdP to Portal (SP); then a separate trust behind the portal to grid resource exchange.

{Scott} also discussed how the relying party needs to trust the data or show concern over whether or not that data is trustworthy. The Identity Provider cares about dissemination of the data and that that this piece of information was passed from point x to y. It is dependent on the Grid Service Provider as to who it will trust. The Service Provider needs to have trust established with the portal itself, not just that the portal is packaging information from a trusted Identity Provider. {Tom S.} expressed that there is a need to let campuses have a choice in allowing campus credentials to be used in the Grid environment.

{Scott} also expressed that the Identity Provider might be concerned about where the information is being sent to, that there should be a way to track when and to where their information is sent out. If the portal joins InCommon, this might be accomplished. To say that the Service Provider alone is responsible for treating the information with care is not enough. This raises the need to clarify whose role (InCommon's or other's?) it is to ensure that information is being passed by portals in a known way. Where does the responsibility for transmission of this data lie, and how to maintain this accountability? Discussion of this topic will continue in subsequent working group calls.

{Tom B.} mentioned that of 1000 potential gateways, 900 are likely to be campuses. This indicates both  (1) the anticipated scale of engagement by TeraGrid via such gateways, and (2) that the majority of them are expected to be operated by campuses and a minority operated as one aspect of specially funded research initiatives. These points should be remembered as gateways take on an ever active role in campus operations.

{Bob} shared an interest in current discussion around identity schemas in the Identity open space. There seems to be a shift from information in identity schemas to information models to SSL. Further information is available at: <http://Identityschemas.org>.

The next MACE-Dir Working Group call will be on Monday, September 25, 2006 at 4:30pm EDT.