Integration Strategies
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 Strategies that describe building the ecosystem and student registration
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
Use Cases Regarding Gathering Attributes
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.
Use Cases Regarding de-provisioning
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?