Defining TVE Home-Based Authentication (HBA) Use

Open Authentication Technical Committee
Defining TVE Home-Based Authentication (HBA)
Use Cases and Requirements
Adobe, Cox, DirecTV, Synacor, Turner
8/20/2014
Version 1.0
Defining TVE Home-Based Authentication Use Cases and Approaches to Supporting Them
Contents
Introduction ........................................................................................................................................................ 3
Categorized HBA use case scenarios ................................................................................................................... 5
General Recommended Requirements and Constraints for HBA ......................................................................... 5
TV Everywhere Foundation ................................................................................................................................. 6
1. Unlimited Household Access ........................................................................................................................... 7
2. Basic restrictions ............................................................................................................................................. 9
3. Fully featured restrictions and subaccounts ................................................................................................... 14
Summary .......................................................................................................................................................... 22
Appendix ........................................................................................................................................................... 23
AuthN Level of Assurance ............................................................................................................................. 23
Stream Limiting and Fraud Management ...................................................................................................... 23
Decision/Support Matrix................................................................................................................................ 24
20 August 2014 – Draft M - Open Authentication Technical Committee
2
Defining TVE Home-Based Authentication Use Cases and Approaches to Supporting Them
LEGAL NOTICE
Copyright © Open Authentication Technology Committee 2014. All rights reserved.
This recommended practice (“Recommended Practice”) may be copied in its entirety and displayed or
distributed to others, provided that the above copyright notice and this legal notice section are preserved on all
such copies. No license is granted to modify the Recommended Practice.
THIS RECOMMENDED PRACTICE IS PROVIDED ON AN “AS-IS” BASIS, WITHOUT ANY EXPRESS OR IMPLIED
WARRANTY OF ANY KIND, INCLUDING WITHOUT LIMITATION ANY WARRANTY OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT OF ANY PARTY’S INTELLECTUAL
PROPERTY.
OATC HEREBY DISCLAIMS ANY AND ALL LIABILITY FOR PERSONAL INJURY OR PROPERTY OR OTHER
DAMAGE, OF ANY NATURE WHATSOEVER, WHETHER SPECIAL, INDIRECT, CONSEQUENTIAL OR
COMPENSATORY, DIRECTLY OR INDIRECTLY RESULTING FROM THE PUBLICATION OR USE OF, OR ANY
RELIANCE UPON, THIS RECOMMENDED PRACTICE.
Implementation of this Recommended Practice is voluntary. Subject to the rights granted to OATC’s members
under the OATC IPR Policy, no rights or licenses under any patent claims are granted hereby. OATC takes no
position regarding the validity or scope of any intellectual property or other rights that might be claimed to be
infringed by the implementation of this Recommended Practice or the extent to which any license under such
rights might or might not be available, and OATC does not represent that it has made any effort to identify any
such rights or conduct any inquiries into the validity or scope of any such rights.
20 August 2014 – Draft M - Open Authentication Technical Committee
3
Defining TVE Home-Based Authentication Use Cases and Approaches to Supporting Them
Introduction
In-home automatic authentication is the process by which an MVPD/OVD uses characteristics of the home
network (or identifiers automatically accessible between devices on the home network) to authenticate which
subscriber account is associated with that home network so that users do not need to manually enter
credentials when establishing a TV Everywhere (TVE) session for accessing TVE protected content. For
simplification, this document refers to home-based authentication as HBA.
This document organizes use cases into groups based on the complexity needed to establish precise individual
identification as part of the automatic authentication process. The goal in grouping the use cases in this
manner is to highlight those use cases where the barrier to wide use of automatic home-based authentication
(HBA) is minimal so it could be widely adopted right away, while also providing specific requirements for more
complex scenarios so that additional work can be done to enable those use cases as soon as possible.
A working HBA solution might ultimately depend on several TVE technologies, including: user account
identification, stream limiting, content restrictions, and personalization. The scope of this document does not
include user account identification or stream limiting. Although account identification through the user’s
network connection is a critical component of HBA, the solutions are either trivial, such as when the operator
also provides the user’s IP address, or operator specific, such as when the identification is obtained through
custom communication with the operator’s set top box. In addition, there are numerous solutions already in
place that address stream limiting and fraud management. They are sufficiently decoupled from the
authentication process as to be addressed separately.
Content restriction and enforcement is dependent upon the identity obtained through the authentication
phase. Inasmuch as many operators have content restriction considerations or capabilities in place, it becomes
necessary to address methods by which HBA can support identity management in cases where content
restrictions apply. These content restriction considerations drive the complexity in many of the use cases.
20 August 2014 – Draft M - Open Authentication Technical Committee
4
Defining TVE Home-Based Authentication Use Cases and Approaches to Supporting Them
Categorized HBA Use Case Scenarios
Based on the estimated complexity of implementation, the recommended categories for home-based
authentication use case scenarios follow:
1. Unlimited household access scenarios
This group of use cases enables MVPDs that don’t support subaccounts or MVPDs that aren’t worried about
restrictions like parental controls to simply assign the single supported account identifier in the HBA flow.
2. Basic restriction and subaccount scenarios
This group of use cases enables basic restrictions and/or subaccounts.
3. Full-featured restrictions and subaccount scenarios
This group of use cases enables full-featured restrictions and over-ride workflows. The experience options
range from allowing users a one-time opt-in to HBA by accepting terms, to full featured restrictions with
overrides.
4. Revert to credential authentication
This group of use cases identifies when HBA can’t yet be used, so it’s recommended to fall back to standard
credential authentication.
General Recommended Requirements and Constraints for HBA
The general recommendation is to reduce constraints and use the simplest solution that works. For example, it
may be OK to ignore restriction complexity as part of HBA for major events or children’s oriented channels.
When an operator does provide a means for users to manage restrictions through TVE, it may be sufficient to
simply provide restriction hints to the programmer to manage the restrictions such as parental controls on their
own.
Operators will generally have several ways to apply their content restriction business policies in the context of
HBA.
 Ignore restrictions if they are technically unsupported or not applicatlble in some cases
 Offer opt-in/opt-out for restrictions, which is detailed in categories section 2 and 3.
 Push to programmers to handle restrictions, which works with the concerned programmer case below
 Implement restrictions, ranging from simple to complete and detailed in categories section 2 and 3. In
