Platform Integration Requirements

Prev Next

This document details additional requirements for apps that utilize specific platform integrations.

Integrations must be discussed before adoption

These requirements only apply if your app uses corresponding integration(s). If you are interested in a particular integration, submit a ticket or contact your partner manager.

Search and Discovery integration

In order to have your app's content fully surfaced in aggregated experiences, Firebolt Search and Discovery APIs must be integrated.

Full Specifications enable your app's content to have a deeper and more prominent exposure in search and discovery experiences.

Deep Linking enables your app to be launched or brought to the foreground with a specific entity, search, player, or other section already loaded.

Voice Commands allow your users to speak to their remotes to navigate, search, and control their experience via voice.

Acceptance Criteria

As a user, I want to be able to launch the app using my voice so that I can access the app quickly.

Having pressed voice input on the remote
  • Given that the user has pressed the voice input on the remote,
  • When they say "app", "launch app", "Open app", "Start app" among others (as per other apps),
  • Then the app application shall launch.

Kids section

KS-01 Option 1a: Launching straight into a kids profile

Your app should open kid section deep links within kid profiles.

Acceptance Criteria

As a user, I want to ensure that the kids section is a safe place for my kids to browse without being able to access inappropriate content through third party apps.

Scenario prerequisites:

  • SOIP
  • The user is browsing the kids super section the app platform
  • The user launches an app either via a deep link to kids content or from the apps rail
  • Kids profiles should only include content rated 0 or 6
When a single kids profile has been created previously
  • Given I am launching an app via a deep link from the kids section and have previously created a kids profile in the app,
  • When the app launches,
  • Then I should be taken straight to the show page (from no resume point)/ playback (from a resume point) within a kids profile that I have already created.
When multiple kids profiles have been created previously
  • Given I am launching an app via a deep link from the kids section and have previously created multiple kids profiles in the app,
  • When the app launches,
  • Then I should be taken to the app profile screen to choose which profile I should watch from.
When no kids profiles have been created
  • Given I am launching an app via a deep link from the kids section,
  • When the app launches,
  • Then I should be taken straight to the show page (from no resume point)/ playback (from a resume point) within a default kids profile.

Example flows

Launching an app via a deep-link, into Kids profile with no profile set up:

kidflowA1.png

Launching an app via a deep-link, into Kids profile with multiple profiles:

kidflowA2.png

Launching an app via a direct app launch, into Kids profile with no profile set up:

kidflowA3.png

Launching an app via a direct app launch, into Kids profile with multiple profiles:

kidflowA4.png

KS-02 Option 1b: Changing profiles

Your app should present a form of parental control before accessing an adult profile.

Acceptance Criteria

As a user, I want to ensure that the kids section is a safe place for my kids to browse without being able to access inappropriate content through third party apps.

Scenario prerequisites:

  • SOIP
  • The user launches an app either via a deep link to Kids content or from the apps rail
  • The user tries to change profile from within the app
  • Kids profiles should only include content rated 0 or 6
Having launched app directly into Kids profile via platform Kids section
  • Given that I've launched the app directly into a kids profile via the app platform Kids section,
  • When I go to change profiles from within the app,
  • Then I should have a form of parental controls challenges (e.g., PIN challenge), before I can access an adult profile.

KS-03 Option 2a: Launching via profile screen

Your app should open Kids section deep links within Kids profiles.

Acceptance Criteria

As a user I want to ensure that the kids section is a safe place for my kids to browse without being able to access inappropriate content through third party apps.

Scenario prerequisites:

  • SOIP
  • The user is browsing the kids super section the platform
  • The user launches an app either via a deep link to kids content or from the apps rail
  • Kids profiles should only include content rated 0 or 6
Launching an app via deep link from Kids section when kids profiles have been created previously
  • Given I am launching an app via a deep link from the kids section and have previously created a kids profile in the app,
  • When the app launches,
  • Then I should be taken straight to the show page (from no resume point)/ playback (from a resume point) within a kids profile that I have already created.
Launching an app via deep link from Kids section when multiple kids profiles have been created previously
  • Given I am launching an app via a deep link from the kids section and have previously created multiple kids profiles in the app,
  • When the app launches,
  • Then I should be taken to the app profile screen to choose which profile I should watch from.
Launching an app via deep link from Kids section when no kids profiles have been created
  • Given I am launching an app via a deep link from the kids section,
  • When the app launches,
  • Then I should be taken straight to the show page (from no resume point)/ playback (from a resume point) within a default kids profile.

Example flows

Launching an app via a deep-link, profile screen before playback:

kidflowA5.png

Launching an app via a direct app launch, profile screen before playback:

kidflowA6.png

