This page is being used to collect Use Cases. Per the usual policy on this wiki, any authenticated user should be able to edit this page, and submit their Use Cases for discussion. Please add your name and site within parentheses at the start of each of your Use Cases.
- (Carnegie Mellon University, Russell J. Yount <rjy@cmu.edu>)
We are working towards using Incommon Federation, OpenID and other future social authentication systems to provide access for what we are terming "Low Level Of Assurance" LLOA access. Our first application to use this is for parental accounts. We would like to enable access to student billing information to parent whos child have enabled permission for access.
The model we have decided on will send an email at the student's request to a parent that invites the parent to register with using one of a number of OpenID providers or Incommon Federation identity providers. We are using this model as we believe students are more likely to know their parents email address than know their parents InCommon or OpenID identity.
The implementation will be done with gateway service which will provide a CMU identities within local CMU shibboleth federation which are the translation of the OpenID or other provider's identity. InCommon federation identities will be used directly.
We hope to use outside identity providers for access to a number of other service in the future. These may include guest network access, preadmission students....
- (CILogon, Jim Basney <jbasney@ncsa.uiuc.edu>)
We are accepting both InCommon and OpenID authentication for the issuance of X.509 certificates for use with grids and cyberinfrastructure (for command-line, message-based, and batch workflows). For IGTF (high assurance) certificates, required by TeraGrid, EGI, and others, we can accept only InCommon Silver authentication. But representatives of other cyberinfrastructure projects (such as DataONE, FutureGrid, and OOI) have requested that we provide lower assurance certificates based on OpenID authentication for greater ease-of-access, especially in cases where the researcher's home campus isn't (yet) an InCommon member. The OIX Certified OpenID providers are of particular interest to us, so we have some minimum level of assurance.
A significant difference for us between InCommon and OpenID is that we can get the researcher's name and email address from InCommon identity providers to insert into the certificate, whereas we find many OpenID providers can not provide this information to us, so we just put the OpenID URL itself in the certificate (see http://ca.cilogon.org/names).
- (Internet2 COmanage, Benn Oshrin)
We anticipate that some members of some VOs will maintain relationships with different Real Organizations (ROs) over the course of their affiliation with the VO. We anticipate that different ROs will be able to support different identity protocols, and that in between affiliation with "traditional" education and research organizations, some members may only maintain identities at "social" organizations such as Facebook and Google. This should look pretty similar to Peter's original use case.