this case, an operator’s existing restriction systems are the main consideration in choosing between
solutions to the respective use cases
For some of the less restricted use cases, programmers whose content may generate concerns regarding
parental controls can still setup their own parental control systems, which is covered more in under category
20 August 2014 – Draft M - Open Authentication Technical Committee
5
Defining TVE Home-Based Authentication Use Cases and Approaches to Supporting Them
section 3. This case decouples parental control from HBA to some extent. Simply identifying HBA
authentications may be sufficient to support this.
TV Everywhere Foundation
Home-based Authentication builds on existing TV Everywhere standards for authentication and authorization.
The basic process involves two separate flows: one for authentication, or user identification, and one for
authorization, or user subscriptions and rights. The diagram below illustrates these flows with the information
that passes between a User’s browser or app, a Programmer (or Content Provider) and an MVPD. The HBA
requirements for each use case that follows are illustrated relative to this diagram.
User
Identification
Login Request
Content
Provider
Channel ID
Channel ID
Login Page
Credentials
Account ID
Welcome
MVPD
Account ID
Content Request
Authorization Request for Account ID
Authorization Grant for Account ID
Credentials
Account ID
Rights Lookup
for Account ID
Rights
Content
Delivery
20 August 2014 – Draft M - Open Authentication Technical Committee
6
Defining TVE Home-Based Authentication Use Cases and Approaches to Supporting Them
1. Unlimited Household Access
The following scenarios are recommended for unlimited household access. These cases can be dependent on
the state of the MVPD’s account system or whether restrictions are a priority for them.






MVPD doesn’t support restrictions (e.g. parental controls), so the user can’t setup restrictions whether
or not subaccounts are supported
The user can’t set up subaccounts AND the user can’t set up restrictions
The MVPD or the User hasn’t bothered to setup subaccounts
The MVPD or the User hasn’t bothered to setup restrictions for subaccounts
MVPD is comfortable using household account for HBA even when subaccounts with or without
restrictions for a limited time period to support a high profile event.
Single sign-on for these user sessions may be unbounded/unscoped by a specific channel that
originated the session
These scenarios can be broken down into two main buckets as follows.
1a. MVPD doesn’t support parental controls.
When MVPDs don’t support parental control restrictions, then MVPD solutions to subaccount specific
restrictions are unnecessary. Subaccounts are useful only for personalization, so the MVPD that supports
subaccounts can chose to ignore that and just focus on enabling HBA.
Programmers that are highly concerned about parental controls given their content can setup their own
parental control systems which is covered more in section 3.
MVPD conditions
 Don’t support parental