KS-04 Option 2b: Launching via profile screen while app is in Background Active mode

Your app should take the user to the app profile screen or return to the kids profile when selecting a deep link from a kids section while the app is in Background Active mode.

Acceptance Criteria

As a user I want to ensure that the kids section is a safe place for my kids to browse without being able to access inappropriate content through third party apps.

Scenario prerequisites:

  • SOIP
  • The user is browsing the kids super section of the app platform
  • The app is already in Background Active mode (see Firebolt® Lifecycle States Requirements) from previous browsing
  • The user launches an app either via a deep link to kids content or from the apps rail
Having left app in Background Active while browsing UI
  • Given I've left the app in Background Active mode as I browse the UI,
  • When I select a deep-link for the same app from the kids section,
  • Then I should either be taken to the app profile screen to choose which profile I should watch from OR I should be returned back to the Kids profile section.

Partner page (PP)

The partner page relies on the use of RSS feeds. For more information on integrating partner page RSS feeds visit the Partner Page RSS documentation.

PP-01 Partner Page – Featured Rail

Example: Featured Rail UI

Implementation prerequisites
  • You have provided the platform with a valid RSS feed
  • The app metadata for each content asset in the feed must have already been ingested.

You must dictate which content should be displayed in your app's 'featured rail' within the platform's Partner page UI.

Additional notes:

  • Content to be displayed in featured rail, is for the partner to dictate.
  • Should avoid duplication with most popular rail.
  • Currently, only individual content assets (shows) can appear in the rail.

Acceptance Criteria

As a user, I want to see an area dedicated to the content from a particular partner app.

Viewing Featured Rail from app platform UI
  • Given I am on the app platform UI,
  • When I go to a partner page,
  • Then content in the featured rail should appear and deep link into the app content.
Selecting content from Featured Rail
  • Given I am on the partner page,
  • When I click on a content tile in the Featured rail,
  • Then the app should launch to the correct content deep link.

PP-02 Partner Page – Most Popular Rail

Implementation prerequisites
  • You have provided the platform with a valid RSS feed
  • The app metadata for each content asset in the feed must have already been ingested.

You must dictate which content should be displayed in your app's 'most popular rail' within the platform's Partner page UI.

Additional notes:

  • Content to be displayed in most popular rail is for the partner to dictate.
  • Should avoid duplication with featured rail.
  • Currently, only individual content assets (shows) can appear in the rail.

Acceptance Criteria

As a user, I want to see an area dedicated to the content from a particular partner app.

Viewing Most Popular Rail from app platform UI
  • Given I am on the app platform UI,
  • When I go to a partner page,
  • Then content in the most popular rail should appear and deep link into the app content.
Selecting content from Most Popular Rail
  • Given I am on the partner page,
  • When I click on a content tile in the most popular rail,
  • Then the app should launch to the correct content deep link.

Advertising (AT)

AT-01 Fast forwarding / scrubbing within an advertising break (ad break)

Users should be able to fast-forward and scrub through ad breaks and resume playback as expected. The player should also support the same FFWD and/or Scrub Forward Requirements across content and ad breaks.

Additional notes:

  • The 'Ad Fast Forward Tier' is indicated via Firebolt Policy method within skipRestriction object.
  • "None" is the equivalent for fast-forward/scrubbing being allowed across content and ad breaks

Acceptance Criteria

Scenario prerequisites:

  • User is in content.
FFWD or scrub forward behavior through ad break
  • Given that a user has initiated FFWD and/or scrub forward in an ad break,
  • Then: the user should be taken through that ad break at an accelerated speed that matches up to the maximum FFWD and/or scrub forward speed supported by the player (minimum requirements listed below)
    • And the FFWD should persist, at the same speed, until the end of the ad-break or the user aborts FFWD,
    • And when FFWD through the ad-break completes, playback should resume in content with no black screens, the FFWD should not pause or be interrupted by buffering or other visible transitions/ inconsistencies.
Resuming playback after FFWD or scrub forward in ad break
  • Given that a user has initiated FFWD and/or scrub forward in an ad break,
  • When the user play/resumes while in the ad break,
  • Then playback of ad break should resume at 1x speed,
    • And playback should resume at an advanced position in the ad break that represents the progress the user made through FFWD,
    • And playback should NOT reset to the start of the ad-break,
    • And there should be no abrupt changes in the UI or visual indicators that could confuse the user when switching back to normal playback (e.g., no large jumps in playhead position or countdown timer).
Fast-forward start during ad break
  • Given I am watching an ad break,
  • When I fast-forward,
  • Then the ad-break must fast-forward within 0.5 seconds.
