Scribing Template --Tues., Nov 12, 2013 at 10:45am -- Salons A-D
TOPIC: Social ID and Trust
CONVENER: Paul Caskey
SCRIBE: David Langenberg
# of ATTENDEES: 59
MAIN ISSUES DISCUSSED:
What credential is a student more likely to protect? Facebook or Campus NetID? --- answer is facebook
While we are going to force an identity on the user, why do we continue to force a credential on the user?
How can we leverage social ID in a more trusted way? How can we elevate trust besides asking the user "20-questions?"
If you think of Social AuthN as just another type of campus AuthN and tackle the problem of enrolling the user via the social ID and adding additional attributes to them you don't have to worry about the fact that it is a social ID.
Parent -- inviting the individual in & have them use SocialID for the AuthN and linking them back to the real identity. It doesn't matter (in the parent case) if the person is really the parent. What matters is that they are paying the bill.
We are lacking the standards and tools for expressing relationships between identities eg student@institution.edu -> parent@gmail.com. Today's solution is to invite the parent in & THEN create the link. What's needed is a way to do that without the parent yet being in the system
OpenIDConnect provides ways of expressing AuthNContextClassRef: it would be nice if Google would use something standard for that.
Just because you outsourced the identification to the social provider doesn't mean you have to outsource the Authentication. You can do a hybrid approach.
Keep in mind that Google operates on what's good for Google and the business cycle. Our community is not held to that and operates on the very-long game.
ACTIVITIES GOING FORWARD / NEXT STEPS:
If slides are used in the session, please ask presenters to convert their slides to PDF and email them to acamp-info@incommon.org
Develop standards / profiles for OpenIDConnect AuthnContextClassRef similar to saml2int profile
Develop methods / clearinghouse to know when a social identity was compromised so that the social ID holder can be re-vetted if necessary
Need to get consensus about needs of the community in regards to fleshing our options for deploying the socialID.
Repurpose the SocialID calls to be more about the eco-system for external ID rather than solely the big socialID providers
Talk about the lifecycle of invitation -> association -> authentication -> credentialing -> closing.
Engaging with with tech types to figure out a way to let folks login to things like workstations, databases, other non-web things with web-based SocialIDs