Versions Compared

Old Version 8

changes.mady.by.user Steven Carmody (brown.edu)

Saved on

compared with

New Version 9

changes.mady.by.user trscavo@internet2.edu

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Initially, this service will be offered as a pilot; it is not a production service. It will be run as a single instance;  there is no failover.
  2. The goal is to get a simple service operational quickly, and evaluate the use of and demand for the service, and learn more about requirements. Because this is a pilot, it may be shut down on short notice. -- consequently, use at your risk  initially risk....
  3. The SLA associated with the GW will provide 5 X 8 8 X 5 coverage (business hours, Ann Arbor). There will be NO 7X24 7 X 24 coverage.
  4. Initially , this service will be scoped to InCommon members.
  5. The social identity gateway will, at least initially, have an LoA of either 1 or undefined, depending on what value FICAM has assigned to the IDP that was usedassert the unspecified authentication context URI. A future version of the gateway might assert other AuthnContext URIs depending on the LoA of the social IdP. For example, some social IdPs (e.g., Google) are certified LoA-1 by ICAM so it would be great if the gateway could proxy an appropriate AuthnContext URI in this case (but there are technical issues, which is why this capability shouldn't be expected from the initial gateway deployment).
  6. The browser user should only have to traverse a single Discovery Service; they should not be forced to traverse multiple DSs. (ie they  shouldn't have to select "social gateway" from the local DS, and then select a specific social IDP when they reach the GW)each RP needs to decide whether to support the invitation model, the self-registration model, or both.
  7. The GW will be stateless; it will not include anything resembling a Person Registry; it will not remember anything about a browser user who traverses the GW.
  8. The GW is just a translator; it maps the values in the received assertion from a social identity provider  to values in a SAML Assertion sent by the GW. The GW does NOT add any attributes to the SAML Assertion that are are sourced from any other sources.
  9. The GW will have NO support for per-attribute or per-SP attribute filtering when constructing the SAML Assertion.
  10. The GW will not attempt to address the use case of associating a SAML account and a separate social account with a single person. If this is a requirement, then the application at the SP will have to provide this functionality. This so-called "account linking" functionality is out of scope for this discussion.

...