Status: Working draft
Summary: Many entities of all kinds are interested in verifying whether a person is an enrolled student, for a variety of purposes. Doing this via federated signon can provide many advantages in ease of use, security, and privacy.
Current Situation
In many situations an organization external to a HE institution wishes to determine whether a person is currently an enrolled student at the institution. The process of doing this is "enrollment verification." Examples include:
- A student applies for a summer program that is restricted to current students.
- A student wishes to take advantage of a service offering free or discounted products to students.
- [Other?]
Many methods are being used to do enrollment verification. Traditionally these have involved paper or fax, usually involving manual procedures in the Registrar's office. As processes have moved online, various electronic methods have emerged. There are no standard methods, however, leaving campuses, verification requesters, and students to deal with a confusing and expensive patchwork.
In some cases verification is an online realtime process initiated by the student, for example a student using an online service providing discounts to students. In other cases verification happens asynchronously, for example as part of an employer verifying resume data.
In some cases the organization requesting verification is given lookup access to student records (or some portion of them) for this purpose. These records may be held (and the lookup access provided) by the HE institution, or by a third-party provider. Often this process requires the student to provide to the requesting organization personally-identifying information such as name, date of birth, or Social Security Number, to be used as a lookup key. While in some business processes (such as employment) this information may need to be given by the student anyway, in others (such as discount purchasing) it is more than the organization needs to know, and may open the student to identity abuses.
The Federated Signon Approach
In a federated scenario using InCommon-promoted standards, a student can authenticate to a Service Provider (SP) via their institutional Identity Provider (IdP), and the IdP can provide information asserting that the authenticating user is currently a student at that institution (using the eduPersonScopedAffiliation attribute defined in the EduPerson specification). This capability can be integrated into an online enrollment verification process.
Consider a hypothetical online discount services provider, studentexample.com. A student wishing to take advantage of the site's services signs up for an account at studentexample.com in the usual Internet way, using some email address (not necessarily an educational-institution one), and making up a password. The student browses the offerings, and comes to a point where proof of enrollment is required. studentexample.com then offers, among its verification possibilities, a link labeled "sign on via your school." Selecting this would bring up a page permitting the student to pick their institution from a list. Doing that sends the student to their institutional web signon page. After authenticating, the student is returned to studentexample.com, which receives both an opaque permanent identifier for the student (e.g., f48726ae@example.edu) and an affiliation attribute (eduPersonScopedAffiliation=student@example.edu). studentexample.com can then associate the student's local account with their student affiliation attribute, and institution-provided identifier (so they can tell if the same student returns, and prevent a student from letting others use their affiliation).
The above scenario has the following benefits:
- For an InCommon HE institution that supports standard user attributes, it is trivial to enable. The InCommon HE institution simply configures their IdP to release the student affiliation attribute to studentexample.com for all of its students.
- For the student, verification happens immediately, using a signon method familiar to the student, without having to release any other personal information to the service.
- For studentexample.com, verification is secure, reliable, and immediate. Once implemented, it can work consistently with all InCommon members with no additional work.
Note that this method could be used by a third-party holder of student records acting as an IdP. Presumably such an IdP would be obliged to rely on personal information such as SSN and date-of-birth to authenticate a student, since it wouldn't have the usual account relationship (i.e., username/password) with the students about whom it holds records.