MACE-Dir WG call October 23, 2006
*Participants*
Keith Hazelton, U. Wisconsin - Madison (chair)
R.L. “Bob” Morgan, U. Washington
Tom Barton, U. Chicago
Scott Cantor, Ohio State U.
Will Norris, USC
Brendan Bellina, USC
Steve Olshansky, Internet2
Jessica Bibbee, Internet2 (scribe)
New *Action Items*
[AI] {Keith} will draft a query to the MACE-Dir and EDUCAUSE Identity Management lists regarding campuses’ current handling of LoA.
Carry-over *Action Items*
[AI] {Keith} will draft a document covering registered MACE entitlement values. (11-Sep-06)
[AI] {Nate} will send a link to his attribute aggregation developmental work. (28-Aug-06)
[AI] {Group} will draft a proposal for InCommon to clarify MACE-Dir efforts. (31-Jul-06)
[AI] {Keith] will raise discussion on the next InCommon Technical Advisory Committee call about the role of MACE-Dir efforts in the Information Model. (31-Jul-06)
[AI] {Keith} will revisit the mailing list archives to mine for possible uses cases. (31-Jul-06)
[AI] {Keith} will begin work on eduPerson (2007??). (31-Jul-06) [AI] Group will review the work on eduCourse and give feedback on how to proceed similarly or otherwise. (31-Jul-06)
Future *Agenda Topic*
– MACE -Dir & EDUCAUSE – how might/should they work together on IdM issues?
*Agenda*
1. Level of Assurance use cases and how our institutions plan to handle them
2. The semantics of existing edu* attributes with "scope"
- eduPersonPrincipalName
- eduPersonScopedAffiliation
- eduCourseMember See: http://middleware.internet2.edu/courseid/docs/internet2-mace-dir-courseid-educourse-ldap-200507.html
3. Clarifying the purpose of edu* schema work
*Discussion*
{Keith} opened discussion with a request for the Group to share their campuses’ perspective with respect to Level of Assurance. He is most interested in real use cases stemming from actual experiences. Which problems are people facing on campus today, which issues are forcing schools to address the level of assurance practice?
{Tom} said there are some level of assurance requirements at U. Chicago, but these are not the same requirements at runtime for attributes. Currently, it seems they will have a need for 3 level of assurances: 1) baseline (email), 2) security policy (biosciences), and 3) restricted access (administrative applications). The bio-sciences department is doing their own policy, as the baseline does not meet their requirements. As there are financial drawbacks to running this separately, they would like to incorporate all three under a single system. A review of their current practices has helped identify areas to improve or practices they would like to discontinue. While these ideas are rolling, specific actions are considered part of a longer-term project.
{Brendan} shared their current ideas around level of assurances at USC. They are now having people use their USC ID and a number issued on a payroll stub, for setting a password. This is another measure to ensure that the people are physically who they state they are, as opposed to a person simply knowing a user’s date of birth. They are considering the use of a Shibboleth-protected Enterprise account where the user must present something they have been given. If this is given correctly, it would indicate a greater degree of assurance. This may not meet the same standards for level of assurance, so ‘degree of assurance’ at least provides another mechanism to ascertain identity.
[AI] {Keith} will draft a query to the MACE-Dir and EDUCAUSE Identity Management lists regarding campuses’ current handling of LoA.
The Group discussed the semantics of existing education* attributes with “scope”. {Keith} posed a question to the Group regarding whether or not they are committed to constrained semantics with respect to scope. Should they insist on the exact definition of a value, or would there be more benefit in allowing others to use values as best fits their institutional demands?
{Brendan} does not think it should have a restricted value. A likely situation is a school whose primary language is other than English, and they would want their values to not be limited to words that might only apply in an English environment. Even if there was an agreed upon standard, it still may not be sufficient. He said the standard should offer an institution flexibility beyond the vocabulary, as long as it does not put the constrained vocab in jeopardy. He feels there would be a greater benefit in remaining open.
{Scott} presented the counter-point that without restriction, it may give rise to 2 communities using a single value for two distinct purposes. {Brendan} was still convinced that this possibility was less risky than a restricted vocabulary. {Tom} was concerned about conflict in the long run if the vocabulary is not restricted. He also suggested that three dimensional data not be pushed into a flat string and that the “@” relationship delimiter stick to 2 entities.
Affirmative Statements Stemming from the Discussion:
- Do not predefine semantics, but rather that these attributes would be essentially scoped to allow us to make an association between person and another entity, on either side of the “@”.
- New values, e.g., SuperStudent, could be floated to the community as a statement for review
[AI] Group will put Schema Harmonization item on agenda for Member Meeting MACE-Directory BoF.
How do we handle situations where the information is more highly structured than scoped attributes? {Keith} expressed interest in understanding what is being done in Europe and also how the SAML community would handle this problem. {Scott} suggested that bringing someone over from the SAML community could offer insight into this particular problem. In order to avoid embedding XML in SAML assertions, the Group discussed base 64 encoding it, then leaving it in an application to ‘re-hydrate’ in XML.
The upcoming MACE-Dir Working Group call on Monday is cancelled in advance of CAMP. Therefore, the next MACE-Dir Working Group call will be held on Monday, November 20, 2006 at 4:30pm EDT.