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
© Copyright 2024 ExpyDoc