Fast-forward speeds during ad break
  • Given I am watching an ad break,
  • When I fast-forward,
  • Then the ad break must fast-forward at the following multiple speeds x2, x6, x12, x30. (mirroring previous trickplay requirements).
Scrubbing experience during ad break
  • Given I am watching an ad break,
  • When I move the audio track or video selector to a specific time,
  • Then the content must move to that point within 2 seconds.

AT-02 Rewinding / scrubbing within an ad break

Users should be able to rewind and scrub through ad breaks and resume playback as expected. The player should also support the same FFWD and/or Scrub Forward requirements across content and ad breaks.

Additional notes:

  • The 'Ad Fast Forward Tier' is indicated via Firebolt Policy method within skipRestriction object.
  • "None" is the equivalent for fast-forward/scrubbing being allowed across content and ad breaks.

Acceptance Criteria

Scenario prerequisites:

  • User is in content.
Having initiated FFWD or scrub forward in content
  • Given that a user has initiated FFWD and/or scrub forward in content,
  • When the player comes across an ad break,
  • Then the FFWD should persist, at the same speed, across content and the ad break and back into content, or until the user aborts FFWD,
    • And the FFWD should not pause or be interrupted by ad breaks,
    • And the FFWD should not pause or be interrupted by buffering or other visible transitions/inconsistencies.
Fast-forward start during content
  • Given I am watching content,
  • When I fast-forward,
  • Then content and ad break(s) must fast-forward within 0.5 seconds.
Fast-forward speeds during content
  • Given I am watching content,
  • When I fast-forward,
  • Then content and ad break(s) must fast-forward at the following multiple speeds: x2, x6, x12, x30 (mirroring previous trickplay requirements).
Scrubbing experience during content
  • Given I am watching content,
  • When I move the audio track or video selector to a specific time,
  • Then the content must move to that point within 2 seconds.

AT-03 Fast forwarding / scrubbing initiated in content and continues across mid-rolls

Users should be able to fast-forward and scrub through ad breaks and resume playback as expected across mid-rolls. The player should also support the same rewind KPIs across content and ad breaks:

Additional notes:

  • The 'Ad Fast Forward Tier' is indicated via Firebolt® Policy method within skipRestriction object.
  • "None" is the equivalent for fast-forward/scrubbing being allowed across content and ad breaks.

Prerequisite: User is in content.

Acceptance Criteria

Rewind or scrub back behavior through ad break
  • Given that a user has initiated rewind and/or scrub back in an ad break,
  • When the user performs these actions,
  • Then the user should be taken through that ad break at an accelerated speed that matches up to the maximum rewind speed and/or scrub back speed supported by the player,
    • And rewind should persist, at the same speed, until the end of the ad break or the user aborts rewind,
    • And when rewinding through the ad break has completed, playback in content should resume,
    • And rewind should not pause or be interrupted by buffering or other visible transitions/inconsistencies.
Resuming playback after rewind or scrub back in ad break
  • Given that a user has initiated rewind and/or scrub back in an ad break,
  • When the user aborts rewind or hits play while in the ad break,
  • Then playback of ad break should resume at 1x speed,
    • And playback should resume at an earlier position in the ad break that represents the progress the user made through rewinding,
    • And there should be no abrupt changes in the UI or visual indicators that could confuse the user when switching back to normal playback (e.g., no large jumps in playhead position or countdown timer).
Rewind start during ad break
  • Given I am watching an ad break,
  • When I rewind,
  • Then the ad break must rewind within 0.5 seconds.
Rewind speed during ad break
  • Given I am watching an ad break,
  • When I rewind,
  • Then the ad break must rewind at the following multiple speeds: x2, x6, x12, x30 (mirroring trickplay requirements).
Scrubbing experience during ad break
  • Given I am watching an ad break,
  • When I move the audio track or video selector to a specific time,
  • Then the content must move to that point within 2 seconds.

AT-04 Rewinding initiated in content and continues across mid-rolls

Users should be able to rewind and scrub through ad breaks and resume playback as expected across mid-rolls. The player should support the same rewind requirements across content and ad breaks.

Additional notes:

  • The 'Ad Fast Forward Tier' is indicated via Firebolt® policy method within skipRestriction object.
  • "None" is the equivalent for rewind/scrubbing being allowed across content and ad breaks.

Prerequisite: User is in content.

Acceptance Criteria

Having initiated rewind or scrub back in content
  • Given that a user has initiated rewind or scrub back in content,
  • When the player comes across an ad break,
  • Then Rewind should persist, at the same speed, across content and the ad break and back into content, or until the user aborts Rewind,
    • And Rewind should not pause or be interrupted by ad breaks,
    • And Rewind should not pause or be interrupted by buffering or other visible transitions/inconsistencies.

