7) Description of SAML attributes:
a) Everything must be expressed in a manner that is independent of whether a native or GW implementation is being used.
b) different social identity providers should be represented with a different url, same as every other saml idp provider. This is essential for implementing Discovery in a seamless fashion.
c) Its not necessary that every GW in the world use the same identifier for a social identity provider. Clearly, though, consistency woould a good thing.
d) Its likely that the entityID will be an amalgamation of GW + social provider, since different GWs might use different values. However, we will need to find a way to deal with situation where an app can be reached via multiple GWs.
e) Identifiers need to be separate from issuers. (eg a google account from one GW MUST be the same as a google account from another GW). NOTE -- accounts are different from email addresses, even though with some social providers there might have the sane value.
f) SP needs to know which GW (if any) is forwarding the authentication event. (eg an SP might trust one GW but not another)
8) Problems obtaining attribute values. Many of the collaboration sites which would use this support want the user to present several PII-attributes (eg name, email, identifier for this principal from the social provider). However, not all social authentication providers will share this information (especially email). As a result, the application may have to present a "user profile" form the first time a user connects, and ask the user to self-assert various values.
We need to do an appropriate study of what all the identifiers in the social space are -- we might end up with different attributes from different providers, or different syntax in some cases.