**MACE Call 11-October-2010**

**Attending**

RL "Bob" Morgan, U. Washington (chair)

Ken Klingenstein, Internet2

Rodney McDuff, U. Queensland

Renee Shuey, Penn State U.

Keith Hazelton, U. Wisc. - Madison

Scott Cantor, The Ohio State U.

Renee Frost, Internet2

Tom Barton, U. Chicago

Neal McBurnett, Internet2

David Wasley, independent

Steve Olshansky, Internet2 (scribe)

NEXT CALL: 25-October-2010

*New Action Items**

[AI] (Keith) will maintain an issues list to inform a potential new charter for MACE-DirNG, syncing it with the FedApps charter.

*Carryover Action Items*

[AI] (RLBob, Scott, and SteveO) will proceed with the process of formalizing the FedApps working group, including setting up a list/wiki/website, and advertise it in the appropriate venues.

[AI] (Ken) will draft a one-pager about what MACE does and what questions it has, for review by MACE, as a discussion guide with Internet2 leadership.

[AI] (Ken and ReneeF) will look at the Fall I2MM schedule to see if there is an opportunity for a F2F meeting between MACE and Internet2 leadership.

[AI] (All) if interested in supporting MoonShot activities, send mail to Ken and subscribe to appropriate lists TBD. There may be some funding available to support travel, e.g. to IETF meetings...

[AI] (Ken) will distribute a draft requirements framework for VO support engagement

[AI] (David) will contact GSA for an update on the approval process for InCommon Silver.

[AI] (ReneeS) will revisit the list of potential new MACE members on the list.

[AI] (All) Send input to Ken about how the InCommon cert service ought to be packaged - i.e. amendment to existing InCommon contract, or other.

[AI] (Ken) will revise the mission statement based upon feedback received on the call.

[AI] (Ken) will send out info on DHS secure online transactions

[AI] (Ken) will follow up on a MACE/AMSAC call.

[AI] (Ken) will follow up with Kuali/Rice about I2MI collaboration.

[AI] (Ken) will draft a catalyst doc, covering the key items to be addressed in advising VOs how to use our infrastructure.

[AI] (Leif) will contact Ken/Steven/Tom about potential overlaps between the SDCI proposal and projects in the EU.

[AI] (Leif) will discuss the IDTrust meeting on the PKNG list, seeking feedback.

[AI] (Jens) will speak to an Eduroam rep about communicating with Educause.

[AI] (Ken) will draft and circulate a letter to Rice leadership, requesting input to roadmaps and use cases, and to ensure our projects with Kuali projects are aligned with their high-level strategic direction.

[AI] (Nate) will distribute information to the list about upcoming tactical issues facing MACE

[AI] (All) send Bamboo IAM comments to Tom ASAP for coordination.

[AI] (All) interested in participating in the international collaboration activity contact RL "Bob."

[AI] (RL "Bob") will contact a representative of Kuali Rice about coordinating a call.

[AI] (Ken and Mark) will distribute some information on trust anchors in the context of dynamic network configuration in GENI testbed, as well as for general access control.

[AI] (Ken) will circulate some meeting notes from the last TERENA/ REFEDS meetings.

**Discussion**

- Attributes

Some ideas for potential re-charter work items:

* abstracting eduPerson from LDAP,

* affiliation vs group-membership vs entitlements

* representing attribute assurance and/or provenance

* assessments of attribute usage in real deployments

* attribute descriptions supporting user consent

The MACE-Dir working group's scope has grown beyond directories, into other federation-related areas. A reinvigorated scope to include attributes would be a good complement to the new FedApps working group that will be spinning up.

When a federation develops attributes, at what point should they be promoted to generalized schema such as eduPerson? Since anyone can use any attribute found to be useful, would they do so without the imprimatur of inclusion in a widely recognized formalized schema?

What are the real overarching problems to be addressed? Where are the places that we are likely to cause some sort of harm or confusion by defining a particular attribute(s)? Pragmatism needs to be balanced with idealism...

The Australian Federation persistent identifier was raised as an example of one that might have broader use in other federation contexts. Would there perhaps be incompatibilities in how these persistent identifier are named or used? "Persistent" in this discussion is taken to mean cross-organizational reusable identifiers. In a national grid context such as in Australia, guaranteeing that attributes could not be reassigned is important, but this is found in ePTID.

The use case in Australia was simply to distinguish one John Smith from another. They use an opaque identifier which is asserted with other identifiers to accomplish this.

Q: Why would EPPN not serve this purpose?

A: They needed this attribute to be transportable across domains, and follow the user as s/he moves around.

Q: Wouldn't this recreate the SSN problem?

A: Perhaps...

Vocabulary: is "persistent" different from "permanent." Do we need a glossary? It was observed that "permanent" does not appear on eduPerson.

Naming and syntactic divergence can both be problematic, but syntactic divergence is potentially a bigger problem especially in the context of automation.

It was noted that NIH is apparently assembling a "tiger team" to tackle attributes in their context, although the scope and ultimate purpose is not yet known.

eduPerson has become a useful standard worldwide, although it is in some ways US-specific. Should future work in this arena be homed in an international body, e.g. REFEDS? Wherever there seems to be energy and the right participation would be fine, but the critical mass for the moment would seem to be under MACE. Thus MACE-DirNG would seem to be an appropriate home, at least for now.

How can MACE encourage adoption of any new schema outside our community, e.g. in the commercial sector? "edu*" naming can be a hindrance, at least in terms of external perception.

Shared Assessments (sharedassessments.org) was referenced as an example of a community doing shared work. Do they define a common vocabulary?

It was noted that the InCommon TAC is publishing attribute profiles, connecting attribute usage to use cases.

It was proposed that the MACE-Dir session at the upcoming Fall Internet2 Member Meeting be used to discuss the re-charter, and then continue the discussion on their mailing list.

[AI] (Keith) will maintain an issues list to inform a potential new charter for MACE-DirNG, syncing it with the FedApps charter.

The subject arose of "translating" the attributes used for uApprove. Are there common "bundles" of attributes that typically are released together? Is there a need for better descriptors for the properties of desired identifiers? Would this be the role of a glossary?

Since EPPN is readable, if it is usable then that would seem a logical starting point, but if not we should perhaps work harder to encourage the use of ePTID.

Q: Would this be a conversation that needs to happen inside a federation, or more globally?

A: Globally...

When an IdP is engaged in discussions with an SP about setting up a new service, attributes are obviously included. Reusing existing attributes is obviously preferable than inventing new one. SPs can be overwhelmed with the details of setting up a service, and often once a service is operational it's configuration is seldom revisited without some extenuating circumstance.

One desired outcome is whether InC-Steering ought to be advocating for the use of particular attributes (e.g. ePTID). This led to the discussion of InCommon potentially developing deployment materials aimed at steering the participants to adopt certain practices.