Rewind Experience

Rewind start
  • Given I am watching content,
  • When I rewind,
  • Then content and ad break(s) must rewind within 0.5 second.
Rewind speeds
  • Given I am watching content,
  • When I rewind,
  • Then content and ad break(s) must rewind at the following multiple speeds: x2, x6, x12, x30 (mirroring previous trickplay requirements).

Scrubbing Experience

  • Given I am watching content,
  • When I move the audio track or video selector to a specific time,
  • Then the content must move to that point within 2 seconds.

AT-05 Ad Trickplay UI / Visual Cues

Users should not be presented with black screens, error screens, or any visible transitions when resuming from fast-forward, rewind, or scrub state.

Acceptance Criteria

Visual cues during Trickplay in ad break
  • Given a user has initiated FFWD, rewind, and/or scrub in an ad-break,
  • When the user performs these actions,
  • Then black screens, error screens, or other visible transitions/inconsistencies should not be presented at any point during the FFWD, rewind, or scrub journey,
    • And Trickplay UI elements displayed should be consistent with the user interface for trickplay during content,
    • And Trickplay UI elements should display until the user aborts FFWD or rewind,
    • And the user should get a visual indication of progress in time via the Player UI elements, preferably with a countdown of time left in the ad-break and an updated timeline.
Visual cues when resuming playback after Trickplay in ad break
  • Given a user has initiated FFWD, rewind, and/or scrub in an ad-break,
  • When the user plays/resumes while in the ad-break,
  • Then play/resume should not display black screens, error screens, or other visible transitions/inconsistencies.
Having not attempted trickplay or playback control
  • Given that a user has not attempted trickplay or attempted to control playback in any way,
  • When normal viewing occurs,
  • Then the Ad Trickplay UI should not be invoked.

AT-06 Advert Quality

Advertisements should be in HD (high definition).

AT-07 Exiting playback session after ad break

User should be returned to playback at the same point they left without ad breaks when resuming.

Acceptance Criteria

Scenario prerequisites

  1. User has fully watched an ad break (pre, mid, or post roll) to 100% at 1x speed.
  2. User has started watching content in app.
User has fully watched an ad break and started watching content
  • Given the user has fully watched an ad break and started watching content in app,
  • When the user exits the playback session and then resumes playback (via Continue Watching or selecting the same episode),
  • Then the user must return to playback at the exact same point they left and no ad break is served on resume.

AT-08 Exiting playback session during ad break

Playback must resume from the start of the ad-break when users exit the playback session and then resume playback.

Acceptance Criteria

User in ad break
  • Given the user is in an ad break,
  • When the user exits the playback session and then resumes playback (via Continue Watching or selecting the same episode),
  • Then playback resumes from the start of the ad break again.

AT-09 Separate Premium Ad Skip experience supersedes Ad Tier entitlement

Users with entitlements to skip advertisements should have the ability to Trickplay ads.

Additional notes:

  • Pause, play, rewind, and scrub back actions must never be suppressed, irrespective of Ad Tier entitlement.

Acceptance Criteria

Scenario prerequisites:

  1. User is subscribed to the app platform over IP and thus has an "Ad Tier" or "Ad Fast Forward Tier"entitlement assigned by the app platform.
  2. User currently pays for a separate premium ad-skip or ad fast-forwarding experience with the app itself that is not part of an app platform entitlement.
User subscribed to "Ad Fast Forward Tier" - premium ad skip supersedes
  • Given that a user has initiated playback in app and the user is subscribed to the app platform 'Ad Fast Forward Tier',
  • When playback occurs,
  • Then the user should be able to Trickplay ads (FFWD, scrub ahead/back, rewind ads, pause/play) in the app.
User subscribed to "Ad Tier" with separate premium ad-skip - premium supersedes
  • Given that a user has initiated playback in app and the user is subscribed to the app platform 'Ad Tier' and the user currently pays for a separate premium ad-skip / ad fast-forwarding experience with the app itself,
  • When playback occurs,
  • Then the user should be able to Trickplay ads (FFWD, scrub ahead/back, rewind ads, pause/play) in the app.

AT-10 Ad Trickplay Experience must match a user's Ad Tier entitlement

The ability to Trickplay ads should reflect the user's Ad Tier entitlement.

Additional notes:

  • Pause, play, rewind, and scrub back actions must never be suppressed, irrespective of Ad Tier entitlement.

Acceptance Criteria

Scenario prerequisites:

  1. User is subscribed to the app platform over IP and thus has an 'Ad Tier' or 'Ad Fast Forward Tier' entitlement assigned by the app platform.
  2. User does not currently pay for a separate premium ad-skip / ad fast-forwarding experience with the app itself that is independent of an app platform entitlement.
