MACE- Dir : Attributes, Schema and Information Models for Education and Research

1. InCommon Virtual Working Groups, May 21, 2013 Keith HazeltonMACE-Dir Chair, UW-Madison Jon SaperiaInCommon User Identifiers Chair, Harvard U Mark Scheible InCommon/Quilt Federation Pilots, MCNC MACE-Dir: Attributes, Schema and Information Models for Education and Research

2. OVERVIEW • Introduction to MACE-Dir • The Evolution of eduPerson--New Draft Out for Review • New identifiers to solve a long-standing set of problems • Keeping track of changes to eduPersonPrincipalName values • Crafting a Schema for K-12 Use • System for Cross-Realm Identity Management (SCIM) • A new model for identity data provisioning and integration • Exploring Curricular Data Needs • Elsewhere in Schema-Land • An Online Schema and Attribute Registry out of the NSTIC pilots

3. Introduction to MACE-Dir • Formed back when LDAP was The New Thing on campuses • Responding to a need for a common core set of identity attributes in higher education identity and access management • Published the first version of the eduPerson specification in early 2001 • The LDAP Recipe Released at the same time (h/t Michael Gettes) • Any time you visit an InCommon relying party using campus login to Shibboleth, your institution is using eduPerson • Over the years also published specifications for • isMemberOf • eduCourse

4. The Evolution of eduPerson • New draft out for review: eduPerson (201305 Draft 08) • New attributes… • Jon Saperia of Harvard University led an InCommon group on User Identifiers • MACE-Dir hosted the User Identifier conference calls • The group ended up advocating the inclusion of three new identifer-class attributes in eduPerson

5. User Identifier Issues • Inconsistent use of existing attributes for: • ePPN • Too often used as mail attribute • Used to show identity domain which can be incompatible with email address • Mail • Need for a stable user identifier • Overloading mail attribute • Used as an identifier to applications • Used to display identity to users • Other administrative uses

6. Using institutionalUserMailAddress • Use when user identifier is required as an institutional email address • not a recommended practice to use email address as an identifier • Once assigned MUST NOT be reassigned • Email domain is treated as an administrative domain under control of identity system that created the ID • User must be reachable via this email address

7. Using eduPersonUniqueID • Long-lived, non re-assignable • Scoped and ID portion must be unique within issuing identity system • Part to right of “@” MUST be same administrative domain as the identity system that created ID • SHOULD NOT be treated as an email address • Example: • eduPersonUniqueId: 28c5353b-8bb3-4984-a8bd-4169ba94c606@foo.edu

8. Using institutionalUserMailAddressPrior • Allows association of previous addresses used with a principal • MUST NOT include any currently valid institutionalUserMailAddress value • There is no ordering to the list of entries

9. The Evolution of eduPerson • New draft out for review: eduPerson (201305 Draft 08) • Another new attribute • eduPersonPrincipalNamePrior (ePPNP) • Helps in situations where a user’s ePPN value has changed • Important when Relying Parties are using ePPN for authorization purposes (as in .htaccess files) • Continued international discussions on uses of existing attributes • For example, last two weeks, lively thread on eduPersonEntitlement • For one example, a way to signal “This user should receive access per the terms of the contract mapped to this entitlement value (URI)”

10. The Evolution of eduPerson • In practice, a small number of attributes do a lot of service • Identifiers (where needed) • Affiliations (scoped, generally) • Group memberships • Entitlements • Tendency to use “cooked” attributes (affiliations, groups, entitlements) rather than ask for a large set of atomic facts from which to compute an allow/deny decision • Example: A learning management system (LMS) controlling access to course materials • Roster information via isMemberOf (vs eduCourseMember) • “Ticket” to use a particular e-text via an entitlement URI

11. Crafting a Schema for K-12 Use • The North Carolina Education Cloud (NCEdCloud) - RttT • Foundational project is an IAM “Managed Service” • Covers ALL K-12 students, teachers & staff, parents, guests • Single username/password for access to cloud services • Led by the Friday Institute at NC State University • MCNC has been providing IAM consulting resources for two years • Developed an architecture document describing what was needed • RFP process completed, contract awarded to Identity Automation • Service consists of Data Integration of sources, building and maintaining a Person Registry, Directory environment, and Federated Identity Management for roughly 3 million identities • Provisioning of Cloud Service accounts • K-12/Community College Pilot using federated identities • Part of InCommon/Quilt project to extend FIM to K12, CC, etc.