controls
Programmer content condition
 Any content
HBA Viewer Experience
 HBA enabled using
household account
1b. MVPD doesn’t support subaccounts or subaccount not setup by MVPD or User.
When MVPDs don’t support subaccounts, the need to worry about restrictions associated with subaccounts
clearly goes away. The only possible approach to restrictions would apply to the entire household which is
quite restrictive unless override capabilities exist (section 3) or applied as basic channel restrictions in a limited
manner (section 2). Restriction overrides in federated TVE flows are not supported anywhere today which
makes the likelihood of that case pretty small. Simple channel blocking (section 2) for the whole household is
also unlikely, but more realistically deployable in current TVE implementations. Given these considerations,
there is likley to be a class of MVPDs for which the lack of subaccount support will mean that restrictions aren’t
20 August 2014 – Draft M - Open Authentication Technical Committee
7
Defining TVE Home-Based Authentication Use Cases and Approaches to Supporting Them
applicable in the HBA flow. The MVPDs that don’t support subaccounts don’t have personalization anyway, so
can just enable HBA on the household account.
MVPD conditions
 Don’t support subaccounts
 Either also don’t support
restrictions or aren’t
concerned with restrictions
for HBA
Programmer content condition
 Any content
HBA Viewer Experience
 HBA enabled using
household account
User
Account ID found?
Identification
Content
Provider
Login Request
Channel ID
Channel ID, NID
Account ID
MVPD
NID (e.g. IP)
Account ID
Login Page
Credentials
Account ID
No
Credentials
Account ID
Account ID
Welcome
20 August 2014 – Draft M - Open Authentication Technical Committee
8
Defining TVE Home-Based Authentication Use Cases and Approaches to Supporting Them
2. Basic restrictions
The following scenarios are recommended for basic HBA restrictions. These cases allow for mostly simple
approaches to blocking content or opting to ignore subaccounts in the HBA flow.





MVPD doesn’t support subaccounts and relies on channel blocking at login for channel based restriction
(no overrides). Some channels get through HBA as above, household access
MVPD allows household account use for HBA for specific channels - even when subaccounts with or
without restrictions are available. Examples are a high profile event or rated G/TV-Y channels
MVPD doesn’t support subaccounts and relies on the programmer to filter content based on restriction
hint in the HBA response
MVPD approves using household account when a Programmer-provided Terms and Conditions
agreement is accepted by the user
Single sign-on could be bound to the channel originating the HBA session in these scenarios when
channel blocking is fully enabled by the Operator
2a. MVPD doesn’t support subaccounts, but supports channel blocking at login.
When MVPDs support channel blocking as a form of parental control, and enforce that block by disallowing
HBA on blocked sites or apps, additional controls are needed to manage when HBA can be applied. HBA should
be applied to all unblocked sites or apps, while credentials should be applied to blocked sites or apps. In this
case, credentials act as an override.
See technical reference to AuthN Level of Assurance in Appendix
Programmers whose content may generate concerns regarding parental controls can setup their own parental
control systems which is covered more in section 3.
MVPD conditions
 Don’t support subaccounts
 Support channel blocking
restrictions
Programmer content condition
 Any content (for unblocked
sites or apps)
20 August 2014 – Draft M - Open Authentication Technical Committee
HBA Viewer Experience
 HBA enabled using
household account for
unblocked sites or apps
 User must present
