Unified Social Sign-on (USS) is a proposed identity and access management solution from Eduserv that would allow single sign-on access to both internal and external resources using varying levels of identity assurance. It is intended to support personalization and controlled access to content and transactional services across government websites using existing web identity providers and social networks. Some potential use cases include storing accessibility preferences, anonymous or attributed commenting on documents, and undertaking transactions that require validated identity information. The solution aims to provide a consistent user experience while giving users privacy over how much identity information is shared.

1. Unified Social Sign-on An ‘identity’ platform for government websites Andy Powell

2. Background Eduserv has ~15 year track record as provider of Access and Identity Management (AIM) solutions customer base that includes UK HE/FE, the NHS, Australian Healthcare providers, US, … primary product now known as OpenAthens SAML-compliant - UK Access Management Federation 50% UK university market and significant proportion of academic publishers

3. Emerging trends principle use-case to date – single sign-on to ‘external’ academic content however… seeing trend towards universities becoming providers of services to other universities desire to use single sign-on mechanism for internal resources growing use of social media by staff and students universities and publishers wanting to minimise costs of integration, management, etc. for their ‘access management’ solution

4. Unified Social Sign-on (USS) USS is our emerging response to these trends possible fit with needs in ‘government’ space an identity and access management solution supporting personalisation controlled access to both content and transactional services based on varying levels of assurance about end-user with possibility of federated solution across government

5. Possible use-cases user wants to store accessibility preferences across multiple sessions, browsers or government websites user wants to comment anonymously on consultation document user wants to comment on consultation document using their preferred social network identity user wants to share comments via their social network

6. Possible use-cases user wants to undertake transaction that requires validated email address user wants to undertake transaction that requires confirmation of postal address user wants to undertake transaction that requires confirmation of paper credentials (passport, driving licence, birth certificate, etc.) (last two not included in current USS plans)

7. Assurance and privacy sliding scale of ‘levels of assurance’ by government provider about who the user is (level 0 thru to level 6) corresponding ‘privacy’ concerns by end-user about how much the provider knows about them possible use of two-factor authentication to increase confidence both for and in the end-user (e.g. username and password and PIN sent to mobile phone)

8. Functional specification enable sign-in to government website using existing web identity providers and social networks (Google Apps, Facebook, etc.) and/or using local website username email validation optional second factor authentication using mobile phone consistent user-experience across multiple government websites

9. Functional specification cloud-based solution to minimise effort around installation and management simple API for local integration support for standards – OpenID, OAuth, SAML

10. Functional specification management console to manage identity providers, local user accounts, services protected integration with social network APIs to allow posting of content on behalf of the end-user (with permission)