- 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. Attribute Gathering from the User's Representation throughout the CommIT Ecosystem
Attribute gathering will occur after an individual has created an CommIT account and associated it with identity information at participating service organizations. A service provider that needs to pull information from these service organizations can do so using the CommIT identifier for the individual, and may optionally leverage the CommIT IdP for authentication. This process is independent from and fully compatible with the integration strategies used by each service organization in building the CommIT representation of the individual.
Use Case C1: Attribute aggregation with single sign-on
The InCommon-Student group is acting as the higher ed consciousness for this group. They have been posting use cases that would require attributed aggregation here: InCommon-Student use stories
We have a general diagram and description of a attribute aggregation use case here: Use Case C1
#1: Inter-Application data request: Test Scores
Cathy wants to apply to Penn State as an undergraduate. She opens a web browser and surfs to the Penn State Admissions site. Clicking on Apply Online, she sees a login screen and clicks on Use Your CommIT Credentials. Cathy’s browser loads the application with a “Welcome Cathy” in the upper right corner. She then clicks on Provide Demographic Information and her name, address and related contacted information are populated in the form. (She had given prior approval to the CommIT Collaborative to share that information only upon her request.)
Cathy now scrolls to the academic credential section of the form. She notices instructions of “Click on the tests you would like to include in your application” and adds a check mark next to SAT, ACT, and AP History and AP Chemistry tests, but there’s no place to add her scores. She then clicks on “Check for scores.” Penn State checks what test scores are on file from the source organizations and prompts her with a window that says:
We have your SAT, AP History and AP Chemistry scores on file. Should we go get your ACT score now? You can always do this later, if you’d like to finish the rest of your application now.
Cathy thinks for a moment and decides to get this part finished now and clicks on “YES. Get my ACT score.” Because her federated CommIT Credentials are accepted by ACT, Cathy next sees a page on the ACT site that contains a question “Send your ACT score to Penn State now”? Cathy clicks YES and is prompted with a window: “ACT will send your score of 31 to Penn State now. You have 1 score request left in your 5 score pack. Shall we send future scores to Penn State on your behalf?” Cathy clicks YES and then NEXT and is sent back to the Penn State Application. She notices that the application now displays the verified ACT score (and verified SAT and AP scores).
When a student logs in to a service provider using their system credentials, they are initially directed to the system to perform authn duties. The system will verify the user's identity and return their unique identifier. The service provider will then take the unique identifier to the local identity provider, where additional 'enriched' attributes can be found.
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 make several integration strategies a likely outcome for deprovisioning as well as identity building.
- In Integration Strategy 2, is it possible that the participant's account creation process acquires the unique identifier and registers the student with the system even if the student does not yet get a system username and password?