A set of use cases has been submitted that describe campus central IT adding "social identity people" to the central person registry (and perhaps associating multiple sets of credentials with an individual); a separate set of use cases has been submitted which include no role for central IT or for "remembering" anything about the person using social credentials. Both models seem to have significant numbers of people interested in them. Consequently, both models are likely to be deployed, with campuses choosing a model appropriate to the problem they are trying to solve.

One of the institution level models involves imposing some control over which social identities are allowed access to services (perhaps by requiring an invitation).

Perspectives on Handling Both Social and SAML Identities

• Relying party wants to make some federated resource accessible to people who have a Social Identity Provider (Twitter, Yahoo, Google, Windows Live)
  • On one hand they want to minimize changes to their Service Provider implementation and their application code
  • On the other, they want to know which-and what type of-IdP is handling any particular access instance
  • If they want identity attributes as well as an authentication assertion, they want those attributes to have consistent names and consistent value syntax. The same attribute name should not represent two different attributes nor should the value syntax vary for a given named attribute.
    • This applies whether a Social-to-SAML gateway is involved or not.

• The user expects to make a search-and-one-click selection of their IdP of choice
  • They would like to see a given social identity provider identified the same way regardless of their path to the SP
  • They might expect that they would be recognized as the same individual regardless of their choice of IdP, but in general this is not possible without some user mediated account linking on a per-SP basis