Contributors:
Arnie Miles, Vince Timbers, Tim McGraw, Michael Gettes
The Story:
Environment:
Technical detail for accuracy: For simplicity's sake, the term Identity Provider and IdP are misused throughout this document. An IdP doesn't actually hold any data or attributes, it acts as an interface the queries data stores. Data and attributes are actually kept in the data stores. In this discussion, a "participant" is any organization that provides identity provider or service provider services to the system.
For this use case, there are one or more Identity Providers (if there is more then one, they will share identical copies of the identity stores and will be load balanced) that provide unique identifiers to every student participating in the system that are matched to a name and a username and password pair. The identity providers will be disinterested 3rd parties, selected via a process described by the policy group. This possible collection of Identity Providers will be called "the IdP" in the singular, since it will act as a single entity. The IdP will also store the fact of each identity vetting performed by the various registration authorities.
Many participants will act as registration authorities for the IdP. These participants will provide a mechanism for students to register to the IdP.
Some registration authorities will have the further responsibility of providing vetting services for the IdP. These will be registration authorities that has some reason for verifying the identity of the student. Examples include the College Board and ACT, who check identities when college entrance exams are given, or FAFSA, who does extensive vetting as part of the financial aid process. The fact of any organization vetting the identity of a student will be entered at the IdP, with only sufficient detail to prove the event happened, not the details of the event. The IdP will hold information that College Board checked a students driver's license, but will not hold the driver's license number.
All participants will maintain their own identify providers, which may or may not have another user name and password for the individual students, based upon their business needs. The participant IdP will keep "enriched" data about each student that is required for that participant's business needs. This is the value add that each participant is able to bring to the marketplace (the technical details of this process will vary from vendor to vendor, and is simplified for this discussion).
There will be a mechanism for password resets, and the information required to perform these password resets will either be stored in the IdP, or will come from a combination of attributes housed by the IdP and other participating identity providers.
Student Registration:
Whenever a student visits a participant for the first time, the student will be asked if they have an account in this system. For the purposes of the prototype the first visit will happen at either College Board or ACT, but in the wild this even may happen much earlier. It makes no difference to the final outcome, because the large majority of participants will be capable of registering students at the time of their first visit. Several things may happen when a student arrives at a registration authority for the first time.
1. They may already have credentials, and remember them, in which case the RA can direct the student to log in with these credentials and complete the local registration event. When the student logs into the system, the local RA will receive the student's unique identity, which will be entered locally and connected to all local attributes. This may or may not include creating a local user name and password, but it will certainly include entering locally useful enriched attributes about the student. Depending upon how many participants the student has already registered with and how much cooperation there is among the participants, much of the work of registering the student with this new participant will be automated.
2. They may already have credentials, and have forgotten what they are, or even forgotten they even exist. This will be by far the most difficult use case to address, because of the risk of the creation of multiple accounts. These must be a mechanism for password resets, and this mechanism must be sufficiently robust to maintain any increased level of assurance the student may have gained via vetting from other authorities, or the level of assurance must be automatically lowered as necessary. In the case of a student who does not believe they have ever enrolled, there must be a mechanism for attempting to match students to existing records, which may prove to be difficult. One element working in our favor is that a student who has already taken exams or applied for financial aid will be aware of that fact, that information can be used to direct a student to a password reset page.
3. They may have never been registered. In this case, the student will register at the local participant's portal, which will automatically touch on the IdP to gather the required unique identifier. The student will be informed that there is a 3rd party handling the identity management and will be given the opportunity to opt out. The student will create their user name and password at the portal, and will then be redirected to the participant's portal to finish the registration process.
