Technical Processes
- Building the User's Representation in the CommIT Ecosystem
- Attribute Gathering from the User's Representation throughout the CommIT Ecosystem
- Deprovisioning a User Representation from the CommIT Ecosystem
1. Building the User's Representation in the CommIT Ecosystem
In order to take advantage of CommIT, an individual will gradually assemble identity information at service organizations that are participants in the CommIT project. This identity information will be keyed by the user's central CommIT identifier.
First, any participant may decide to use only CommIT for login. Second, a participant may choose to offer both local accounts and CommIT for login. A third choice envisions permitting login from any InCommon member. These three strategies are described below.
In each integration strategy, there is a consistent, shared CommIT identifier. User information is not stored centrally, but is instead stored at each service organization.
The choice of integration strategy is the sole province of each participant, and all three strategies can co-exist. Each participant is encouraged to choose the integration strategy that best suits their needs.
Integration Strategy 1: The Service Organization Relies on CommIT for All Authentication
Integration strategy 1 presents a user with a single login choice: CommIT. This removes the need for the service organization to manage the authentication of users, a costly and time-consuming process. It also greatly simplifies the user experience.
After clicking login, the user will be sent to CommIT and shown the logos for all the various participants in the system, and will learn how a single system account will Federate their identity and provide single sign on to some or all of each participant's offerings. The student will create a system account at that time, and will be given the option to create identities with each participant.
Participants will only use the system credentials for authentication, and will only keep enriched participant-relevant data locally. The system will provide an identifier that is unique to the student that links all the accounts together.
Integration Strategy 2: Login through CommIT or through Local Credentials
This integration strategy reflects both some participant's desires to have local participant credentials and the reality that there may be a migration strategy required for participants who will eventually use Integration Strategy 1. There are 4 different flows through this strategy that are described in further detail.
Integration Strategy 3: Student has system account linked to University account, and wants to use University account to apply to other institutions
This integration strategy could be required in cases which the student would like to apply to other undergraduate institutions or graduate institutions. It could also exist where an undergraduate or graduate wishes to take a graduate admissions exam (e.g. GRE, GMAT, LSAT, MCAT). As far as flows are concerned, once the student goes to a participating site, a request will be made for the CommIT account credentials and the flows degenerate to Integration Strategy 2 flows. (We may wish to contemplate whether that last sentence is true.)
2. User Data Transfers throughout the CommIT Ecosystem
The common CommIT identifier and trust framework permit organizations to communicate information about an individual with an authoritative single reference, replacing distributed, costly and error-prone matching processes. However, this data aggregation process is largely orthogonal to the CommIT problem space.
Existing data transfer frameworks understood by both organizations that can accommodate and include this identifier need no modification. New data transfer protocols and frameworks may be designed using the CommIT identifier as a component.
Organizations involved in this data transfer may optionally leverage the CommIT IdP for authentication as part of a data transfer process.
3. Deprovisioning a User Representation from the CommIT Ecosystem
While not likely to be a powerful initial concern for the CommIT project and its participants, eventually there will need to be processes and policies in place for deprovisioning user information that is no longer needed. Because this information is stored in a highly distributed fashion, special care will need to be paid to purging it to avoid either premature deletion of parts of a user's representation, or storage of old, possibly sensative personal information.
This should be coherently addressed for the CommIT Ecosystem, but the wide variety of data persisted at each service organization makes several integration strategies a likely outcome for deprovisioning as well as identity building.
Parking Space
This material is not maintained and is archived for discussion.
#1 enhanced, re-write from CommonApp:
Since CommonApp will be an excellent example of this use case, this addition/enhancement from them is useful:
DRAFT Use Case: Inter-Application data request: Test Scores
Simon wants to apply to college as an undergraduate using the Common Application. He navigates to www.commonapp.org and creates a user profile. Upon starting the registration process, he sees a login screen and clicks on Use Your CommIT Credentials. Simon’s CA registration page displays an "Import CommIT Profile" link and asks him to complete remaining information for Common App registration. If Simon has no CommIT Profile, he is given the opportunity to create one, which is then recognized by Common App as his user credential.
Simon proceeds with completing the Common Application, and comes to the Testing section. He sees instructions at the start of the section with a link to "Import your official test scores." Since Simon has a CommIT ID, when he clicks the link, a series of checkbox options appear , labeled with the range of scores he can import: SAT, ACT, and AP History and AP Chemistry tests. Once selected, Simon clicks "Import Official Scores." Each testing source chosen by Simon is queried for scores using his CommIT credentials, and each source returns all Simon's scores and dates, or a message indicating that no scores were found, and where to go for support from ACT, SAT, etc.
Common App receives the data and populates his Testing Section of the Common Application appropriately. Beside each score, a choice group labelled Do Not Send appears, allowing Simon to choose from among the schools on his MyColleges list, to accommodate his preferences regarding Score Choice. Simon completes his application and submits to Common Application Member Colleges according to his preferences, and with each submission, his chosen official scores for the member college in question are provided along with the application.