Technical Processes
Participation in Building the User's Representation in the AdmitMe Ecosystem
During the November 4 technical committee teleconference there was much discussion about the various flows a student may take to register through the system. Basically, the discussion broke into two general categories which need to be described.
Integration Strategy 1: The only account a student gets is a system account
In this flow, the first place a student goes will be the system's home page. The student will be 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: A student can have either a system account or local participant account
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
More to follow. Michael Gettes and Jim Leous
Attribute Gathering from the User's Representation throughout the AdmitMe Ecosystem
Attribute gathering will occur after an individual has created an AdmitMe 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 AdmitMe identifier for the individual, and may optionally leverage the AdmitMe IdP for authentication. This process is independent from and fully compatible with the integration strategies used by each service organization in building the AdmitMe representation of the individual.
Use Case C1: Attribute aggregation with single sign-on
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.
Deprovisioning a User Representation from the AdmitMe Ecosystem
While not likely to be a powerful initial concern for the AdmitMe 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 AdmitMe 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.
Questions:
- 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?