MACE-Dir WG call
December 18, 2006

*Participants*
Keith Hazelton, U. Wisconsin - Madison (chair)
R.L. “Bob” Morgan, U. Washington
Tom Barton, U. Chicago
Scott Cantor, Ohio State U.
Steven Carmody, Brown U.
Will Norris, USC
Brendan Bellina, USC
Renee Frost, Internet2
Ann West, EDUCAUSE/Internet2
Steve Olshansky, Internet2
[Jessica Bibbee, Internet2 (scribe)]

New *Action Items*
[AI] {Steve C.} will email the list with a URL to the UK production federation and a link for information on the definitions of “standard” attribute use.
[AI] {Steve C.} will connect the UK folks with the mailing list and ask Michael Kim at Ovid-Silver Platter to post there.
[AI] {Keith} will post a thread with discussion on members, and {Scott} will pass this on to folks in the UK.

Carry-over *Action Items*
[AI] {Keith} will draft a document covering registered MACE entitlement values. (11-Sep-06)

Future *Agenda Topic*
– Resurfacing of affiliation control vocabulary, stemming from recent discussion in Spain. 
– MACE -Dir & EDUCAUSE – how might/should they work together on IdM issues?

*Agenda*
1) eduPerson in an OWL (Web Ontology Language) representation many of our favorite LDAP person schema have already been given  OWL representations by the IdentitySchema wiki folks: http://idschemas.idcommons.net/moin.cgi/List_Of_Schemas

2) Persistent identifiers: clash between IdP realities (no unfunded external mandates, please) and expectation of some SP/Resource Managers (a globally unique identifier with an eternally valid mapping to a single real world person/entity)

3) How to indicate person-institution link in an outsourced Identity Provider representing tens of thousands of institutions (real world case in UK).  Hint: eduPersonScopedAffiliation is not a full-credit answer.

*Discussion*

-eduPerson in OWL representation-

The Group discussed reasons why they could continue with the current LDAP object class or why there may be sufficient reason to represent eduPerson in OWL. Using OWL opens the standing web approach and it also ties in with others across the world. The identity schema folks have produced OWL web ontology representations for underlying LDAP schema. MACE-Dir will likely have influence on whether others are quick to follow suit or not. {Keith} asked the Group to consider whether MACE-Dir should do more in this area, return to the idea later, or perhaps it may not be needed at all.

{Scott} commented that other projects with more priority should be addressed before really considering MACE-Dir's use of OWL. {Tom} said that there is value in making it more clear, value of the language to write a specification, and value of how profiling is done in different contexts. However, he said most of the eduPerson work would not benefit too much from putting it into OWL and documentation for profiling work in SAML also is in place. {Bob and Tom} agreed that there would be more value in using OWL for not just redoing what has been stated in LDAP, but for tying new schema or defining good practices, etc. in the future. Additionally, it might be of value if the Group wants to do something model-based, versus attribute X or attribute Y.

-Persistent Identifiers-

{Keith} described a conflict between Identity Provider realities and expectations of Service Providers; what is the incentive for Identity Providers to have requirements that they do not already have globally? However, Service Providers (e.g., in the GRID community) feel they most need a globally unique identifier with an eternally valid mapping to real world person or entity. Given this clash, should an Service Provider with set requirements have to work out any issues with the VO or representative from user community? Regarding problems with identifiers coming from campus infrastructure, there ought to be more communication. What MACE-Dir is not able or willing to fix, they will have to address it on their own.

In a previous discussion with TeraGRID, the request was for something that 1) they know, and 2) will not be reassigned (and thus revisited). {Keith} wondered if perhaps the issue may be dissolving as a result of these conversations. {Tom} said it is a question of policy whether an Identity Provider will engage in transmitting information; MACE-Dir might have input on how it can be expressed, if the Identity Provider chooses to do so. {Scott} believes privacy is still a top concern; if the goal is to mandate a particular degree of privacy –on either the Service Provider or Identity Provider side– options open up only when requirements are removed. {Bob} reminded that it will require time spent with local applications so they know what to expect when a change does occur. {Keith} suggested that this problem is serious enough to warrant an identifier recipe, etc. being placed on the priority list. {Steve C.} suggested a resulting matrix of possible identifiers and correlating properties, followed by explanatory text. This could be an accompaniment or support document to e.g., the eduPerson spec.

