MACE-Dir Call 1-August-2011

**MACE-Dir Call 1-August-2011**

**Attending**
Keith Hazelton, U. Wisconsin - Madison (co-chair)
Brendan Bellina, USC (co-chair)
Michael Gettes, CMU
Mark Scheible, MCNC
David Bantz, U. Alaska - Fairbanks
Scott Cantor, The Ohio State U.
Michael Pelikan, Penn State U.
Jim Leous, Penn State U.
Jimmy Vuccolo, Penn State U.
Chris Bongaarts, U. Minnesota
RL "Bob" Morgan, U. Washington
Dean Woodbeck, Internet2

**Next call: 15-August-2011 3:00 PM EDT (GMT-4)
(NOTE: All future calls will be at 3:00 PM ET)

**New Action Items**
[AI] (Keith) will re-draft the eduMember definition including prefixing the attribute names with edu*, and send it to the list for review and feedback.

[AI] (Keith) will propose a discuss-starter on the subject of whether there should be MACE-Dir attribute specifications for Grouper objects: Role, Privilege, Subject, (others).

**Carryover Action Items**
[AI] (All) discuss feedback or concerns about revised EPTID text on the mailing list.
[AI] (RL "Bob) will distribute information about the UW person registry web service.
[AI] (Keith) will draft a problem statement on person and organization identifiers from social IdPs related to VOs, as a discussion starter, and will refer to IPEDS for reference.
[AI] (Brendan) will distribute some reference materials related to person and organization identifiers from PESC.
[AI] (Keith) will send a discussion starter on the use of eduCourse to the mailing list.
[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. Decline & fall of HE WebSSO
See email: shibboleth-users thread: "Please, somebody talk me down!"
http://marc.info/?l=shibboleth-users&m=131205139925100&w=2

Many vendors proclaim support in principle for Federation/SAML, but in practice don't "walk the walk," e.g. demanding batch feeds of user account info, or eventually remove federated access for various reasons, or don't keep their Shib implementations up to date and properly cared for.

A distinction was noted between vendors which are primarily in the consumer business but also deal with the enterprise, v. those that are primarily enterprise-focused and thus (hopefully) more open to federated access because their customers are asking for it.

Note the distinction between federated services (multi-domain) and outsourced services (single domain). Outsourced services will always have alternatives to federated access, while federated services generally don't. Generally, there are more outsourced services than federated services, and the "boarding problem" has a lot to do with this. Ultimately it is up to the customer relationship with the "outsourced services" vendor, to push for the features you want. This often involves pressure on the campus business folks to push the vendor for particular functionality and features you want. Costs and reliability are factors that can be used to good effect with the business people.

2. Update on guest identities survey
The survey is now closed, with ~60 responses. SteveO is anonymizing the results so we can make it publicly available. Notable was that ~50% use their ERP system as their guest provisioning system, i.e. they support guests by adding categories into the ERP system.

3. A new friendly name for "isMemberOf"? (in SAML: urn:oid:1.3.6.1.4.1.5923.1.5.1.1)
Why? See Peter Schober's email: "Re: Representing VO entities in attributes"
http://www.terena.org/mail-archives/tf-emc2/msg01935.html

- memberOfGroup?
- other suggestions?
- since it's "just" a friendly name, it's not such a big decision

In SAML, the names of attributes is not that important so long as we agree on the OID. Thus is it important to change the name?

The reason proposed is to avoid a name collision with the isMemberOf attribute in OpenDS/OpenDJ (open source LDAP server from Sun, and now part of the Sun/Oracle Directory Server), which is an operational attribute and thus cannot be modified.

Consensus on the call was that this is a serious enough issue that it needs to be addressed. The ways in which software deals with attributes is important to consider in looking at how to tackle this.

It was noted that for these same reasons, hasMember should probably be addressed as well.

One proposal was to prefix our attributes names with "edu" in order to avoid namespace collisions in the future, i.e. eduIsMemberOf and eduHasMember. Note that the containing object class is called eduMember...

Since eduMember will need to be revised, it was noted that there are some other changes, albeit non-controversial, that should be addressed in the process.

[AI] (Keith) will re-draft the eduMember (201109) definition including prefixing the attribute names with edu*, and send it to the list for review and feedback.

4. Should there be MACE-Dir attribute specifications for Grouper objects: Role, Privilege, Subject,...?
- E.g., Could/Should Grouper Privileges be represented as eduPersonEntitlements?

The main reason for doing this would be to support interoperability. Given that Ldappc and related translate Grouper names into others, perhaps this would not be necessary, unless we foresee other Grouper-like tools forthcoming.

It was proposed that this conversation should be taken up with the COmanage and Grouper dev communities, if it seems worth pursuing, to ensure that all are on board.

[AI] (Keith) will propose a discuss-starter on the subject of whether there should be MACE-Dir attribute specifications for Grouper objects: Role, Privilege, Subject, (others).

5. SCIM - Simple Cloud Identity Management
Cf. http://www.simplecloud.info/

Several vendors, including SalesForce and Google, had similar RESTful services defined for their customers to do provisioning into their services, and together with Ping are leading the attempt to standardize. ChrisP and TomZ are the most active participants representing the higher-ed community. We will discuss this more on future MACE-Dir calls.