credentials to blocked sites
or apps
9
Defining TVE Home-Based Authentication Use Cases and Approaches to Supporting Them
User
Channel ID white-listed?
Account ID found?
Identification
Content
Provider
Login Request
Channel ID
Channel ID, NID
MVPD
NID (e.g. IP)
Account ID
Login Page
Account ID
No
Credentials
Account ID
No
Credentials
Account ID
Account ID
Welcome
2b. MVPD allows household account use for HBA for specific channels.
Typically, when MVPDs support subaccounts, each household user (subaccount) is required to identify him- or
herself – potentially with credentials – so that exiting parental controls can be applied or usage history can be
used for personalization. MVPDs can alternatively use the household (master) account for pre-approved
channels and events to avoid the intervening subaccount identification. For example, MVPDs might take this
step because the channel is known to provide content of appropriate rating and high interest (e.g., major
sporting events).
In these situations, MVPDs could take steps outlined in 2a to provide authentication to designated sites or apps
using the household account. The same rules and limitations around availability and SSO would be enforced.
Therefore, when a household user who was HBA authenticated for an HBA-approved site or app using the
household account, then navigates to non-HBA-approved site or app, they will be prompted to identify
themselves and supply credentials where appropriate.
MVPD conditions
 Support subaccounts
 Support household account
use for appoved channels
Programmer content condition
 Any content (for unblocked
sites or apps)
20 August 2014 – Draft M - Open Authentication Technical Committee
HBA Viewer Experience
 HBA enabled using
household account for
unblocked sites or apps
 User must self identify or
present credentials to
blocked sites or apps
10
Defining TVE Home-Based Authentication Use Cases and Approaches to Supporting Them
User
Channel ID white-listed?
Account ID found?
Identification
Content
Provider
Login Request
Channel ID
Channel ID, NID
Account ID
Login Page
Account or
SubAcct ID
MVPD
NID (e.g. IP)
Account ID
No
Credentials
SubAcct ID
No
Credentials
SubAcct ID
Welcome
2c. MVPD doesn’t support subaccounts and relies on the programmer to filter content.
When MVPDs don’t support subaccount or channel blocking, but need to restrict the content accessed through
HBA-authentication based on rating, they could rely on programmers to block content above a maximum
rating communicated during authentication. In this scenario, the MVPD would communicate one maximum
rating for credential-based authentication, and another for HBA-authentication. The programmer would
assume responsibility for limiting the content based on the maximum rating.
Additionally, the MVPD and programmer should provide a means for HBA-authenticated users to
unauthenticate and reauthenticate with credentials in the case the user wants to access content beyond the
HBA-authentication maximum ratings – covered more in section 3. Programmer sets AuthN Context to
request credential authN (no HBA). There may be lightweight approaches to overriding blocked access
content that could be included here.
20 August 2014 – Draft M - Open Authentication Technical Committee
11
Defining TVE Home-Based Authentication Use Cases and Approaches to Supporting Them
MVPD conditions
 Don’t support subaccounts
 Don’t support channel
blocking restrictions
 Communicate type of
authentication (HBA or
credential) and maximum
ratings for each
 Can trigger credential authN
for non-conforming use case
Programmer content condition
 Content not exceeding the
maximum rating
communicated at
authentication
HBA Viewer Experience
 HBA enabled for all sites or
apps
 Content restricted by
maximum rating
associated with
authentication type (HBA
or credentials)
 User can present
credentials to gain higher
maximum rating
 Must login if content
exceeds HBA rating
User
Account ID found?
Identification
Login Request
Channel ID
Content
Provider
NID (e.g. IP)
Account ID,
Max Rating
Channel ID, NID
Account ID,
Max Rating
No
Login Page
Account ID,
Max Rating
MVPD
Credentials
Account ID,
Max Rating
Credentials
Account ID,
Max Rating
Welcome
Content Request
Authorization Request for Account ID
Authorization Grant for Account ID
No
Content Rating
<=
Max Rating?
Rights Lookup
Rights
Content
Deny
Delivery
2d. Programmer provides Acceptance of Terms and Conditions.
When MVPDs don’t support subaccounts with restrictions or channel blocking, but want to require users to
acknowledge their understanding of the HBA system and the content it provides, they could rely on
programmers to present Terms and Conditions to the user, and allow access only to those users acknowledging
20 August 2014 – Draft M - Open Authentication Technical Committee
12
Defining TVE Home-Based Authentication Use Cases and Approaches to Supporting Them
their acceptance. Having recorded the acceptance, the programmer could the skip the Terms and Conditions
for users of the same account on subsequent visits.
MVPD conditions
 Don’t support subaccounts
