This page is being used to collect GENERIC Use Cases. Per the usual policy on this wiki, any authenticated user should be able to edit this page.
Basic Use Case -- short term guest access. Jane Doe attempts to access Service X at campus Y, because she is working on a project with John Smith (a faculty member at campus Y). The service requires that she authenticate; she navigates through the Discovery Service and uses her google/yahoo/facebook account to authenticate, and is returned to Service X. Jane now has the baseline set of permissions at Service X. Later, John gives Jane access to the document they are working on together.
Variant one -- short term guest access, pre-provisioned with certain specific rights. (CMU) Student Jane logs into the local student system, and navigates to area X. She decides to give her parents access to this area. She enters one parent's email address. The system sends an email to that address; it contains a url with a token. The parent reads the email, clicks the url, is taken to a service on the campus. Because there is no existing session, the parent is redirected to a Discovery Service. They select their social service as their IDP, are redirected there, authenticate, and are redirected back to the campus. This time,they have a session, and consequently are granted access to Jane's instance of area X.
Variant Two (extending variant one); after authentication the user is taken to a central point of some sort (eg a Gateway); the first time there the user is taken to a Registration App and the user self asserts profile info. (need some sort of person registry. The GW constructs an EPPN value...)
Variant Three -- (extending variant two); some attributes are populated using values asserted by authentication service. (I'm not sure this is really any different than self-asserted...)
Account linking -- built on variant two with the Person Registry. The Registry remembers all of the accounts that a person can use (eg OpenID, institution issued credentials, etc). The user's history and permissions are associated with all of the login accounts. (Perhaps some privileges require higher LoA authN?)
sweden -- specific example of account linking. Person transitions through several stages: applicant (OpenID, social), student (institution issued credentials), alum (back to external credentials). All of these accounts are linked to a single individual.
(n-tier) Jane Doe attempts to access Service X at campus Y, because she is working on a project with John Smith (a faculty member at campus Y). The service requires that she authenticate; she navigates through the Discovery Service and uses her google/yahoo/facebook account to authenticate, and is returned to Service X. Jane now has the baseline set of permissions at Service X. Jane clicks a button at Service X, which sends a query to a backend service; Service X authenticates to the backend service as Jane.