The TV Everywhere proposition is that cable, satellite & telco TV subscribers should be able to enjoy their subscription content online at different programmer properties – no longer shackled to their TVs or the Multi-Video Programmer Distributors (MVPD)’s own online portals.
In a sense a defensive mechanism against ‘cord cutting,’ the practice by which existing MVPD customers turn away from traditional subscriptions and choose to rely exclusively on online options for their TV entertainment, TV Everywhere is a recognition from those MVPDs that they need to enhance their offering to stay competitive against online video portals such as Hulu and services like Netflix.
First popularized by Comcast & Time Warner in 2009, TV Everywhere was arguably initially slow to take off. Recently however, that appears to be changing. Time Warner claims that over 40 participating networks are involved in deployments and trials. Additionally, a May 2012 report from Parks & Associates cited significant growth in TV Everywhere deployments. NPD Group NPD Group also reported earlier in 2012 that 70 percent of respondents to a global survey said that they have watched TV on a device other than a TV.
Anecdotally, the recent 2012 London Olympics served as the poster-child of TV Everywhere’s coming of age. On its blog, Comcast highlighted that more than 219 million unique viewers in the U.S. tuned in across all screens, and customers on average authenticated 2.4 devices on which to view streaming Olympics content. The BBC showedthe incredible uptick in TV Everywhere, with over 12 million requests for video on mobile across the whole of the Games to complement its 51.9 million TV viewers. Mobile viewing took off at the end of the business day, for local British viewers.
It’s clear that viewing behavior worldwide has embraced multiple devices, so how does the technology behind TV Everywhere meet this demand? Let’s take a look at the identity infrastructure that is integral to future success for TV service providers.
In order for a subscriber to view video content at a programmer portal based on their subscription at an MVPD – the programmer must be able to verify that the user is indeed an MVPD subscriber, and that their subscription entitles them to view the video content in question. How to do this? One option would be for the programmer to ask the subscriber for their account information (i.e. account name & password) at the MVPD and use that information to query the MVPD for the relevant subscription status. While this model could work, it implies that the subscriber’s password be shared with the programmer – a less than ideal security practice (and one the MVPD would be unlikely to endorse).
The alternative model is for the programmer to, rather than itself collecting the subscriber’s name & password, instead ask the MVPD to authenticate the subscriber, and then send back the desired subscription details. In this model, the programmer still obtains the required information about the user’s subscription status & entitlements – but never learns the subscriber’s password. This model is shown below.
In the above, in Step 1, the subscriber requests to view a particular piece of video content from the Programmer. In order to determine whether or not it should grant access to the content, in Step 2 the Programmer sends the user’s browser to the appropriate MVPD, asking that the user be authenticated and their identity be returned, as in Steps 3 & 4. Then, in Step 5 the Programmer can ask if the (now verified) Subscriber should be granted access to a particular piece of content. In Steps 6 & 7 respectively, the MVPD checks the subscription and responds to the Programmer with a yes/no. If the response is affirmative – the Programmer in Step 8 grants the Subscriber access to the requested content and begins the stream.
Steps 2, 4, 5, & 7 in the above presume that the Programmer & MVPD are able to communicate between themselves – in Step 2 the Programmer needs to be able to request of the MVPD that the user be authenticated (and potentially specify a particular piece of video content the User is attempting to access), and in Step 4 the MVPD must be able to send back the Subscriber’s information. Step 5 requires that the Programmer be able to pose queries of the form ‘Can User X view content Y’? – and the MVPD must be able to respond to these queries in Step 7. This sort of communication across independent business entities demands a standard – both to normalize the syntax by which messages are communicated, but also to ensure that an appropriate level of security over the interaction is maintained.
The standards behind TV everywhere
Historically, the Security Assertion Markup Language (SAML) has been the standardized protocol by which the programmer & MVPD shared the subscriber’s authentication & subscription information. In the language of SAML, the MVPD plays the role of the SAML Identity Provider (IdP), authenticating the Subscriber and then communicating the necessary subscription information as parts of an assertion to the Programmer acting as the SAML Service Provider (S). The CableLabs Online Content Authorization (OLCA) specification  defines a standard for TV Everywhere based on SAML. The OLCA specification also points to the eXtensible Access Control Markup Language (XACML) – over simplistically, OLCA uses SAML for authentication (Steps 2 &4 in the above) and XACML for authorization (Steps 5 & 7 in the above).
While many existing TV Everywhere deployments successfully use SAML, a number of factors have caused the TV Everywhere community to define alternative frameworks that do not use SAML as the key standardized underpinning. First of these is that SAML is primarily focused on authentication of the subscriber, yet the fundamental question for the programmer is not who the subscriber is, but rather what video they are allowed to view, i.e. an authorization decision. Consequently, building on SAML for authentication may demand an additional authorization piece, as in the inclusion of XACML in OLCA. Secondly, SAML is not optimized for thick client architectures such as found in native video viewing applications on tablets, phones, & set top boxes. For these reasons, the standards bodies in the TVE space have looked toward extending & evolving their architectures to build on OAuth 2.0 either instead of, or in addition to, SAML.
The Open Authorization (OAuth) protocol first emerged in the consumer social world of Facebook, Twitter etc., before more formalized standardization in the Internet Engineering Task Force (IETF). While OAuth’s original drivers were consumer-centric use cases such as sharing updates with Facebook, or supporting Twitter desktop clients, OAuth has evolved beyond those scenarios to provide security & features demanded of more sensitive applications. OAuth is both 1) more focused on authorization than authentication and 2) more optimized for native applications than SAML. Consequently, OAuth 2.0 was chosen by both the technical standards bodies working on the TV Everywhere space – CableLabs and the Open Authentication Technical Committee (OATC) as the technical platform on which to build a new TV Everywhere architecture - one more able to deal with today’s mobile viewing models.
The OATC is a non-profit industry association of programmers/content owners, MVPDs, technology companies, and system integrators. In early 2012, the OATC released its Online Multimedia Authorization Protocol (OMAP) specification . The OMAP specification defines the architecture, protocols and data formats needed to build and deploy interoperable systems that authorize access to protected media resources on any Internet-connected device.
CableLabs, similarly motivated by the need to support mobile clients, has released its own ‘Authentication and Authorization through Client Applications’  specification - also defined as a profile of OAuth 2.0.
The relationship between the standards chosen as foundational (SAML or OAuth), the TVE focused standards bodies building on top of these foundational standards, and their resultant TVE focused standards, is shown below.
The comparable diagram for an OAuth-based model is shown below:
Because OAuth more directly deals in authorization (the fundamental semantic of TVE) the flow is significantly simpler than that of the SAML flow above. Rather than the Programmer asking who the user is, they pose the more important ‘what video content can they view’ question.
Whether based on the CableLabs or OATC OAuth-based framework, TV Everywhere promises to give subscribers flexibility in greater in viewing TV content online, across a range of devices & services. Of course, the broader requirements of multiple devices, login usability, and authorizations are not unique to viewing TV content and are just as relevant to the enterprise & SaaS.
 - http://cablelabs.com/specifications/CL-SP-AUTH1.0-I04-120621.pdf
 – http://www.oatc.us/Standards/DownloadOMAPStandard.aspx
 - http://cablelabs.com/specifications/CL-SP-AUTH-APP-I01-120118.pdf