MACE-Dir WG call
May 7, 2007

*Participants*
Keith Hazelton, U. Wisconsin-Madison (chair)
Etan Weintraub, Johns Hopkins
Paul Hill, MIT
Scott Cantor, OSU
Tom Barton, U. Chicago
Tom Scavo, NCSA
R.L. “Bob“ Morgan, U. Washington
Steven Carmody, Brown U.
Ann West, EDUCAUSE/Internet2
Michael Gettes, Internet2
Steve Olshansky, Internet2
Jessica Bibbee, Internet2 (scribe)

New *Action Items*
[AI] {Keith} will post a question to SCHAC list regarding their definition of user status.
[AI] {Keith} will model (BPMN) common lifecycle of groups, life stages of groups, grace periods, etc., soliciting ideas from the MACE-Dir list.
[AI] {Keith} will pose the issues surrounding SAML attribute profiles to the mailing list, including arguments for using flattened URNs vs scoped attributes in the Shib 1.x sense.
[AI] {Keith} will kick-start a (longer-term) request queue for open issues, such as recommendations for practice regarding defining of entitlement values, including scenarios such as institutional internal use, vendor Service Provider working with customer community, maybe research projects, etc.

Carry-over *Action Items*
[AI] {Brendan} will review archives related to eduAccount and search for interested folks, eventually arranging a call focused on formulating the right questions to target a solution. (26-Mar-07)
[AI] {Keith} will draft a document covering registered MACE entitlement values. (11-Sep-06)

Future *Agenda Topic*
- c (country) attribute (c.f Tom Scavo’s email, 22-Jan-07)
- Levels of assurance of credentials and of authentication events: getting a handle on the problem
- IETF RFC &/or ITU X.520 standardization of edu* attributes; X.521 standardization of edu* object classes. Guidance on what ePEntitlement registry doc should cover.
- Liaison with identity gang work: what form, who,...
- Begin a persistent queue of open areas of potential work on wiki, e.g.,
 .1 localEduPerson OC, attributes; affiliation sub-types and roll-ups
 .2 Collaborative use, evolution of SCHAC userStatus
 .3 coordination with SCHAC generally
- Use of the wiki to expand; starting with discussion topics on this call.  Subscribe to RSS feeds on changes to wiki pages vs. email as only e-forum for MACE-Dir work.  Keep mace-dir list plugged into all work areas wiki or not.

*Agenda*
1. Group management issues
2. SAML attribute profiles
Cf. Scott Cantor's email of 22-Apr: "Scoped attribute and naming compatibility" and the discussion under the last heading ("MACE I2MI attribute profiles for SAML") in notes from the MACE-Dir WG at the Internet2 Member Meeting: <https://spaces.internet2.edu/display/macedir/MACE-Dir+Bof+Notes>

*Discussion*

The Group agreed that it would be best to aim for a typical Working Group call to last 60 minutes, as opposed to 90 minutes.

-Group Management Issues-
Refer to the discussion under first heading in notes from MACE-Dir WG at the Internet2 Member Meeting: <https://spaces.internet2.edu/display/macedir/MACE-Dir+Bof+Notes>

{Keith} reemphasized that the MACE-Dir Working Group is doing important work, evidenced by the multiple attributes and models for carrying groups affiliation on group entries, not to mention the multiple ways of doing member information.

{Tom} mentioned looking at SCHAC and their ideas around user status. It might provide a viable option without needing to make eduPersonEntitlement roomier and calling everything a group memberships. His point was that there should be distinction between that which has appropriate attributes and groups that you manage.

The group reached consensus they did not want to present an absolutist approach with the use of isMemberOf, by saying that anything that could be called a member of a group ought to use isMemberOf. If there is an attribute that looks semantically correct, use it, but bear in mind implementation issues. {Tom} reminded the group that choosing one path to follow might raise another set of maintenance issues not fully understood at the moment of choosing. For example, the class level idea might point to isMemberOf, but later, may realize that you have to use group memberships.

{Ingrid Melve} of FEIDE posed a question about how to represent class level: should she use a value of eduPersonEntitlement that would carry the class level. {Keith} suggested using isMemberOf, as it looked to be a group. However, {Tom’s} proposal is to use the SCHAC user status, where there seems to be a better fit. [AI] {Keith} will post a question to SCHAC list regarding their definition of user status.

