*MACE-Dir Conference Call* March 14, 2005

*Participants*

Keith Hazelton -- Wisconsin (chair)
Tom Barton -- Chicago
Brendan Bellina -- USC
Scott Cantor -- OSU
Ido Carmi -- USC
Craig Hancock -- Notre Dame
Paul Hill -- MIT
Walter Hoehn -- Memphis
Bob Morgan -- Washington
Steve Olshansky -- Internet2
Ann West -- EDUCAUSE/Internet2
Nate Klingenstein -- Internet2 (scribe)

*Discussion*

In keeping with the loose modelling of MACE processes on those used by the IETF, Bob suggested an approval process similar to that of clearing a working group into an IETF-wide request for comments, followed by an
intense review by the IESG. The main gap is a functional route for review calls out to the entire Internet2 Middleware community. The MW-Discuss list intended for a purpose such as this has been largely un-utilized, so Bob suggested MW-Announce as one option.

courseID Approval

The group spent some time reviewing the finalized courseID documents. eduAux, a general-purpose object class proposed to carry attributes for inclusion in various directory entries, would be the holding body for two of the primary attributes coming out of this effort. It was suggested this object class could additionally carry attributes for other projects as they move into more permanent homes such as eduPerson or eduOrg.

Bob had a request for additional guidance to deployers; the best way to deploy eduCourse in both a finalized state and in terms of progressive roll-out is unclear from just reading these documents. The general suggestion is that eduCourseMember is the only attribute recommended for person entries. It is possible to assert detailed roles here, but in many circumstances member@courseidentifier will suffice; again, additional guidance to deployers would be valuable here.
Keith intends to have this work finalized in time for NMI's 7th release.

SAML Bindings of Scoped MACE-Dir Attributes

Many attributes defined by MACE-Dir require proper scoping to have any real meaning in an inter-realm context. This scope can be expressed in multiple ways in SAML XML formation; either as a separate Scope attribute, or in the more traditional value@domain form. MACE-Dir plans on issuing separate recommendations for SAML 1.x and SAML 2.x. These expectations are framed around many of these attributes being primarily intended for LDAP and the desire to adhere to the relevant SAML x.500 profile.

However, MACE-Dir heard a recommendation from Scott, a primary contributor to the SAML effort, a recommendation that the Scope attribute not be used, which surprised Bob, who felt that use of Scope had been directly encouraged. Scott's most direct response was that scoped attributes had caused nothing but problems for people, to which Bob replied, "Okay, that's a better answer." The possibility that even more problems will be caused by abolishing it was considered. "Scopeness" has distinct policy meaning defined in the SAML schema, so
its use, for example, to express scopes for course identifiers, would come with pre-defined policy implications. Its use is more a matter of perception than a question of precisely how information should be bound to the wire. Agreement was reached that use of the Scope attribute will be recommended against in the future.

SAML Attribute Names

SAML 2.0 will include a mechanism to handle friendly names for attributes named with URN's. Tom's resolution is that there is no need to explicitly reaffirm support of SAML 2.0's x.500 attribute representation in the bindings document, but that there is a need to indicate the friendly names preferred for MACE-Dir-defined attributes. Recommendations on value syntax will be delayed.

The immediate goal will be to define MACE-Dir's SAML bindings for version 1.1. This will simply be the shape urn:oid:<oid>, with no defined friendly name. Scoped values will still be used when appropriate, and the attribute-def space will be updated to reflect its deprecation. Shibboleth has no opinion as to what names are used; it's a simple matching that is performed, and there is no distributed attribute metadata.