User subscribed to "Ad Fast Forward Tier" - Trickplay allowed
  • Given that a user has initiated playback in app and the user is subscribed to the app platform 'Ad Fast Forward Tier',
  • When playback occurs,
  • Then the user should be able to Trickplay ads (FFWD, scrub ahead/back, rewind ads, pause/play) in the app.
User subscribed to "Ad Tier" - Trickplay restricted
  • Given that a user has initiated playback in app and the user is subscribed to the app platform 'Ad Tier',
  • When playback occurs during ad-breaks,
  • Then the fast-forward and scrub ahead Trickplay actions must be suppressed during ad-breaks (subject to "Relax Viewing" requirement below) and playback of the ad-break must continue at 1x speed.

AT-11 No Trickplay restrictions during content playback

Trickplay should not be restricted over primary content playback.

Additional notes:

  • Trickplay should only be restricted over ad break content.

Acceptance Criteria

Scenario prerequisites:

  1. User is subscribed to 'Ad Tier'.
  2. User is watching primary content.
User subscribed to "Ad Tier" and watching primary content
  • Given the user is subscribed to "Ad Tier" and is watching primary content,
  • When playback occurs over primary content,
  • Then Trickplay (FFWD / Rewind / high-speed scrub) should not be restricted over primary content playback.

AT-12 Ad Markers for Non-FFWD

Ad markers should display in the playback bar and appear in the exact point where the ad-break begins.

Additional notes:

  • Ad markers are spots/markings on the trickplay bar / seek bar that signal the presence of an ad-break where trickplay is disabled.

Acceptance Criteria

Scenario prerequisites:

  • User is subscribed to the 'Ad Tier' and has initiated playback in app.
User subscribed to "Ad Tier" and initiates playback
  • Given the user is subscribed to the "Ad Tier" and has initiated playback in app,
  • When playback reaches an ad-break,
  • Then ad markers should display in the seek bar / trickplay bar and appear at the precise point in playback (in trickplay bar) where the ad-break begins.

AT-13 "Relax View" for subsequent views of ad-breaks

Users should be able to use Trickplay on ads which have been previously viewed fully at 1x speed.

Acceptance Criteria

Scenario prerequisites:

  1. User is subscribed to the "Ad Tier" (i.e., tier where Trickplay is suppressed on ads).
  2. User has already viewed an ad-break in full.
User has fully watched an ad break
  • Given a user has fully watched an ad-break (Pre/Mid/Post roll) to 100% at 1x speed,
  • When the user returns to the same ad-break position (by rewinding / scrubbing back to that position),
  • Then Trickplay will not be restricted for this subsequent view so that the user will be able to FFWD / high-speed scrub during this ad-break on subsequent views.

AT-14 UI Notifications for Trickplay suppression

There should be a visible notification to indicate when Trickplay is not available and the user has attempted to use Trickplay.

Acceptance Criteria

Scenario prerequisites:

  1. User is subscribed to the 'Ad Tier' where Trickplay on ads is suppressed.
  2. User is watching an ad-break that he/she has not watched before (so Relax View is not in effect and the ad-break is not FFWD-able).
Subscribed to "Ad Tier" and watching non FFWD-able ad break
  • Given the user is subscribed to the "Ad Tier" and watching an ad break that is not FFWD-able,
  • When the user attempts to Trickplay (FFWD / high-speed scrub) out of this ad-break,
  • Then Trickplay (FFWD/high-speed scrub) should be suppressed and playback of the ad break must continue at 1x speed.

A visual notification should display to the user, informing the user that Trickplay is suppressed, that playback will resume after the ad break finishes, and how much time is left in the ad-break.

Notification should auto-dismiss so that it is not always on the screen.

AT-15 High Speed scrub (jump) past multiple mid-rolls

Users must be presented with only the nearest mid-roll ad-break position before resuming content from the jump/scrub point.

Acceptance Criteria

Scenario prerequisites:

  1. User has started watching content in app.
  2. The content has 2 or more mid-roll ad-breaks that the user has not yet viewed to 100%.
User tries to scrub or jump past two or more ad breaks
  • Given the user attempts to scrub past or jump past 2 or more mid-roll ad breaks,
  • When the user initiates this action,
  • Then the user must be pulled back to the mid-roll position nearest to his/her jump position before playback resumes from the scrub/jump position.

The user must watch this nearest mid-roll ad-break position before he/she can resume watching content from the jump/scrub point (i.e., the user must only watch one mid-roll ad-break nearest to their position rather than all mid-rolls that they jumped across).

