RadioTAG Application Team A. Buckingham Global Radio May 2013 Improving Authentication in RadioTAG draft-radiotag-auth-01 Abstract The current authentication methodology employed in RadioTAG draft 5 offers a poor user experience with repeated operations when a Listener interacts with Services from more than one Service Provider. This document proposes alterations to this methodology to improve this User Experience and provide a solution for Single Sign On across Services digital assets. Table of Contents 1. Introduction 2. Use Cases 3. Authentication Models 3.1. Current authentication model 3.2. Revised authentication model 4. Single Sign On 4.1. Login procedure 4.2. Discovery methodology 5. Entity definitions 1. Introduction In the current authentication model for RadioTAG, relationships are formed between a Devices, Users and Service Provider. This means that a Listener can complete registration with a Service and, by design, be able to interact with any Service from the same Service Provider without further intervention. When the Listener begins listening and interacting with another Service from a different Service Provider, however, they will have to perform the same registration steps again. It would also be an improved User Experience if a Listener could authenticate with the website of any Service irrespective of Service Provider and view all their tags from all their Devices, against all Service Providers. This would help reduce the cognitive load on a Listener by not having to remember which Service they previously Tagged to review that Tag event. It is also worth considering what other possibilities an industry- wide authentication model opens up for Radio that benefits both Listeners, Service Providers and Manufacturers alike. 2. Use Cases o Andy is listening to Bayern 3 on his DAB radio, when he hears something he is interested in, and wants to find out more about later. He pushes the Tag button on his radio, and his radio confirms the action with a brief summary of what he's listening to. He can come back and read this brief summary on the radio later. As his radio has a small (10cm) screen, he wants to use his tablet computer to read more about his Tagged item. He goes to the Bayern 3 website, and completes a short process to register himself as a User, and then enters a code provided by Bayern 3 into his radio, which associates his radio with him. He can now see the Tag that he made whilst listening to Bayern 3 on the Bayern 3 website on his tablet computer. He can also see Tags from other Services (Bayern 1, Bayern 2, etc.), because they are provided by the same Service Provider (Bayrische Rundfunk). He can access detailed additional information associated with the Tags on his preferred device. o Ben has a car radio which he has previously used to only tag BBC Radio 1 (Service) and as a result is registered with the BBC (Service Provider). He changes station and tags Capital FM (Service), which is from a different Service Provider (Global Radio). Under the current draft, because Capital FM is owned by a different Service Provider, a fully registered tagging experience would be unavailable for this Service until the registration steps were performed again. This would continue to happen for each new Service. Furthermore it's important to realise that while for some "networks" of Services operated by a Service Provider, the ownership is obvious (BBC Radio 1, BBC Radio 2 etc.), other Service Providers use differing brands for each service (Capital FM, Classic FM, Heart) which could further confuse a Listener as to why registration is required again. This process should be as seamless as possible. Once Ben has completed registration, Service's should share the authentication details to avoid repeating the registration process. o Pete has owned a RadioTAG enabled device for many months now and recently decided to purchase another for a different room of the house. In the current draft, after having to complete registration multiple times for differing Service Providers, he would then have to perform all those repeated registrations again to enable the device. This should be simplified so a single registration can be performed per device and then work across all Services. o Byrion hears a new track from his favourite band and hits the 'Tag' button to record it. A few days later he wants to find the Tagged Event again to find out more information, but can't remember which Service he was listening to when he originally heard it. Byrion will have to remember which Service he tagged and go to that Service in order to see his Tag. It is not possible for Byrion to go to any Service in order to see all his Tags from all Services. With a single sign on and discovery mechanism the Listener could visit any Service Provider, sign in using the same login details and view all Tags for all Devices across all Service Providers. 3. Authentication Models This section proposes a variation of the current RadioTAG specification to allow a shared authentication provider to authenticate users across multiple Service Providers to improve user experience. The details is intentionally "high level" as this document is intended to provide a starting point for future more detailed technical discussions. 3.1. Current authentication model In the current RadioTAG specification, the authentication model is based upon the device agreeing a relationship with the service provider. This means that once authenticated with one of the Services from a Service Provider, it will be authenticated with all Services by that provider. However, when a listener tags another station not owned by that provider they must repeat the whole process again. +--------+ +----------+ | |--(A)----- Tag Request ----->| | | | | | | |<-(B)------ Auth Grant ------| | | | | | | |--(C)------ Auth Grant ----->| Service | | Device | | Provider | | |<-(D)------ Auth Token ------| | | | | | | |--(E)- Tag Request + Token ->| | | | | | | |<-(F)---------- OK ----------| | +--------+ +----------+ Figure 1: Abstract Protocol Flow The abstract RadioTAG draft flow illustrated in Figure 1 describes the interaction between a Device and a Service Provider and includes the following steps: (A) A naïve unauthenticated tag request is made to the Service Provider. (B) Service Provider rejects the request but provides a Grant for the Device to exchange for an authenticated Token. (C) Device returns the grant back to the Service Provider. (D) Service Provider returns a Token for the Device to use in future requests to prove authentication. (E) Device repeats the Tag request with the Token. (F) Service Provider responds with an OK status to confirm Tag. 3.2. Revised authentication model If the Service is able to nominate an alternative entity for authentication (similar to the methods offered in OAuth) it would be possible for multiple Service Providers to share a common trusted Authentication Provider. Once the first registration has been completed, the User would not have to register again for any Service/ Service Provider using the same Authentication Provider. +--------+ +----------+ +----------+ | |--(A)----- Tag ----->| |--(B)-- Auth ->| | | | | Service | | Auth | | |<-(D)----- Fail -----| Provider |<-(C)-- Fail --| Provider | | | | | | | | | +----------+ | | | | | | | |--(E)---------------- Auth Request ------------>| | | Device | | | | |<-(F)----------------- Auth Token --------------| | | | | | | | +----------+ | | | |--(G)- Tag + Token ->| |--(H)- Token ->| | | | | Service | | | | |<-(J)------ OK ------| Provider |<-(I)-- OK ----| | | | | | | | +--------+ +----------+ +----------+ Figure 2: Alternative Protocol Flow The abstract revised flow in Figure 2 demonstrates how a 3rd party Authentication Provider could be used and includes the following steps: (A) A tag request with an invalid authentication attempt is made to the Service Provider. (B) Service Provider forwards the authentication attempt to a 3rd Party, trusted Auth Provider. (C) Auth Provider rejects the invalid credentials. (D) Service Provider forwards the failure to the Device and informs the Device which Auth Provider to authenticate with directly. (E) Device completes authentication with Auth Provider directly. (F) New Token returned to Device. (G) New Token is used by the Device in next request to Service Provider. (H) Service Provider confirms Token is valid with Auth Provider. (I) Auth Provider confirms valid Auth Token to Service Provider. (J) Service Provider completes Tag and returns confirmation to Device. It is reasonable to expect that most smaller territories would be able to agree on a single trusted organisation to fulfil the role of Auth Provider (for example, in Great Britain the "UK Radio Player" project is an organisation co-funded and controlled by a consortium of broadcasters). However some territories, particularly those much larger, may have one or more organisations suitable for this role. Furthermore most territories border others, where listeners close to those borders are likely to consume services from two or more territories due to the nature of broadcast reception. It is crucial therefore that auth providers can work in both standalone and interoperable modes, where with bilateral agreements in place, they can share non-identifiable information about a device or user to give a simple, unified experience to the end user. For example, if service providers in different territories communicated with each other you would then be able to use the same device token internationally, with different broadcasters, even if they are members of different Trusted Authentication Providers. +--------+ +----------+ | | | | | |--(A)- Auth Req ->| Auth | | Device | | Provider | | |<-(B)--- Token ---| 1 | | | | | +--------+ +----------+ +--------+ +----------+ +----------+ | | | | | | | |--(C)- Auth Req ->| Auth |--(D)- Auth Req ->| Auth | | Device | | Provider | | Provider | | |<-(F)---- OK -----| 2 |<-(E)---- OK -----| 1 | | | | | | | +--------+ +----------+ +----------+ Figure 3: Syndication Protocol Flow The abstract syndication flow in Figure 3 demonstrates how a user registered with one Authentication Provider can be authenticated via a different Authentication Provider. (A) Device initial makes an Authentication request with Auth Provider 1. (B) Auth Provider 1 returns a token for Device to store. (C) A later transaction between Device and a different Service Provider instructs Device to interact with Auth Provider 2 (D) The token informs Auth Provider 2 that Auth Provider 1 is authoritative for this device and so the token request is relayed over a trusted connection, so that Auth Provider 2 can also confirm the validity of the token. (E) A response from Auth Provider 1 confirms the validity of the token. (F) Auth Provider 2 confirms the device is now ready to interact with the Service Provider that preceded Step A. 4. Single Sign On and Syndication This section discusses a way that 'single sign on' could be implemented on individual Service's websites. 4.1. Login procedure Convincing people to sign up for another website or service is always a struggle and considering the recent trends in using third party sites for authentication, which users are already likely to hold accounts for, this is an interesting area to explore to drive the SSO login procedure. As an example, today Twitter, Google+ and Facebook logins are all commonly used by 3rd party websites. If a common identifier could be obtained from any of these login systems, it could be secured via a hashing algorithm and then exchanged with the Auth Provider to obtain non-identifiable information about which other Services and Auth Providers have knowledge of this user. +------+ +---------+ | | | | | |--(A)- Login ->| Service | | | | | | | +---------+ +----------+ | | | | | |--(B)---------------- Login --------------->| | | | | | | | +---------+ | Twitter | | | | | | | | User | | |<-(C)---- ID -----| | | | | | | | | | | | +----------+ | | | | | | | Service | +----------+ | | | | | | | | | |--(D)- Hash(ID) ->| Auth | | | | | | Provider | | |<-(F)-- View --| |<-(E)-- Profile --| | | | | | | | +------+ +---------+ +----------+ Figure 4: Single Sign On Procedure The abstract SSP procedure in Figure 4 demonstrates how a user could sign in through a "recognised" 3rd party, but a common identification parameter could be hashed and used to exchange further profile details with an independent Auth Provider. (A) User goes to the login page for the Service which provides a link to login via Twitter (B) User logins directly with Twitter. (C) Identification details are passed back to the Service. (D) The Service hashes a specific ID value to refer to the User with the Auth Provider. A hash could protect a useful parameter such as e-mail address without disclosing the value. (E) Additional profile information known by the Auth Provider are returned to the Service. (F) Using the additional details obtained from the Auth Provider Beyond the scope of this explanation, the details obtained from the auth provider can then be used to syndicate data from other Service Providers. 5. Entity definitions The document discuss relationships between 3 different entities: Service A particular radio brand or station Service Provider The organisation behind one (or more) Services Authentication Provider An organisation that is trusted in some way by two or more Service Providers