...
The following scenarios describe the four processes that can occur at authentication time. Other flows, such as the aggregation of attributes about a principal from all participants in the AdmitMe ecosystem at the end stage of the application process, are out of scope for this document, which addresses only authentication.
Actors Involved in these scenarios
1. Student: S1 - In this case it is the user Annie Applicant
2. Participating Portal: P1 - It could be a Service Organization (Ex. Collegeboard, ACT, FAFSA etc) or an Application Service Organization (Aggregation portal, school system etc). A user may have local account with this organization. P1 also offers an attribute service that can be viewed as a business opportunity for P1 to contract with potential customers who are interested in retrieving valuable information about the user.
3. AdmitMe Identity Provider: IdP - AdmitMe portal that also supports central account creation UI to establish a unique identifier for the user.
1. AdmitMe Login
Annie Applicant wants to use an application service. The application service permits both login with an application service credential, or login with an AdmitMe account. Annie doesn't have a local account yet, and there's an explanation on the page that tells her about all the benefits of using AdmitMe instead of a local account. She chooses to click on the AdmitMe button and she creates a new AdmitMe account. Following account creation, she's directed back to the AdmitMe IdP to authenticate. After successfully authenticating, AdmitMe sends back an assertion describing the authentication, the verification level associated with her account, her AdmitMe identifier, and optionally a set of attributes. The application service optionally creates or loads a local representation of Annie keyed by her AdmitMe identifier which is used to store additional local data about her.
The next time Annie returns to the service, she chooses to login with AdmitMe. Since she already has an account, she clicks the AdmitMe button. After successfully authenticating, AdmitMe sends back an assertion describing the authentication, the verification level associated with her account, her AdmitMe identifier, and optionally a set of attributes. The application service optionally loads the local representation of Annie. 
2. AdmitMe Login to Local Account Creation or Association
...
Arnie Applicant wants to login to an application service. The testing service offers to let him login with a local account, or to use an AdmitMe account. Arnie just wants access to the application; he is not interested in using or learning more about AdmitMe. He clicks the local login button. After successfully creating a new local account or authenticating with an existing local account, Arnie is granted access to the application.
Outstanding Questions:
1. Can one AdmitMe account be mapped to multiple accounts from a given service organization? Probably the answer is No, however the policy group need to vet this out.
...
5. If a user creates multiple AdmitMe accounts, are they reconciled? If so, how?
Actors involved in the following scenarios:
1. Student: S1 - A user whose Identity is uniquely referenced with central Identity Provider, i.e. AdmitMe portal
2. Participant: P1 - Service Organization (Ex. Collegeboard, ACT, FAFSA etc). A user may have local account with this organization. P1 also offers an attribute service that can be viewed as a business opportunity for P1 to contract with potential customers who are interested in retrieving valuable information about the user.
3. Participant: P2 - Application Service Organization (Ex. Aggregation Portal that interfaces with schools and colleges). A user may have local account with this organization
4. Identity Provider: IdP - AdmitMe portal that also supports central account creation UI to establish a unique identifier for the user.
The proposed user story is divided into the following two scenarios.
Wireframe UI's for Sequences:
...