Ken K – Conservation of APIs. Interfederation is driving even further multiplication of APIs. What are the pain points? Marshaling parameters – what do you call it? What are the attributes being passed? Normalization of release of information. Building interfaces that will work. Reconcile that over 90% of users of Google don’t know what information is being released. APIs are going to invoke privacy management, so we’re going to need conservation of paradigms around that. It’s going to mean multiprotocol. What happens if I want to interact with my colleagues in a cloud app? Re-emphasizes bilateral federation vs. multilateral federation. Feds will announce federal portal soon. MLS services have done Shib, as is health care. APIs haven’t been worrying about strength of authentication. In the future you’ll be able to buy attribute verification services – e.g. “user has put in this street address, do they really live there?”. Presumably the more you spend the better the strength of the verification. You’ll be able to buy from the Postal Service, Google, credit card services, etc. through APIs. Reinforces the privacy aspect – will need to make this tractable. There are a bunch of vendors that want values of “studentness” – we will be in a position to sell that to them. We pass it among each other with no charge. What does this do to our social fabric? Steven Carmody – Brown University – Models for Managing Privacy and Attribute Release Fair Information Practice Principles – passed by congress in 1974 – Transparency, individual participation, purpose speification, data minimization, use limitation, data quality and integrity, security, accountability and auditing So why are so many places asking for so much personal data to be released? Research from Penn State – when faced with a note that says “This program will erase your hard disk, click yes to continue”, 90% of people click it. One model that might help is if the attribute release process is not part of going to actually use a service. Abc4trust/Idemix – You download identity cards from your identity providers. Will produce trusted assertion without revealing details. You choose what source you will release the information from. Process occurs in your desktop, so the iDP doesn’t know where the credential is being used. Privacy manager properties: Accurate; Design consistency; describe who will use the data, and what they will do with it; understandable (balance, summary vs. detail, information model), encourage reasonable answers (position in flow, timing). Leveraging Social Identities Allowing access to the other 90%. An InCommon pilot to support access by people with either Federated or Social identities. Provide application owners with a single auth framework for both types of identiies. Provide info to the application about the user with a singel interface regardless of identity type. application owner can choose which social identity providers to permit. Why? We already work with people outside our communities – applicants, parents, continuing ed/MOOCs. Other areas showing interest in working with people outside the traditional communities. All of those people have identities at one of the social/personal providers. This may be preferable to issuing campus identities to those people. However, there is NO guarantee about who is using a social account. How – Web based authentication gateway, translates authentication responses from popular “social” ID services into regular SAML 2 Assertions (consumable by Shibboleth). Allows downstream applications which only understand SAML to easily utilize social IDs. Maps attributes. Works great for guest authentication. Typical use is “pick and choose” among the external services. Very powerful combined with an invitation service like that in Grouper. Consent screen at Social Providers akss users to release attributes to the gateway. Pilot gateway available since Fall 2012, but will end. 2nd Pilot underway, run by Cirrus Identity. Can be used to access I2 Spaces Wiki and InCommon Federation Manager App, currently only supports Google. Next phase – looking to expand use and use cases, require definition, testing during summer 2013, campus participants being identified, hope to have services available to InCommon members for Fall 2013. USC’s OAuth Recipe: oAuth + Enriched Identity Data + Central Authorization – Brendan Belina Benefits of Using OAuth (Social Providers) – extend USC services to greater populations; password related issues addressed by OAuth providers; reduces barriers to adoption. Chalenges: Different versions of OAuth with different capabilities; Inconsistent and unpredictable attribute release; Attributes required for applications may be missing; Identity is self-asserted – potential risk to applications; user may use multiple OAuth providers, leading to login confusion and multiple identifiers; OAuth providers come and go, leading to potential ;loss of identifier persistence; how to revoke an OAuth Login?; Authentication without Authorization What is needed: Allow multiple OAuth providers per identity and the provider should be transparent to the service – addresses problem of user using multiple OAuth providers, addresses problem of deprecated OAuth providers; Deliver a standard attribute set regardless of OAuth provider or version for compatibility with applications; Provide consistent user attribute values to services; Externalize authorization to apps to reduce risk and allow revocation; support for both Just-In-Time provisioning and ETL provisioning.
Benefits of self-registration: registry provides single place for meantenance of user attributes; opportunity to enrich data released by OAuth providers to meet requirements and provide consistency; allow creation of persistent identifiers for use across institutional services; Opportunity to provide linking to multiple OAuth providers to address continuity; ability for user to unlink an OAuth provider or credential; Registry entries can be used for ETL provisioning and authorization to services.
Scotty says you should use OpenID Connect for social authentication instead of OAuth.
Oren Sreebny 