AT-16 Unsubscribed Registered State

User should be able to Trickplay content and ads according to your app's advertising product requirements.

Acceptance Criteria

Scenario prerequisites:

  • User was previously subscribed to the app platform, but has now cancelled their subscription and is now in an "unsubscribed registered state".
User has initiated playback in app
  • Given that a user has initiated playback in app,
  • When the user is now in an "unsubscribed registered state",
  • Then the user should be able to Trickplay content and ads according to the app's own advertising product requirements.

Commerce Integration (MP)

MP-01 Referral to commerce integration CT

Non-subscribed users must be given a "Get via app platform" CTA to subscribe to the app from the sign-in / sign-up screen

Acceptance Criteria

As a user, I want to be able to start a purchase journey of an app I am not signed into from the app landing page.

Not having purchased app subscription and launching the app
  • Given I have not purchased an app subscription and I launch the app,
  • When I am not logged into the app,
  • Then while on the sign-in / sign-up screen, I must be given the option to select a "Get via app platform" CTA.

MP-02 Transition to commerce integration app for purchase

Users must be directed to the commerce integration app when they select the "Get via app platform" CTA.

Additional notes:

  • Specification for the app-to-app transition (including the specific link parameters) will be provided separately. The app will be responsible for sending the user to the specified link.
  • The app platform will be responsible for any content displayed within the commerce integration app.

Acceptance Criteria

As a user, I want to be redirected to the commerce integration app when I select the "Get via app platform" CTA.

  • Given I have launched the app and I am presented with an option to 'Get via app platform',
  • When I select the 'Get via app platform' option,
  • Then I must be redirected to the commerce integration app straight to a page with relevant information about the app subscription.

MP-03 Activation feedback

Your app must notify the app platform when a user has successfully purchased and activated a subscription to your app.

Additional notes:

  • Specification for how the activation notification should be passed to the app platform will be provided.

Acceptance Criteria

As a platform, I want to know if a user who has bought a subscription has successfully activated the subscription.

User bought subscription through commerce integration
  • Given a user has bought a subscription to an app through the commerce integration,
  • When the user activates that subscription with the app partner,
  • Then app platform should be notified of a successful activation.

Silent Sign-In (SI)

SI-01 On Product sign-in, apps without existing account credentials

When a user signs into an app on one device, it should allow the user to auto-sign into all other devices in their household.

Additional notes:

  • The partner should show a notification in app to confirm the user has been signed in.

Acceptance Criteria

As an app user, I want to sign into third-party apps across all my connected app platform devices, so that I don't have to repeat the time consuming process of signing-in on each device.

Scenario prerequisites

  1. The user is trying to sign into an app on any device
  2. The app the user is accessing supports silent sign-in
  3. The user has multiple devices connected to the same account
Signing in on product to third-party app supporting silent sign-in
  • Given I am signing in on product to "Account X" to third-party app that supports silent sign-in,
  • When I've signed into the app,
  • Then I should be eligible to auto sign in on other devices in my household.
Signing in on product to third-party app supporting silent sign-in on another household device
  • Given I've signed in to a silent sign-in supporting app on another device on my household,
  • When I open the app on another device, that is not currently signed in,
  • Then it should be signed in using the same account(s) as the device where I initiated silent sign-in,

SI-02 On Product sign-in, apps with existing account credentials

When a user signs into an app on one device, it should not overwrite existing credentials on other devices in their household.

Acceptance Criteria

As an app user, I don't want silent sign-in to overwrite existing account credentials that are being used on additional devices.

Scenario prerequisites:

  1. The user is trying to sign into an app on any device.
  2. The app the user is accessing supports silent sign in.
  3. The user has multiple devices connected to the same account.
  4. The user has already signed into an app on one of their devices.
Silent sign-in does not overwrite different account on other device
  • Given I am signing in on product to "Account X" to a third-party app that supports silent sign-in,
  • When I open the app on another device that is signed in to a different account,
  • Then the app will remain signed in with the local credentials and will not be signed in to the new account.
Silent sign-in does not overwrite same account on other device
  • Given I am signing in on product to "Account X" to a third-party app that supports silent sign in,
  • When I open the app on another device that is signed in to the same account,
  • Then the app will remain signed in with the local credentials.

SI-03 Silent sign-in following signing out from previous credentials on additional devices

Users should be able to use silent sign-in after signing out on other devices.

Additional notes:

  • The partner should show a notification in app to confirm the user has been signed in.
  • If the app was previously signed in with the same account as the silent sign in credentials then when they relaunch the app it will be signed in again with the same account but using the authentication token from silent sign-in.

Acceptance Criteria

