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.
Link to contributed use cases 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, email invite, 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...)
Basic Use Case 2 -- short term guest access. John Smith (a faculty member at campus Y) is working on a project with Jane Doe; they are using a wiki service to support their collaborative work. John goes to the wiki space, and grants Jane's OpenID value R/W access tot he space. Later, Jane accesses the wiki, authenticates using her OpenID associated account, and gains access to their shared work space.
Basic Use Case 3 -- (web finger) John Smith is working with a group of 50 other researchers. He has email addresses for all of them; most of the email addresses are based at gmail and yahoo. He maps the email addresses to their associated OpenID values, and then grants all these OpenID values R/W access to the wiki space supporting their work.
Account linking 1-- 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?)
Account linking 2-- Sara has been accessing the public portions of SonnetBlast, a Bamboo workspace, based on an authentication to her FaceBook account. Six months later Sara starts a research plan that requires advanced features of SonnetBlast only accessible via federated login using her Wattsamatta U. userid. However, she doesn't want to lose access to some note files compiled while logged in under her Facebook identity. She learns from Bamboo Workspace documentation that it is possible to coalesce materials stored under two Bamboo accounts using a custom account linking service.
She goes to the account linking website where she is prompted to log in to Bamboo. Once in, she is prompted to log in again, using the Bamboo userid for the account she wants to link to. On successful authentication to both accounts, the two associated Bamboo PersonIDs are merged so that all materials linked to her Facebook identity are accessible with her Wattsamatta U userid. She is still able to login to SonnetBlast with her Facebook credentials, but is only able to see publicly accessible materials.
Account linking 3-- Assistant Professor Kohlrabi has a Bamboo identity created under his Garden State College issued userid. Budget cuts to the university threaten to snowball into layoffs in the assistant professoriate. Based on Bamboo FAQ advice, He decides to link his Google account to his Bamboo identity as a precaution against losing his Bamboo portfolio in the event his university credentials are yanked as part of a termination of appointment.
He authenticates to the Bamboo account linking site with his institutional identity. He is invited to chose a social identity provider, clicks on a link that takes him to a Google login popup. After successfully authenticating, he is informed that his Bamboo account is now accessible via his google account credentials, regardless of the status of his Garden State ID. However, because the rights to access certain online journals and Bamboo data files depend on faculty status, he will not have access to those resources when logged in with his Google account.
Account linking 4-- Professor Jessica Postlethwaite holds joint appointments at Harvard and MIT in nanosemiotics. She is a senior partner in The Semiotics of Nanotechnology Bamboo Workspace. To bring together her data files from both MIT and Harvard, she uses the account linking service to link her Harvard and MIT identities, thereby consolidating them under a single Bamboo Person ID. Note that specific access rights are associated with particular identities, so there are some MIT materials that she cannot access when logged in via Harvard credentials.
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 case 1 -- (delegation used to access backend service)
n-tier case 2 -- (impersonation used to access backend service)
Alumni -- another specific example of account linking. (Carleton College) When alumni password recovery or account claiming can be managed through the email address on record, so can linking of alumni internal accounts with OpenID credentials. Alumni tend to access services rarely (reunion registration every five years, occasional alumni directory lookup); it makes so much sense for them to use credentials they use on a daily basis (like their Gmail account) instead of maintaining and/or recovering local credentials.
(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.