In each integration strategy, there is a consistent, shared CommIT identifierCommIT identifier. User information is not stored centrally, but is instead stored at each service organization.
Integration Strategy 1: The Service Organization Relies on CommIT for CommIT for All Authentication
After clicking login, the user will be sent to CommIT and 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.
Integration Strategy 2: Login through CommIT or CommIT or through Local Credentials
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.)
User Data Transfers throughout the
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.
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.
This material is not maintained and is archived for discussion.
#1 enhanced, re-write from CommonApp:
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.
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?