As an app user, I want silent sign in to auto sign me into an app with my silent sign in credentials if I sign out of any existing accounts on other devices.

Scenario prerequisites

  1. The user is trying to sign into an app on any device.
  2. The app the user is accessing supports silent sign-in.
  3. The user has multiple devices connected to the same account.
  4. The user has opted in to silent sign in on a device but at the time was signed in to the app with another account on another device.
  5. The user is signing out of the alternative credentials either on platform or through the partner's website.
Having signed out of existing account on secondary device
  • Given that I've signed out of my existing account on a secondary device,
  • When I next launch the app,
  • Then it should be signed in using the same account as the device where I initiated silent sign-in.

SI-04 Sign in to third-party apps through commerce integration

Users using commerce integration should have their credentials available for auto sign in after creating an account. You must present a clear message to indicate all devices will be auto signed in using the provided account information.

Additional notes:

  • The partner should show a notification in app to confirm the user has been signed in
  • A similar approach will be required to support an off platform pre-authentication journey in the future.

Acceptance Criteria

As a user buying through app platform commerce integration, I want my account credentials provided at account creation to auto sign me into the app across all my devices.

Scenario prerequisites:

  1. The app the user is accessing supports silent sign-in
  2. The user has purchased the app through commerce integration
  3. The user has gone through the account creation process on the partner's website
Having purchased app through commerce integration
  • Given I have purchased an app through the commerce integration,
  • Then there should be clear messaging to indicate that all devices will be auto signed in using my new account credentials before I leave the journey to create my partner account.
Having created account through commerce integration supporting silent sign-in
  • Given that I have created account credentials through the commerce integration journey with an app that supports silent sign-in,
  • When I have completed account creation,
  • Then those credentials should be available to auto sign into my app platform devices.
Created account through commerce integration
  • Given I have created an account through commerce integration,
  • When I launch that app on an app platform device,
  • Then I should be automatically signed into the commerce integration account ("Account X").

SI-05 Sharing device friendly names with partner sign-out journey (optional behavior)

Users should be presented with device friendly names when signing out of a device through your app's website.

Additional notes:

  • Not all partners will allow log out from their website. This requirement is only for apps that do and the app platform will need to support this journey.

Acceptance Criteria

As a user when I choose to log out of a device from a partner's website I want the device friendly names that I've chosen for devices to appear in the list of active devices.

Scenario prerequisites:

  1. The app the user is accessing supports silent sign-in.
  2. The user has selected device friendly names for their devices.
  3. The user is on the partner's website attempting to log out.
  4. The partner's website supports logging out of individual devices.
Having set up device friendly names
  • Given I have set up device friendly names for my panel or puck,
  • When I attempt to log out from a third-party website,
  • Then the device friendly name for my devices should appear in the list—only the devices where a user is logged into the partner app should be available.

SI-06 Sign out of 3rd party apps on devices within the product

Users who sign out of a 3rd party app on one device should only be signed out of the app on that device. Other devices should not be affected.

Additional notes:

  • The app platform will retain the subscription token and therefore will retain sign-in details for users.

Acceptance Criteria

As an app user, when I sign out of an app I want the sign out to only impact the local device

Scenario prerequisites

  1. The app the user is accessing supports silent sign in.
  2. The user has multiple devices connected to the same account.
  3. The user has used silent sign in to authenticate on this device.
  4. The user is signing out of the alternative credentials either on platform or through the partner's website.
Sign out affects only local device
  • Given I have signed-in with "Account X" to a third-party app,
  • When I sign out of the app,
  • Then I should only be signed out of the device I am on. Other devices should not be affected.
Relaunching app after sign out shows sign-in screen
  • Given I have signed out with "Account X" on a third-party app,
  • When I relaunch the app,
  • Then I should be presented with a sign-in screen.

SI-07 Sign out of third-party apps across all devices - With subscription token (commerce integration)

Users who sign out of a third-party app on one device should only be signed out of the app on that device. Other devices should not be affected and the app platform will retain the subscription token.

Additional notes:

  • The app platform will retain the subscription token and therefore will retain sign-in details for users.
  • Not all partners will allow log out from their website. This requirement is only for apps that do and the app platform will need to support this journey.

Acceptance Criteria

As an app user that has purchased a subscription through commerce integration, when I sign out of an app I want the sign-out to only impact the local device.

Scenario prerequisites:

  1. The app the user is accessing supports silent sign-in.
  2. The user has multiple devices connected to the same account.
  3. The user has used silent sign in to authenticate on this device.
  4. The user is signing out of the alternative credentials either on platform or through the partner's website.
  5. The user has purchased the app subscription through commerce integration.
