*Participants*

Keith Hazelton -- Wisconsin (chair)
Tom Barton -- Chicago
Brendan Bellina -- USC
Scott Cantor -- OSU
Ido Carmi -- USC
Jeanette Fielden -- Internet2
Renee Frost -- Michigan/Internet2
Richard Goerwitz -- Carleton
Digant Kasundra -- UTA
Jason Hardy -- UTA
Shelley Henderson -- USC
David Hunter -- UTA
Bob Morgan -- Washington
Todd Piket -- MTU
Ann West -- EDUCAUSE/Internet2
Nate Klingenstein -- Internet2 (scribe)

*Discussion*

courseID Draft Documents

The only change Keith made pursuant to the last call was to eliminate the text defining eduAux. He cited the greater pain involved in defining a fundamentally structural object class and put it off until there was an
immediate need. Given that all information that would have been contained in eduAux collectively meant the object defined was very "course-like", these have been rebundled into a new eduCourse object class. It is still auxiliary but can contain anything devised for courses.

Tom also solicited additional ideas on how and where documentation could be created in order to guide campus deployment of eduCourse. Many things that such documentation might discuss have not been evaluated yet: work hasn't even yet begun on where in the DIT eduCourseOffering objects belong, for example. The meaning of all this in a broader institutional data model has only begun to be discussed.

The most immediate deployment may be that of UTA, where they want to quickly intregrate eduCourse into their directory in addition to the fact that they're rolling out PeopleSoft as well. The representatives on the call suggested something like a good case study would serve as the best basis to guide these decisions, which Tom turned around to ask, would UTA "flounder about publically" and develop such a case study with guidance and ample question responses from MACE-Dir?

[AI] UTA agreed to contribute their deployment of eduCourse as a case study.

There was brief discussion about the indexing recommendations, and just how strong these recommendations were. "Whatever it is, it ain't a must," decided Keith, and it's meant as non-normative advice. The language will be clarified to that effect.

PeopleSoft Integration

There was a brief discussion on the various ways to integrate PeopleSoft with the rest of the enterprise middleware infrastructure, including a CMS, which together is just "no end of fun." Given that each of these components likes to install its own information model, mutating them to the point where they share a common data model is notoriously difficult. The most common behaviour is to simply perform nightly dumps out of PeopleSoft into the middleware layer from which other applications can pull information. UTA is taking a more ambitious approach, hoping to put a sufficient number of triggered events in the implementation to take a subset of the enrolment data and pass it directly into the directory from which WebCT would feed.

SAML Bindings

Greater closure was reached on this call regarding the binding of MACE-Dir-defined attributes to SAML representations to allow this information to be passed over the wire by systems such as Shibboleth. The use of primary OID naming for these attributes for SAML 2.0 is well agreed-upon, but deciding what to use until then, particularly in light of current deployments and avoiding creation of any further non-OID names, is more difficult. The lack of rhyme and reason some of this may lead to made Scott suggest "the binding has to be pretty frank about why attributes are handled the way they are" to avoid confusion. The service provider can be liberal in the names it chooses to accept, but identity providers must pick a particular name to choose and send. There is a stated desire to make this decision as simple as possible. The primary requirement to make this happen is the aforementioned for SAML 2.0 and one binding per attribute for SAML 1.x. The real decision is regarding the new attributes such as isMemberOf, eduCourseOffering, and the perennial hard case, eduPersonTargetedID, which was never formally addressed. The latter "accidentally became a scoped attribute," elaborated Scott, but this is not likely to persist. It will be a nameID in SAML 2.0, but there may still be instances where it will be passed as an attribute as well. The goal is to use the same XML encoding in either case.

*Action Items*

1. UTA will detail their use of the courseID data model, PeopleSoft, and the enterprise middleware structure as a use case for subsequent deployments to consult.