12. K12 Schema Development • Why a separate K12 Schema? • K12 has additional challenges/requirements • K12 students are minors • Special/additional regulations apply (e.g. COPPA, CIPA) • Students cannot authorize attribute release (parent involvement?) • Delivery of online services/content may be age- or grade-based • Granularity of K12 organizational structure may be finer than HE • IT Staffing, Skillsets in K12 frequently not focused on IAM/SAML • 13-year relationship with moves between schools/districts • Parents could easily have a longer relationship (multiple children) • 1:1 student/client device is rare (particularly primary grades)

13. K12 Schema Development • Existing schema (e.g. eduPerson) are not sufficient • Attributes we know or suspect will be needed • Grade level • Over/Under 13 (for COPPA) • School Identifier • School District • School Region (in some states) • Parent or Guardian “link” (connecting parent to student) • Parent or Guardian consent (to release attributes) • Schema development work plan • Mailing list, Conference calls (under auspices of MACE-Dir)

14. System for Cross-Realm Identity Management (SCIM) • A new API and schema for identity data provisioning and integration • Came from a vendor consortium • Now transferred to an IETF working group • Provisioning and integration is a different beast than Web SSO access control • Think cloud providers, SaaS • They may need a persistent service-specific set of user accounts and identity data • Perhaps driving a need for the sharing of a richer set of attributes from our campus IAM systems • SCIM defines a standard mechanism for schema extension (like auxiliary object classes in LDAP)

15. System for Cross-Realm Identity Management (SCIM) • SCIM is coming to higher education via two paths • Grouper has SCIM support on its latest roadmap • CIFER (Community Identity Framework for Education and Research) • Open source IAM initiative under the auspices of Internet2, Kuali and Apereo(Jasig/Sakai) • Recommending SCIM as a core API for identity data provisioning and integration across the IAM infrastructure • Developing SCIM schema extensions to cover the CIFER identity registry data model • MACE-Dir will host review and comment discussions as requested

16. Exploring Curricular Data Needs • New collaboration being launched by Penn State and the University of Wisconsin-Madison • MACE-Dir will provide a venue for the collaboration • As it did for InCommon User Identifiers • Provisioning to LMS is one use case • But many other uses are made of curricular data including mash-ups with location information and academic organizational structure • Planning your course schedule, can you get from Chem 205 to Art History 101? • UW-Madison evolved a set of Enterprise Business Objects (EBOs) for curricular data • Collaborative exploration of requirements and potential solutions

17. Elsewhere in Schema-Land • An online Schema and Attribute Registry now at version 1.0 • An early NSTIC pilot deliverable from the Internet2 Scalable Privacy project • NSTIC: National Strategy for Trusted Identities in Cyberspace • Higher education has thought longer and harder about schema and attributes than government and industry • The registry as a way to demonstrate prior art and show patterns of use • Includes eduPerson, SCHAC, OpenID Connect, Open Social,… • Each attribute is associated with an attribute class (identifier, name, entitlement, profile) to facilitate cross-schema comparisons

18. Your Input: Other Topics Needing Attention

19. To Participate in the Work • MACE-Dir mailing list • Subscribe at https://lists.internet2.edu/sympa/subscribe/mace-dir • InCommon User Identifiers: Via review of eduPerson draft • Subscriber comments to mace-dir@internet2.edu • Non-subscriber comments to i2mi-info@internet2.edu • K-12 Schema work • Subscribe at https://lists.internet2.edu/sympa/subscribe/k12person • SCIM • Subscribe at https://lists.internet2.edu/sympa/subscribe/cifer-prov • Other questions: hazelton@wisc.edu

20. MACE-Dir: Attributes, Schema and Information Models for Education and Research May 21, 2013, InCommon Virtual Working Groups Thank you! For more information,please visit www.internet2.edu