with restrictions
 Don’t support channel
blocking restrictions
Programmer content condition
 User has accepted Terms and
Conditions
HBA Viewer Experience
 HBA enabled for all sites or
apps
 User must accept Terms
and Conditions on each site
or app that accepts HBAauthentications
User
Previously
Accepted?
Account ID found?
HBA?
Identification
Content
Provider
Login Request
Channel ID
Account ID, HBA
No
Accepted?
Record
Yes
No
Yes
Channel ID, NID
Account ID,
HBA
Terms
Accept
Login Page
Deny
Credentials
Account ID
MVPD
NID (e.g. IP)
Account ID
No
Credentials
Account ID
Welcome
2e. SSO channel blocking.
If single sign on is supported across programmers, the scope of an authentication must also be managed.
Authentications provided by HBA must be managed separately from authentications provided by credentials.
If MVPD single sign on (SSO) is supported, after receiving authentication on an HBA-approved site or app, users
should be prompted to enter credentials after navigating to a non-HBA-approved site or app.
-
In an SSO flow, blocked sites or apps or apps should inform the user that they aren’t authenticated
given the restrictions. This could lead to triggering a Force AuthN secondary flow, which is covered
more in section 3. Programmers will need enough information back from the AuthN failed response to
convey this state.
-
Programmer terms and conditions acceptance
20 August 2014 – Draft M - Open Authentication Technical Committee
13
Defining TVE Home-Based Authentication Use Cases and Approaches to Supporting Them
3. Fully featured restrictions and subaccounts
The following are the most complex and full-featured scenarios. These use cases range from simple account
pickers and terms of acceptance to restrictions with overrides. When the full range of override capabilities is
supported, users could get to any content via HBA using overrides even when full restrictions and subaccounts
are place.






MVPD supports subaccounts without restriction and accepts presenting a simple account picker to the
user during HBA flow. MVPD provides account picker as a means for personalization, not restrictions
MVPD supports subaccounts with restrictions and still accepts presenting an account picker and does
either channel blocking or passes the restriction hint in the HBA response for programmer filtering
MVPD doesn’t support subaccounts and relies on authorization as the means for enforcing restrictions
with programmers by sending the content rating on authZ
MVPD approves using household account when MVPD-provided Terms and Conditions Terms and
Conditions are accepted by the user as part of the HBA flow
MVPD only supports single household account and has restrictions, but allows for a PIN override for the
restriction.
MVPD supports subaccounts and has restrictions and allows for an account picker with PIN override for
the restriction
20 August 2014 – Draft M - Open Authentication Technical Committee
14
Defining TVE Home-Based Authentication Use Cases and Approaches to Supporting Them
3a. No MVPD restriction concern.
MVPD supports subaccounts without explicit restriction for end user and doesn’t care enough to include
channel blocking and accepts presenting a simple account picker to the user during HBA flow. MVPD provides
account picker as a means for personalization, not restrictions. Programmers with restricted content would not
be applicable – unless managed completely on their own.
MVPD conditions
 MVPD has subaccounts,
without restrictions
 MVPD supports subaccount
HBA auth, without requiring
PIN or Password
 MVPD does not return
restrictions in auth response
Programmer content condition
 Content does not require
restrictions – unless managed
by Programmer
independently
 Content personalization
based on end user attributes
HBA Viewer Experience
 Account Picker rendered
 HBA enabled, after
Account Selection
User
SubAcct picker
Account ID found?
Identification
Content
Provider
Login Request
Channel ID
Channel ID, NID
SubAcct ID
MVPD
NID (e.g. IP)
SubAcct ID
Login Page
Credentials
SubAcct ID
No
Credentials
SubAcct ID
SubAcct ID
Welcome
3b. MVPD restriction concern handled through household account.
MVPD supports subaccounts without explicit restriction settings for the end user/subaccount, supports channel
blocking, and accepts presenting a simple account picker to the user during HBA flow. MVPD provides account
picker as a means for personalization, not restrictions. Any channel blocking restriction could be householdwide and can be applied to all selected subaccounts.
20 August 2014 – Draft M - Open Authentication Technical Committee
15
Defining TVE Home-Based Authentication Use Cases and Approaches to Supporting Them
MVPD conditions
 MVPD has restriction on
