MVPD Integration Features
NOTE
The content on this page is provided for information purposes only. Usage of this API requires a current license from Adobe. No unauthorized use is permitted.
Overview mvpd-int-features-overview
Adobe Pass Authentication supports the emerging standards for TV Everywhere. It is compliant with the CableLabs OLCA (Online Content Access) specification, which provides technical requirements and architecture for the delivery of video to a Pay TV customer from online sources. Adobe participated in the joint CableLabs interopt testing project in June 2011 and passed the testing process for a Service Provider implementation. Adobe is also an active member of the OATC (Open Authentication Technical Consortium) and participates in several of the subcommittees’ specification-drafting projects as part of that body.
Having described Adobe Pass Authentication OLCA compliance, and Adobe’s participation in OATC, it is also important to note that Adobe Pass Authentication is actually “protocol agnostic”. But at this stage of the TVE era, Adobe Pass Authentication is definitely oriented toward the OLCA standards. The standards delineate currently agreed-upon ways for the different TVE players (Programmers, MVPDs, and Service Providers) to implement TVE features. Many of these features are listed in the tables below, with links to related pages that provide details and examples of how to implement the features.
The information in the tables is intended to drive the Adobe Pass Authentication integration process towards consistent functionality across all MVPD integrations. The priority column ranks the features into A, B, and C:
- A - These are “must have” features for the initial roll-out of an integration.
- B - These are important enhancements to the initial integration, to be added after the initial roll-out.
- C - These are further enhancements to the integration that can be implemented after the ‘B’ requirements.
1. Core Functional Features core-func-features
No.
Feature
Description
Priority
Notes
1.1
The viewer selects the MVPD and initiates the authentication (AuthN) flow from the Programmer brand’s website or application.
A+
1.2
Once authenticated, authorization (AuthZ) can occur in the background, with the passing of only a network channel identifier, and a user identifier, to the MVPD.
A+
1.3
UserID Persistence
The MVPD provides an obfuscated, persistent UserID.
A
1.4
The viewer logs in with the MVPD on the site of one brand and can then go to another brand and not be prompted to log in again. The AuthN session is shared between the brands. SSO support is for both websites and mobile / device applications. For MVPDs, it requires returning either a User ID or some other user token that can be used for AuthZ across brands.
A
1.5
Device-optimized Login User Experience (UX)
The MVPD supports resizing the login screen so that it fits the dimensions of the device the view is using.
A
1.6
Default MVPD Picker Logo
The MVPD provides a URL to a default logo of appropriate dimensions (112x33 pixels).
A
The logo should be hosted by the MVPD and should be cached by CDN.
1.7
MVPD supports passing the brand identifier (Requestor value) in the AuthN request.
A-
This enables a Service Provider-specific login experience.
1.8
The MVPD supports a Programmer sending multiple channels in a single authorization request.
B+
1.9
iFrame or “JS Pop-up” based Authentication
The Programmer is able to integrate the login flow into an iFrame or pop-up experience instead of an HTTP redirect.
B
1.10
The viewer has an authenticated session both on the Programmer’s Site or App and with the MVPD. The viewer can initiate a federated logout from the Programmer’s site, and the logout also clears the session on the MVPD portal.
B
Ensures shared computers are more protected from misuse from the Programmer perspective.
1.11
The MVPD passes its own custom error string, which is appropriate for the Programmer’s federated Site or App to display to the user.
B
Enables up-sell scenarios
1.12
User Metadata on Authentication Response
The MVPD AuthN response can include user metadata that acts as a hint for personalization of the user’s experience during the entitlement flow. This requirement enables parental control hints from the MVPD to the Programmer.
B-
1.13
MVPD-initiated Authentication
The viewer completes a successful AuthN session on the MVPD portal, and then navigates to the Programmer’s TVE site. The user is not prompted for the MVPD picker and is automatically authenticated.
B-
1.14
UserID Scoping
The MVPD UserID should occur in two forms - one scoped to Programmers and the other scoped Adobe-wide for fraud. This allows Adobe to share the Programmer-scoped MVPD UserID without further encryption / obfuscation.
C
1.15
Asset-based Authorization
Once AuthN is completed, AuthZ can happen in the background, by passing structured data that can include network, show, asset, parental control rating, and more as needed. This enables parental controls on every AuthZ call from the Programmer to the MVPD.
C
1.16
MVPD-initiated Logout
The viewer has an authenticated session both on the Programmer’s site or app and with the MVPD. The viewer can initiate a federated logout from the MVPD’s site that also clears the session on all federated Programmer sites.
C
1.17
Authorization Obligations
The MVPD provides additional conditions in the AuthZ response, such as logging, or a refreshed maximum parental control rating (OLCA).
C
1.18
IP Address Context
The MVPD requires explicitly passing the IP address. For AuthZ, where the calls are server-side, this gives the MVPD fraud tracking information about where the user is coming from on the AuthZ call.
C
1.19
Token Persistence Time-to-live (TTL) Value Dynamically Defined
The MVPD is able to set the TTL of the Adobe Pass Authentication token dynamically through properties in the response, so that Adobe is out of the loop for TTL changes.
C-
1.20
Device Type
The MVPD supports passing the device type in the AuthN or AuthZ request. This property informs the MVPD as to the nature of the device where the content will be consumed, so they could adjust the TTL of the AuthN or AuthZ token to conform to their own security considerations for the device.
C-
This is helpful for the clientless platform, where it may be hard to expose every device type as a config setting on the Adobe Pass Authentication side.
2. Operational Features operational-features
No
Feature
Description
Priority
Notes
2.1
24/7 Up-time
An MVPD agreement to strive for 24/7 up time and measure against that over time.
A
2.2
Test Credentials For Each Programmer
The MVPD provides separate testing accounts for each Programmer.
A
2.3
Certificate Expiration and Renewal Schedule Plan
An MVPD-documented plan with a schedule for ensuring SAML certificates are up to date.
A-
2.4
Average Latency Under 250 Ms / Response
An MVPD agreement to strive for low latency, and to measure against that over time.
A-
2.5
Hosting Own MVPD Picker Logo
The MVPD needs to host their own logo and it should be protected by CDN caching.
B
2.6
Support Escalation Plan
An MVPD-documented plan for escalation that is kept up to date and reviewed at least quarterly.
A
2.7
Outage Protection Plan
An MVPD co-plan with Adobe on degradation measures that can be used generally as needed.
B
2.8
Maintain Separate Staging and Production Endpoints
An MVPD integration test that doesn’t require hostfile spoofing to test the staging integration.
B
2.9
Additional QA Endpoint
The MVPD maintains an additional QA IdP integration for joint new feature development. Supporting this would make it less likely that we need UAT special requests for app store cert testing.
C
3. Authentication Experience Features authn-exp-features
No
Feature
Description
Priority
Notes
3.1
Authentication Conversion Over Minimum Expectation
The MVPD ensures minimum conversion rate to prove functional (5%), and reasonable (30%).
A
3.2
Inline Password Recovery
The MVPD provides a means to recover passwords inline to the federated AuthN flow.
A
3.3
Inline Account Registration
The MVPD provides a means to create a new account inline to federated AuthN flow.
A
3.4
Inline Help / Support
The MVPD provides a means to provide help during the federated AuthN flow.
A
3.5
Modem-based In-home Authentication
The MVPD automatically authenticates a device when it is on the local network of a registered model (ISP MVPD only).
B
This is lower priority because it’s an optimization that many can’t yet support and introduces some challenges for fraud mitigation and parental controls
You can now import Markdown table code directly using File/Paste table data… dialog.
4. Analytics Features analytics-features
No
Feature
Description
Priority
4.1
Authentication Conversion Funnel Alignment
The MVPD has a metric for AuthN requests that starts with the SAML AuthN request - to align with the Adobe Pass Authentication and Programmer AuthN request metrics.
A
4.2
Unique Users
Users that have been successfully authenticated, and de-duplicated in a monthly roll-up across days.
A
4.3
Time Zone Accounting
Reports include timezone for when the day turns over.
A
5. Fraud Mitigation Features fraud-mitgn-features
No
Feature
Description
Priority
Notes
5.1
Video Subscriber Validation on Authentication
The MVPD ensures that the user is a valid video subscriber during the AuthN flow.
A
5.2
Rate Limiting for Authentication / Authorization
The MVPD supports throttling on their web services to limit usage from a specific user account when appropriate.
B
5.3
Persistent UserID With Global Scope to Adobe
The MVPD ensures that Adobe has a UserID that can be tracked across Programmers for fraud. This doesn’t need to be provided to the customer directly.
B
Online Multimedia Authorization Protocol (OMAP) Specification and Real User Monitoring (RUM).
5.4
Concurrent Usage Validation
The MVPD has a means to track and limit the concurrent usage of the subscriber account beyond a business threshold.
B
P1. Proxy-Specific Functional Features proxy-sp-func-features
No
Description
Priority
Notes
P 1.1
Proxy responsible for maintaining accuracy of up to date list of subMVPDs
A
P 1.2
Proxy delivers appropriate sized logo for each subMVPD
A
Some live subMVPDs don’t have the right logo size
P 1.3
Proxy delivers appropriately branded log-in page for each subMVPD
A
P 1.4
Proxy responsible to target specific service provider brands with subMVPD list
B
P 1.5
Proxy specifies all subMVPD properties correctly (iFrame size, TTL, logo, etc)
A
P 1.6
Proxy specifies separate entityID
B
P2. Proxy Operational Features proxy-op-features
No
Description
Priority
P 2.1
API Key is secured
A
P 2.2
Test credentials for the first subMVPD used in live integration for each new requestor
A
P 2.3
subMVPD lists are accurate and complete per requestor
A
recommendation-more-help
3f5e655c-af63-48cc-9769-2b6803cc5f4b