{Tom} asked if the recipe would include how to work with eduPersonTargetedID. {Scott} advised a closer look, saying that some identifiers are widely supported, while others are not. For example, the only identifier with any notion of non-reassignment is not supported. Use cases would be helpful, but will likely surface naturally. {Keith} said the fate of targetedID may be linked to privacy issues. {Steve C.} said the easiest implementation is to release an identifier that is mostly persistent and mostly non-reassignable; but how many are willing to release without concern to privacy? After 9/11, {John Markoff, NYT} concluded in an article that people are willing to give up privacy – for a price. {Keith} suggested a clarification of ePTID for the sake of its survival. Among the concerns, as {Tom} said, are user support and incident response requirements; how to meet these concerns is not clear. ePPN is not right, but there is no existing recipe for ePTID. {Steve C.} asked if campuses could look to the federation to solve this, such that a federation-imposed policy addressed the current privilege concerns.

{Keith} summarized the discussion on Persistent Identifiers with the following points: 1) identifier recipe needs work before it is launched, 2) {Tom’s} insight on TeraGRID requirements will be useful, and 3) {Steve C.’s} statement of the libraries’ interest.

-Person-Institution link in an outsourced Identity Provider on a large scale-

{Keith} shared a real world case in the UK where eduPersonScopedAffiliation may not fully address the situation: how to indicate person-institution link in an outsourced Identity Provider representing tens of thousands of institutions?

{Steve C.} added a comment about the production UK federation, which has published a set of guidelines on attribute. A question from a contact at Ovid-Silver Platter expressed interest in bringing entitlement discussion into line with the recommendations stemming from the different direction of the UK federation. [AI] {Steve C.} will email the list with a URL to the UK production federation and a link for information on the definitions of “standard” attribute use, (c.f. Steve’s 18-Dec-06 email):

UK production Federation: <http://www.ukfederation.org.uk/>

Info about the federation's definitions of "standard" attribute use can be found in
Chapter 3 of this document: <http://www.athensams.net/federations/athens-shib-integration1.0.pdf>

The mentioned outsourced Identity Provider is the Athens Shib Gateway. The document says scopedAffiliation is one of three attributes (entitlement is not one). The entityID is defending up to 30 thousand scoped values. The Service Provider would take the right hand side of eduPersonScopedAffiliation and determine which license to use. A note from {Ian Young} expressed that they are willing to talk and/or modify their approach if another more reasonable approach is discovered and presented. In an attempt to reduce financial strain, there is pressure now on eduPersonScopedAffiliation to put more things on the left side to address use cases.

{Scott} warned against pushing an argument on use of attributes when the battle is more about the implementation constraints. A likely reason for why they are pushing through affiliation is to make the code scale to hold thousands of scopes versus 30 thousand entities.

{Steve C.} suggested that as this discussion moves forward, they ought to figure out a process that has potential of creating a higher level of investment from dozen or more federations. Additionally, they could bring {Ian} into the discussion, along with others using Shibboleth. What is the best way to identify these people/institutions and furthermore, get them involved in the discussion? The trigger for this topic came from a query from Ovid-Silver Platter. If the UK federation goes one way, another federation yet a different way, there is a danger of everyone making their own path. {Scott} urged this discussion to move beyond a venue, but more so an activity. [AI] {Steve C.} will connect the UK folks with the mailing list and ask Michael Kim at Ovid-Silver Platter to post there.

[AI] {Keith} will post a thread with discussion on members, and {Scott} will pass this on to folks in the UK.

Another topic for the Group to discuss is the resurfacing of affiliation control vocabulary, stemming from recent discussion in Spain.

The following MACE-Dir Working Group call on January 22, 2007 will be canceled. Therefore, the next MACE-Dir Working Group call will be held on Monday, January 29, 2007.