household account only
 MVPD subaccounts, don’t
support restrictions
 MVPD supports subaccount
HBA auth, without requiring
PIN or Password
 MVPD could block channels
on HBA.
Programmer content condition
 Specific channels could be
blocked from HBA
 Content personalization
based on end user attributes
HBA Viewer Experience
 Account Picker rendered
 HBA enabled, after
Account Selection
User
Channel ID black-listed
for SubAcct ID? SubAcct picker
Account ID found?
Identification
Content
Provider
Login Request
Channel ID
Channel ID, NID
SubAcct ID
Login Page
MVPD
NID (e.g. IP)
SubAcct
ID
Yes
Credentials
SubAcct ID
No
Credentials
SubAcct ID
SubAcct ID
Welcome
20 August 2014 – Draft M - Open Authentication Technical Committee
16
Defining TVE Home-Based Authentication Use Cases and Approaches to Supporting Them
3c. MVPD trusts account selection.
MVPD supports subaccounts with restrictions and still accepts presenting an account picker and does either
channel blocking or passes the restriction hint in the HBA response for programmer for filtering. Programmers
with restricted content must enforce restriction upon access to site or app or asset.
MVPD conditions
 MVPD has subaccounts,
with restrictions
 MVPD supports subaccount
HBA auth, without
restriction overrides (PIN or
Password)
 MVPD returns restrictions in
authentication response
Programmer content condition
 Content may require
restrictions
 Content blocks/filtering access
at the site or app or asset level
HBA Viewer Experience
 Account Picker rendered
 HBA enabled, after
Account Selection
 Potential
restriction/filtering notice
message after successful
HBA enabled, or
restriction notice message
upon asset viewing
User
SubAcct picker
Account ID found?
Identification
Content
Provider
Login Request
Channel ID
MVPD
Channel ID, NID
Account ID,
Max Rating
NID (e.g. IP)
SubAcct ID,
Max Rating
No
Login Page
Account ID,
Max Rating
Credentials
Account ID,
Max Rating
Credentials
Account ID,
Max Rating
Welcome
Content Rating
<=
Max Rating?
Content Request
Authorization Request for Account ID
Authorization Grant for Account ID
No
Rights Lookup
Rights
Content
Deny
Delivery
3d. MVPD global default through Authorization.
20 August 2014 – Draft M - Open Authentication Technical Committee
17
Defining TVE Home-Based Authentication Use Cases and Approaches to Supporting Them
MVPD doesn’t support subaccounts and relies on authorization as the means for managing default restrictions
assigned to all households by MVPD. Programmers send content rating on authorization request, unless not
serving restricted content.
MVPD conditions
 MVPD supports HBA
 MVPD has no subaccounts
 MVPD provides data with
AuthN response indicating
HBA that can be used with
AuthZ request (should be
tranparent to Programmer)
 MVPD assigns default
restrictions to household,
but doesn’t support user
defined control
MVPD returns restrictions in
authorization response
Programmer content condition
 Content requires restrictions
 Content access is blocked at
the site or app or asset level
HBA Viewer Experience
 HBA enabled upon
confirmation
 Potential restriction notice
message after succesful
HBA enabled, or warning
message upon asset
viewing
User
Account ID found?
Identification
Login Request
Channel ID
Content
Provider
NID (e.g. IP)
Channel ID, NID
Account ID,
HBA
Account ID
No
No
Login Page
MVPD
Credentials
Account ID
Credentials
Account ID
Account ID
Welcome
Content Request
Authorization Request for Account ID, HBA
Authorization Grant for Account ID
Rights Lookup, HBA
Rights
No
Content
Rights
Granted?
No
Deny Rights
Deny
Delivery
Content Rating
<=
HBA Max Rating?
3e. Subscriber restrictions through Authorization.
20 August 2014 – Draft M - Open Authentication Technical Committee
18
Defining TVE Home-Based Authentication Use Cases and Approaches to Supporting Them
MVPD doesn’t support subaccounts and relies on authorization as the means for restrictions set by the
subscriber for the household. Programmers send content rating on authorization request, unless not serving
restricted content.
MVPD conditions
 MVPD supports HBA
 MVPD has no subaccounts
 MVPD supports user
