At ±«Óãtv R&D, we have been working on user authentication on media devices for some time now, starting with , and then . Most recently, over the last year we've been working in collaboration with the EBU, other European public service and commercial broadcasters, and device manufacturers, to develop the Cross Platform Authentication (CPA) protocol, the first version of which was by the EBU.
CPA provides a way of securely associating an internet-connected media device with an online user account, to enable delivery of personalised services to the device, for example, media recommendations, bookmarking, and pause/resume of media playback between devices. In its first version, CPA focuses on hybrid (i.e., broadcast and internet) radios, but could also be applied to connected TVs or set-top boxes.
The protocol is based on but adapted to the characteristics of media devices, and to the needs of broadcasters, as described below. The authentication flow is based on the .
The following diagram shows the different entities that participate in the CPA protocol. These are the client, service provider, authorization provider, and (indirectly) the identity provider. The goal of CPA is to grant the client permission to make authenticated API calls to the service provider on behalf of an end user. The authorization provider manages client identities, and the link between the client and the end user's identity (which is obtained from the identity provider).
Device characteristics
Radios typically have small display screens, e.g., a small colour LCD or a two-line text-only display. They also do not have a convenient way for users to input information such as a username or password.
One of our aims in designing CPA was to impose as few extra requirements onto devices as possible, to be as compatible as possible with existing devices. For example, CPA does not require a remote control with a keyboard, or a smartphone with a camera, as in QR code based solutions.
Single sign-on
Another important requirement that CPA addresses is single sign-on. This allows a user to pair their device with a broadcaster's service only once, e.g., for one radio station, then they can remain signed in when listening to any radio station from that broadcaster. Multiple broadcasters can also share a common authorization service, which allows single sign-on across these broadcasters' services, while keeping the user data held by these services separate from each other.
CPA in practice
Recently, we worked with ±«Óãtv and to integrate CPA and RadioTAG, allowing listeners to add tracks to their playlists directly from their radios. Although this is currently only possible on certain prototype radios, we're talking to manufacturers about adding it to their products and are hoping to see it on the shelves in due course.
The video below shows how the sign-in process works from the user's perspective.
The user presses a button on the radio to add the track they're listening to to their playlist. The radio makes a call to Playlister's web API, and receives a HTTP response indicating that authentication is required. This response includes the URL of the authorization provider the radio should use to authenticate.
The radio then calls the authorization provider, firstly to register as a client, then to associate the client with a user account.
In response the radio receives a URL that the user should visit, and a short security code for them to type in, which the radio displays to the user.
On their PC or smartphone, the user visits this URL and the website asks them to sign in and input the security code. This step associates the radio with the signed in user.
By periodically polling the authorization provider, the device automatically detects that the security code has been input correctly, and is given an access token that allows it to store data on behalf of the user. The device can then use this token to add the track to the user's playlist.
For more information
If you want more information about CPA, or have comments or questions about the specification, please contact us via the .
The specification itself is available from the and there are open-source software reference implementations of the client and servers, available on our .
Acknowledgement
We'd like to thank Michael Barroco of the EBU for coordinating the CPA working group, and all the participants in the group for their input and contribution to the development of the protocol.