{Keith} offered the following site for reference, but commented it did not offer as much information as he had hoped: <http://www.terena.org/registry/terena.org/schac/>

[AI] {Keith} will model (BPMN) common lifecycle of groups, life stages of groups, grace periods, etc., soliciting ideas from the MACE-Dir list.

-SAML attribute profiles-
Refer to {Scott Cantor's} email of 22-Apr: "Scoped attribute and naming compatibility" and the discussion under the last heading ("MACE I2MI attribute profiles for SAML") in notes from the MACE-Dir WG at the Internet2 Member Meeting: <https://spaces.internet2.edu/display/macedir/MACE-Dir+Bof+Notes>

The current SAML attribute profile doc: <http://middleware.internet2.edu/dir/docs/internet2-mace-dir-saml-attributes-200604.pdf>

There are several questions around how to properly modify Internet2-MACE-Dir SAML attributes 200604, and how to resolve the dilemma that {Scott} presents. To what extent do these problems go away with the coming of Shibboleth 2.0 and SAML 2.0? {Scott} said that in addition to some large vendors not supporting it, it may or may not pose a problem. If moving to SAML 2.0 assertions, there might still be issues around attribute naming in the next generation of the problem. However, he did say that most issues with interoperability are likely to go away with the 2.0 versions.

{Keith} said that under 1.3, it is not possible for an Identity Provider to support both the Active Directory Federation Services (ADFS) as Service Provider and non-Shibboleth SAML Service Provider in the same way. He asked about the likelihood of a use case having an Identity Provider where ADFS and non-Shibboleth SAML would need to do that in v1.3. {Scott} said that the pre-defined attributes offered by ADFS would not conflict with any attributes we have defined. He assumes that you are talking to someone using eduPerson attributes or LDAP, which is being pushed in the UK. He said the Shibboleth case is common.

{Scott} said he’s trying to come up with a best-of-the-bad-lot work around, which wouldn’t require fixing bugs in older software. His proposal is to use new names; new names that would not collide in the Identity Provider policy, nor with confusion over which version of attributes were being released. {Keith} said in the case of a Shibboleth Identity Provider and Service Provider, the eduPersonScopedAffiliation would have an attribute value of scope=.edu. {Scott} said that having Shibboleth on both sides would not require additional actions. If you are using a non-Shibboleth product on either end, instead of eduScopedAffiliation, you would pass the entire attribute value in flattened syntax. He is proposing not a deletion of old attributes, but an additional set that would help to standardize. This could imply the adding of new language, the changing of some rules, and perhaps another attribute definition for eduMember.

{Scott} said that in practice, it may not matter how confusing a set of names is, due to the fact that using URIs for names and actual profiles for names is a foreign concept itself for some. He is trying to figure out if anyone is interested in coming out with a set of rules to be followed in these scenarios.

The group discussed scope and how it may need to be added to more attributes. {Keith} referred to the UK, where one Identity Provider would be speaking for hundreds of institution. Perhaps it would use eduPersonScopedEntitlement. {Michael} asked the group if the Group was worrying about cases that would not happen. {Michael} thought including scope in the URN, and not actually creating a new attribute would be simpler than using eduPersonScopedEntitlement. This idea may lead to further discussion on the mailing list, as there are likely different perspectives. {Scott} said he is less interested in eduPersonAffiliation, which is used more with ePPN. He has tried to convince some to invest in scope, saying that if they trust the Identity Provider, they ought to trust the scope. However, if they trust the Identity Provider to assert something, they still are not willing to trust that it will not assert bad things.

[AI] {Keith} will pose the issues surrounding SAML attribute profiles to the mailing list, including arguments for using flattened URNs vs scoped attributes in the Shib 1.x sense.

[AI] {Keith} will kick-start a (longer-term) request queue for open issues, such as recommendations for practice regarding defining of entitlement values, including scenarios such as institutional internal use, vendor Service Provider working with customer community, maybe research projects, etc.

The next MACE-Dir Working Group call will be held on Monday, May 21, 2007 at 4:30pm EDT.