defined restriction control
and may assign a default
restriction that can be
changed by subscriber
 MVPD returns restrictions in
authorization response
Programmer content condition
 Content requires restrictions
 Content access is blocked at
the site or app or asset level
HBA Viewer Experience
 HBA enabled upon
confirmation
 Potential restriction notice
message after succesful
HBA enabled, or warning
message upon asset
viewing
3f. Term and Conditions generically for all channels.
MVPD approves using household account when MVPD-provided acceptance of Terms and Conditions is
approved by the user as part of the HBA flow. Terms and Conditions apply to all content regardless of channel
and content rating.
MVPD conditions
 MVPD supports HBA for
household accounts
 Requires approval of Terms
and Conditions for HBA
access
Programmer content condition
 All content is available when
user accepts Terms and
Conditions.
20 August 2014 – Draft M - Open Authentication Technical Committee
HBA Viewer Experience
 HBA enabled using
household account, upon
acceptance of Terms and
Conditions
19
Defining TVE Home-Based Authentication Use Cases and Approaches to Supporting Them
User
Previously
Accepted?
HBA?
Content
Provider
Identification
Previously
Accepted?
Account ID found?
Accepted?
Login Request
Channel ID
Channel ID, NID
Account ID
MVPD
Terms
Accept
Account ID
NID (e.g. IP)
Account ID
Terms
Accept
Account ID
No
Login Page
Account ID
Welcome
No
Credentials
Account ID
No
Credentials
Account ID
Record
3g. Terms and Conditions for specific channels.
MVPD approves using household account when MVPD-provided acceptance of Terms and Conditions
agreement is approved by the user as part of the HBA flow. Terms and Conditions apply narrowly to specific
channel and/or content rating level of the channel as maintained by the MVPD.
MVPD conditions
 MVPD supports HBA for
household accounts
 Requires approval of Terms
and Conditions for HBA
access per channel content
level
Programmer content condition
 Specific channels are available
when user accepts Terms and
Conditions.
HBA Viewer Experience
 HBA enabled using
household account, upon
acceptance of Terms and
Conditions
Some channels might not
even trigger the Terms and
Conditionsbecause the
MVPD determines content
is general audience
3h. MVPD supports only a single household account and has restrictions, but allows for a PIN override for
the restriction.
Programmer should identify the desired heightened permission needed. When successful, MVPD returns an
additional identifier that is used by the Programmer to identify the user as having heightened permission
requirements. MVPD may also provide the duration of the heightened permission requirements.
20 August 2014 – Draft M - Open Authentication Technical Committee
20
Defining TVE Home-Based Authentication Use Cases and Approaches to Supporting Them
MVPD conditions
 MVPD supports HBA for
household accounts, with
restrictions
 MVPD has no subaccounts
 Requires Programmer to
pass restricted content
context in authentication
request
Programmer content condition
HBA Viewer Experience
 Supports household-level
 HBA enabled using
accounts
household account
 If content requires
 In restricted content
restrictions, blocks access at
context, potential PIN
the site or app or asset level
overide prompt in
Passes restriction context to
authentication flow, or PIN
MVPD in authentication
prompt upon asset
request, whether for first login
viewing, before HBA
attempt or SSO encounter
enabled
with restricted content
3i. MVPD supports subaccounts, has restrictions, and allows for an account picker with PIN override for the
restriction.
The flow would be the same 3h. Under this scenario, it is recommended that the PIN apply to the household,
although the PIN could be on a subaccount.
MVPD conditions
 MVPD supports HBA for
subaccounts, with
restrictions
 Requires Programmer to
pass restricted content
context in authentication
request
Programmer content condition
HBA Viewer Experience
 Supports subaccounts
 Account Picker rendered
 If content requires
 HBA enabled, after
restrictions, blocks access at
Account Selection
the site or app or asset level
In restricted content
 Passes restriction context to
