Social Identity Conference Call, 07/01/2013
Overview
- Topic: Minimal Gateway Attribute Bundle
- Reference: https://docs.google.com/a/brown.edu/document/d/1VHuga_hifyjQJbr9i17Vw4FEprwLJxM13Kuc-PX_3Zg/edit
Summary
The discussion focused mainly around EPPN and email. The question of whether or not it is acceptable to use email as EPPN was discussed, and the general feeling was this is not a good idea, but it really is up to the SP/application admin to determine how he/she wants to consume attributes. Scott also noted that shibd is highly configurable, so if the Gateway issued an attribute in one format, shibd could easily rewrite it so the SP could consume it in a format it expects. Lucas noted that the Gateway itself could also allow the SP admin to determine what attribute from the social provider should be set as EPPN, and perhaps even the format of the attribute. He offered three suggestions: 1) Email; 2) Email as proposed by Tom Scavo, but with the scope being the social provider, not the gateway (for instance, lr+lucasrockwell.com@google.com); 3) Unique ID from the social provider, scoped to the domain of the provider. Of course, all of those options may not be available for every social provider, as some do not provide a persistent identifier, some do not provide an email, some provide email but the user can change it, and finally, some offer more than one email. To the last point, Jim noted that Windows Live can return more than one email, and all agreed that if this happens, the Gateway should return all values.
The discussion also focused on the discoverability of a user’s account name/persistent identifier. In the case of Twitter, every user knows their username, because that is simply how the service works. Other providers, like Facebook, also have a human-readable username, but in some cases it may take some discovery for a user to figure it out. Facebook also allows a user to change their username (apparently only once). This is not bad, but it is something SP admins should be aware of. In short, the point is that EPPN should be a username, and not an opaque ID, and it should not be email address if it can be avoided. In the end, it will probably be up to the SP admin to make the choice, and it is up to us (or the Gateway documentation) to make sure the SP admins understand the ramifications of their choices.
Several options were discussed regarding how to provision a user using their social identifier. Steven gave an example of an application where students will need to grant access to their supervisor from their summer internship, and the supervisor will be logging in via a social provider. Ideally, the user could just enter their supervisor’s social username into the application. Of course, this works great for services where you know the username, like Twitter and Facebook.
Also on the topic of attributes, it is possible that instead of EPPN, the new eduPersonUniqueID could be used when the ID is not really EPPN-friendly (like Google’s profile ID and the Windows Live ID). Furthermore, these attributes could be used to seed a targeted ID.
An important item brought up by Scott which is something perhaps the group can keep in mind for the future is: Having attributes for the various social providers. He said, “If we can pass Facebook ID around, then we need an attribute for Facebook ID. And we need an attribute for Twitter handle, and an attribute for Google ID.” He feels this is much better than constructing an EPPN around these values, especially since the user will not know what you are talking about, and the social provider certainly will not know what you are talking about.