**MACE-Dir Call 16-May-2011**
**Attending**
Keith Hazelton, U. Wisconsin - Madison (co-chair)
Mark Scheible, independent
Benn Oshrin, Internet2
Scott Cantor, The Ohio State U.
Todd Piket, MNSCU
David Bantz, U. Alaska
RL "Bob" Morgan, U. Washington
Ann West, Internet2
**Next two calls:
- In two weeks: **One-time switch from Monday (US Memorial Day) to Tuesday**: May 31, 2011 11:00 am EDT (GMT-4), PIN: 0179884#
- In four weeks: June 13, 2011 5:00 pm EDT (GMT-4), PIN: 0169152#
**Carryover Action Items**
[AI] (Keith) will issue a last call for eduPerson edits, beyond EPTID revisions, for inclusion in a forthcoming revision.
[AI] (Keith) will develop a Bamboo use case for persistent identifiers.
[AI] (Keith) will write up the current state of the identifier discussion and apparent consensus, and associated explanatory material, for use by REFEDs.
[AI] (Keith) will edit the previous versions of the SAML Attribute Profiles documents to note that they have been superseded by a newer version:
http://docs.oasis-open.org/security/saml/SpecDrafts-Post2.0/sstc-saml-attribute-x500-cd-01.pdf
http://middleware.internet2.edu/dir/docs/internet2-mace-dir-saml-attributes-200604.pdf
http://middleware.internet2.edu/dir/docs/draft-internet2-mace-dir-saml-attributes-20071202.pdf
http://middleware.internet2.edu/dir/docs/internet2-mace-dir-saml-attributes-200804.pdf
http://wiki.oasis-open.org/security/SstcSaml2AttributeX500Profile
http://www.oasis-open.org/committees/download.php/28042/sstc-saml-attribute-x500-cs-01.pdf
See also:
http://www.edugain.org/policy/edugain_policy_build20110124/attribute_profile_20101215.pdf
[AI] (RL "Bob") will query the REFEDs list about whether identifier reassignability is an issue for them esp. in grid environments.
[AI] (Keith) will take a first pass at revving http://middleware.internet2.edu/dir/docs/internet2-mace-dir-ldap-group-membership-200507.html in the wiki, then run it by the group for comment, with the goal of perhaps finalizing it in the near future.
[AI] (Brendan) will poll the mailing list for feedback on the use of name fields, and whether they have had the need to extend eduPerson locally with additional name fields.
**Discussion**
1. - Proposal: A way out of the worst consequences of eduPerson{Scoped}Affiliation divergence:
- Draft, vet and promote adoption of a "Profile of eduPerson for Federated Scenarios"
- https://spaces.internet2.edu/display/macedir/A+way+out+of+the+worst+consequences+of+eduPersonAffiliation+divergence
While the vocabulary is controlled in the spec, this is far from the case in actual use, e.g. with local affiliations added.
Should the spec be modified in some way to address this? E.g., should language be added to clarify that adherence to the controlled vocabulary is the only guarantee of interoperability? The reservations expressed about modifying the spec are that it would call undue attention to the fact that some are misusing this attribute, and/or make "illegal" what has become somewhat common practice. Thus it was proposed to develop a profile for the use of eduPerson in an inter-institutional setting, but it appears that this won't really solve the core problem.
The definitions of faculty and staff, and employee (as a superset of these), roles in the US, as opposed to elsewhere, appear to be a common scenario for modifying affiliation. For SPs, Shib enforces policy and ensures that only standard values are received, without deliberately modifying the SP in some way to change the default definition. While the definition of student is generally undisputed, the definitions of faculty/staff/employee may vary, along with "affiliate." Agreement on these roles may be difficult to achieve, and another option may then be to define a new OID, although it is questionable whether this would be the right approach.
Q: How common are national/regional variants of eduPerson, e.g. ukEduPerson, nordEduPerson, etc.? If we revise eduPerson, would these variants follow suit?
A: Unknown...
It was noted that there is more energy being expended on AuthN than on AuthZ at the moment, and thus this may not be an issue worth tackling until the focus shifts more to AuthZ.
Consensus on the call was to leave this as is, with no further action for now.
2. Thread "Composite Attributes" (started by Benn Oshrin 19-April on the MACE-Dir mailing list: "Correlation of roles via LDAP attribute description options").
Is there an agreed recommended approach? Or is the field wide open, with a variety of viable approaches?
It was noted that this is not an uncommon issue, and some solutions in the wild are not really optimal, thus a number of institutions would find clarity on this to be useful.
Scopes may not be the universal answer, so there would seem to be a need for another approach. How structured do you need to be with related data, so that it is machine processable? Scott suggested that while doing this in LDAP is fine, but the question of how to do this in SAML will immediately arise, so it would not be a good idea for MACE-Dir to approach this on the LDAP side in isolation.
With the current energy around JSON, how should that be factored into this? Can the ability to parse it be assumed universally? Using JSON Web Tokens (JWTs), which are essentially SAML statements in JSON, the assumption will be that the values are strings; cf.
http://self-issued.info/docs/draft-jones-json-web-token-02.html
http://iiw.idcommons.com/Introduction_to_the_JSON_Spec_Suite
http://iiw.idcommons.com/IIW#12_Notes
Scott noted that the issue of attribute options was raised when work was under way to develop standards for attribute naming, and it was decided not to treat options as modifiers of the underlying attribute type, but this isn't really what the approach would be here.
Further work on this in the context of LDAP/eduPerson would need to focus on particular attributes individually... In the SAML arena, aside from Shib, SimpleSAMLphp would seem to be the only other implementation to factor in to this.
Consensus on the call was to track this issue for now, and revisit it later as events warrant. Benn will at some point propose potential next steps on the mailing list, and circulate reference links related.
3. Thread "Cloud Directory" (started by RL "Bob" Morgan 22-April on the MACE-Dir mailing list); cf.
https://sites.google.com/site/clouddir/home
http://www.pingidentity.com/blogs/pingtalk/index.cfm/2011/4/22/SPML-churn-leaves-provisioning-proprietary
http://lists.oasis-open.org/archives/provision/201104/msg00018.html
RL "Bob" noted that this is essentially an attempt to reach consistency on what some are already doing. eduPerson experience with identifiers (e.g. user IDs v. opaque IDs), was cited as a useful example for reference, in terms of the issues raised.
Provisioning accounts in a consistent fashion to cloud providers is clearly a topic of great interest to higher ed. To the extent that we can influence how this evolves in the consumer space, all the better.
Keith and RL "Bob" will be tracking this as it progresses, and we will add a page in the wiki to follow this.