context, after Account
MVPD in authentication
Selection, potential PIN
request, whether for first login
prompt in authentication
attempt or SSO encounter
flow, or PIN prompt upon
with restricted content
asset viewing, before
restricted content enabled
20 August 2014 – Draft M - Open Authentication Technical Committee
21
Defining TVE Home-Based Authentication Use Cases and Approaches to Supporting Them
Summary
The following are the recommended priorities for use cases groups.
1. The easiest scenario for HBA is when the MVPD doesn’t need to deal with restrictions and subaccounts.
Either subaccount or restriction features aren’t offered or users haven’t set them up. In these cases, MVPDs
and Programmers should be able to enable HBA using the household account without restriction.
2. The next easiest scenario involves MVPDs that rely on either simple channel blocking or programmer filtering
based on hints while tying HBA to the household account ID (without personalization). Most MVPDs and
Programmers are technically capable of doing this today.
This scenario requires that TVE integration support sharing the channel-ID during authentication, MVPDs to
handle channel blocking, and Passive AuthN for SSO. Optionally, MVPDs could support ratings restriction hints
where Programmers support scoped AuthN tokens/session, filtering content based on restriction hints, and
Passive AuthN flow.
3. A scenario similar to #2 is when the MVPD can rely on content rating based on AuthZ, but most MVPDs don’t
support that today.
4. The next in complexity is providing account pickers and/or Terms and Conditions screens. For opt-in, users
could pick a specific account or accept terms. MVPDs that can’t customize their SAML integrations may find
supporting these scenarios to be difficult. Terms and Conditions enabled by Programmers could be an option
here. To enable by that, MVPDs would need to consistently identify the user and send a flag for HBA flow.
Programmers may need to pass a flag indicating Terms and Conditions capabilities. In this way, Terms and
Conditions by Programmer is a relatively simple extension of #2 above.
5. The most complex scenario is providing restriction overrides, such as a PIN. Again, MVPDs that can’t
customize their SAML integrations will find supporting this scenario difficult. Programmer-managed PINs
could be explored when an MVPD passes both household and subaccount IDs.
20 August 2014 – Draft M - Open Authentication Technical Committee
22
Defining TVE Home-Based Authentication Use Cases and Approaches to Supporting Them
Appendix
AuthN Level of Assurance
In cases where HBA content access is restricted to content of a particular rating, an MVPD (or technology
partner) manages a site or app whitelist mapping to channel to an “authentication context”, which includes a
required “level of assurance”. The Programmer site or app must provide that level of assurance. The MVPD
would provide the level with the rating specified by the user account, the least common denominator for
households with multiple accounts, or a default if not specified by the user.
When a user wants to access content above the level of assurance, a mechanism is required that allows the
Programmer site or app to return the user to the MVPD where the user can assert their privilege to access the
content through a process such as credential-based authentication.
An example of a general mechanism for elevating privileges is suggested in section “3.4.2
InternetProtocolPassword” of the Authentication Context for OASIS SAML v2.0 document (http://docs.oasisopen.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf).
Stream Limiting and Fraud Management
Fraud and unauthorized use arise as topics within the scope of HBA when they are not already managed with
dedicated systems. As mentioned, stream limiting and fraud management systems, such as real-time usage
monitoring (RUM), generally exist independently from the authentications systems, and are the solutions to
these issues. When these systems are unavailable, there still are approaches to mitigating fraud and
unauthorized use by authentications granted through HBA. Two examples are:
1. Shorter authentication sessions, which limits the usefulness (and unfortunately the convenience) of the
HBA provided authentication out of the home
2. In-home proximity detection to prevent spoofing of IPs addresses
20 August 2014 – Draft M - Open Authentication Technical Committee
23
Defining TVE Home-Based Authentication Use Cases and Approaches to Supporting Them
Decision/Support Matrix
The table below identifies known MVPD capabilities and requirements, along with a list of possible solutions or
tools. It is referenced as an aid in constructing HBA current and future use cases and solutions.
Restrictions Restriction Enforcement
None
Restriction
Modification
MVPD authN Programmer block None
Programmer content filter on
MVPD Default MVPD authN hint
Re-authN
Household
AuthZ re-authN response
Programmer managed T&C
AuthZ challenge (e.g. PIN in
authZ response)
MVPD-managed T&C
MVPD-scoped authN
assertion/token
PIN
Subaccount
LCD
Subaccount
Individualization Resolution
Household
Default
Subaccount
Picker
Restriction-scoped authN
assertion/token
Note: T&C = Terms and Conditions
20 August 2014 – Draft M - Open Authentication Technical Committee
24