Contributors:
Arnie Miles, Vince Timbers, Tim McGraw, Michael Morris
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. So, in this document, an Identity Provider or IdP is the entity that has the identity store and the Shibboleth Identity Provider software installed. A "participant" is any organization that provides identity provider or service provider services to the system.
For this use case, there is an Identity Provider that provides unique identifiers to every student participating in the system that are matched to a name and a username and password pair. The IdP is responsible for managing and disseminating the unique identifier. The identity provider will be a disinterested 3rd parties, selected via a process described by the policy group. This Identity Provides will be called "the IdP". 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.
General Student Registration example:
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.
Specific Student Registration Processes:
1. The first stop a student makes is to the System maintained portal
In this example, the first place a student goes is to a portal that is owned and maintained by the system. The page will display descriptions of what the system offers students and why they should create accounts. It will describe all the current participants, and will tell the student which participants will accept System accounts and which will accept a combination of System and Local accounts. Since this is defined as the first time the student visits, the student does not yet have an account, so when the student is asked if they have an account or not, they will select 'No."
The student will be given a list of participants with check boxes to indicate which participants they would like to pre-register with. The student will click on "Continue."
The student will be presented a general account creation screen. If the student has not selected any participants to pre-register with, the student will be asked the minimum questions that will allow the System account to be created, primarily the student's name and other attributes that may be useful for password resets. If the student has selected one or more participants to pre-register to, the student will get a larger set of general questions that contain information that the typical participant may want to keep locally. The student clicks on "Register."
When the student clicks on "Register," the system and participant identity stores are checked for potential matches to the student attempting to register. If any matches occur, the student will be given the opportunity to select the one that is a good match and log in as that account, or perform a password reset. If the system does not make any matches, the system will assign a unique identifier and will store this identifier and system required attributes while simultaneously writing the identifier and the enriched attributes to the participant identity stores.
For participants who decide to depend upon system credentials for everything, the process of registration is complete, and the student will receive a "Success" screen. For participants who require additional local credentials, the student will be sent to the participant's portal with the explanation that this participant requires an additional registration step. The participant portal will start with pre-populated fields from the initial system registration and the student will be given the opportunity to create new local participant credentials. This will happen for each participant that the student selects that may require this additional account creation. Once this is complete, the student will receive a "Success" screen.