Sign out with commerce integration affects only local device
  • Given I have signed-in with "Account X" to a third-party app,
  • When I sign out of the app,
  • Then I should only be signed out of the device I am on. Other devices should not be affected.
Relaunching app after sign out with commerce integration
  • Given I have signed out with "Account X" on a third-party app,
  • When I relaunch the app,
  • Then I should be presented with a sign-in screen offering two options:
    1. Sign in with retained subscription details, as subscription token has been retained.
    2. An alternative method to sign in using different details (QR code, keyboard sign-in, pin pairing, etc.).

SI-08 Sign out of third-party apps on all devices off product (optional behavior)

Users who use your app's website to "sign out of all devices" should be signed out of all devices that they are logged into and the authentication token should be cancelled.

Acceptance Criteria

As an app user, when I go to the partner website of an app I want to be able to sign out of all my devices (including all devices).

Scenario prerequisites:

  1. The app the user is accessing supports silent sign in
  2. The user has multiple devices connected to the same account
  3. The user has opted in to silent sign in previously and those credentials are used on this device
  4. The user is signing out of the account through the partner's website
Signed into third-party app
  • Given I have signed in with "Account X" to a third-party app,
  • When I click 'sign out of all devices' on the partner website,
  • Then I should be signed out of all my devices I am logged in on,
    • And the authentication token should be cancelled and no longer eligible for auto sign in.

SI-09 Sign out of third-party apps on individual devices (optional behavior)

Users who use your app's website to sign out of "friendly device name" should only be signed out on the device that they selected to log out of.

Additional notes:

  • Not all partners will allow log out from their website. This requirement is only for apps that do and the app Platform will need to support this journey.

Acceptance Criteria

As an app user, when I go to the partner website of an app I want to be able to sign out of each individual device (including all individual devices).

Scenario prerequisites:

  1. The app the user is accessing supports silent sign in
  2. The user has multiple devices connected to the same account
  3. The user has opted in to silent sign in previously and those credentials are used on this device
  4. The user is signing out of the account through the partner's website
User signed into a third-party app
  • Given I have signed in with "Account X" to a third-party app,
  • When I sign out of a particular device on the partner website,
  • Then I should only be signed out of the device I have selected. Other devices should not be affected but then authentication token should be cancelled.

Entitlement (EN)

EN-01 Signed-In / Authentication Status

Your app should inform the platform when a user has successfully signed in and signed out.

Acceptance Criteria

Scenario prerequisites:

  • The app requires a user to sign in to access and play back content.
Notify platform on user sign-in
  • Given a user has signed in to the app,
  • Then the app should inform the platform with a successful sign-in response, login token and specified endTime.
Update platform on app launch while signed in
  • Given a user is signed in to the app,
  • When the user launches the app,
  • Then the app should update the sign-in response, login token and specified endTime.
User is signed out of the app
  • Given a user has signed out of the app,
  • Then the app should inform the app platform of a sign-out response.

EN-02 Entitlement Status

Your app should inform the app platform when a user has modified their subscription for your app.

Acceptance Criteria

Scenario prerequisites:

  • The app requires an account/subscription in order to access & playback content.
User has purchased, changed, upgraded, or downgraded a subscription
  • Given a user has purchased, changed, upgraded, or downgraded a subscription for the app,
  • Then the app should update the platform with a new Discovery.contentAccess(entitlements) API call.
User has launched the app
  • Given a user has launched the app,
  • Then the app should refresh and update the platform with any new changes.
User has canceled their subscription for the app
  • Given a user has canceled their subscription for the app,
  • Then the app should update the platform with a new Discovery.contentAccess(entitlements) API call, and when the specified endTime has lapsed,
  • Then the app should clear and remove all entitlements for the user with a Discovery.clearContentAccess API call.

Thumbnail Trickplay recommendations (TH)

TH-01 Enabling Thumbnail Trickplay

  • Users should be able to trigger thumbnail Trickplay from the D-Pad on the remote without navigating to any in-app button on the progress bar.
  • Users should be able to start fast-forwarding or rewinding with a single click on the D-Pad, with each click increasing the FFWD / RWND speed.
  • Users should be able to stop thumbnail Trickplay and resume or pause playback by either pressing the Select button the D-Pad or using the Play/Pause button on the remote.

TH-02 Thumbnail Trickplay Speeds

  • Users should be able to fast-forward or rewind content at three incremental speeds.

TH-03 Thumbnail Trickplay UI

  • The progress bar should remain at the point where Trickplay was initiated and should remain visible during Trickplay.
  • A minimum of 3 thumbnails should display when the user is fast-forwarding, rewinding, or scrubbing.