Draft requirements for a shared Social2SAML gateway service

Operational

1. This is a pilot -- use at your risk  initially ....
2. What is the SLA for the GW -- 5 X 8 coverage (business hours)
3. provided identity is low assurance, 
4. do NOT require that browser user login from IDP contained in the invite email
5. should be a single discovery service per RP - shouldn't have to select "social gateway" from the local DS, then at the social gateway, select yet another social IDP
6. each RP needs to decide whether to support the self-registration use case
7. separate out the account linking problem, out of scope for this discussion. Perhaps it is a separate service.

Mode 1 -- SP uses Embedded Discovery Service

1. This mode can be used with both the invitation model and the self-registration at the SP model
2. Browser user must be able to transparently traverse the GW
3. Browser user selects social identity provider within the EDS; SP tells GW which social identity provider to "relay" to ...

Mode 2 -- SP Uses central Invitation Service

1. Is anyone actually interested in this model ?
2. Issuing the invitation (via email) and remembering which permissions it is associated with seems like an SP issue
3. preserve any URI that's passed to an invitation service

Mode 3 -- SP relies on Central DS which Includes Social Options

1. SP passes the GW a filter specifying acceptable IDPs (both SAML and social ? ) SP provides json feed ?
2. User is presented with a DS, selects IDP, "normal" flow.

GW -- Handling of input, and outputs

1. SP can pass a token to the GW (indicating session at SP?); GW must return it
2. GW MUST forward to the SP the original payload from IDP in an unmolested way (I believe this refers to the Assertion coming from the social IDP, in its native format)
3. the GW should map and then forward individual attributes ....
   1. we need to define syntax, semantics for Assertions produced by GW