ETSI TS 103 407 V1.1.1 (2016-04)

ETSI TS 103 407 V1.1.1 (2016-04)
TECHNICAL SPECIFICATION
Cross Platform Authentication for limited input hybrid
consumer equipment
---------------------- Page: 1 ----------------------
2 ETSI TS 103 407 V1.1.1 (2016-04)
Reference
DTS/JTC-033
Keywords
authentication, authorization, protocol
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search

The present document may be made available in electronic versions and/or in print. The content of any electronic and/or

print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any

existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the

print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.

Users of the present document should be aware that the document may be subject to revision or change of status.

Information on the current status of this and other ETSI documents is available at

If you find errors in the present document, please send your comment to one of the following services:

No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying

The content of the PDF version shall not be modified without the written authorization of ETSI.

DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.

3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and

GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.

Intellectual Property Rights ................................................................................................................................ 5

Foreword ............................................................................................................................................................. 5

Modal verbs terminology .................................................................................................................................... 5

Executive summary ............................................................................................................................................ 6

Introduction ........................................................................................................................................................ 6

1 Scope ........................................................................................................................................................ 7

1.1 General ............................................................................................................................................................... 7

2 References ................................................................................................................................................ 7

2.1 Normative references ......................................................................................................................................... 7

2.2 Informative references ........................................................................................................................................ 7

3 Definitions and abbreviations ................................................................................................................... 8

3.1 Definitions .......................................................................................................................................................... 8

3.2 Abbreviations ..................................................................................................................................................... 8

4 Protocol overview .................................................................................................................................... 9

4.1 Introduction ........................................................................................................................................................ 9

4.2 Modes of association ........................................................................................................................................ 10

4.2.1 Overview .................................................................................................................................................... 10

4.2.2 Authenticated association ('user mode') ...................................................................................................... 10

4.2.3 Unauthenticated association ('client mode') ................................................................................................ 10

5 Core concepts ......................................................................................................................................... 10

5.1 Bearer token ..................................................................................................................................................... 10

5.2 Domain ............................................................................................................................................................. 11

6 Roles ....................................................................................................................................................... 11

6.1 Client ................................................................................................................................................................ 11

6.2 Service provider ............................................................................................................................................... 11

6.3 Authorization provider ..................................................................................................................................... 11

7 The device flow ...................................................................................................................................... 12

7.1 Protocol version ................................................................................................................................................ 12

7.2 Basic principles ................................................................................................................................................ 12

7.2.1 HTTPS ........................................................................................................................................................ 12

7.2.2 JSON ........................................................................................................................................................... 12

7.2.3 Integrating applications with the CPA protocol .......................................................................................... 12

7.2.4 Example of authenticated association using the CPA device flow ............................................................. 12

7.3 User mode ........................................................................................................................................................ 13

7.4 Client mode ...................................................................................................................................................... 14

7.5 Automatic provisioning of tokens .................................................................................................................... 16

7.5.1 Overview .................................................................................................................................................... 16

7.5.2 User signs in and enters a pairing code ....................................................................................................... 16

7.5.3 User signs in and gives confirmation .......................................................................................................... 17

7.5.4 Token is automatically granted ................................................................................................................... 19

7.5.5 Refreshing an expired access token ............................................................................................................ 20

7.6 Deleting the association between a client and an authorization provider ......................................................... 21

7.6.1 Overview .................................................................................................................................................... 21

7.6.2 Deleting the association on the client side .................................................................................................. 21

7.6.3 Deleting the association on the authorization provider side ....................................................................... 22

8. Client/Authorization Provider API ......................................................................................................... 22

8.1 Overview .......................................................................................................................................................... 22

8.2 /register - Register a client ................................................................................................................................ 23

8.2.1 /register request ........................................................................................................................................... 23

8.2.2 /register response ........................................................................................................................................ 23

8.3 /associate - Associate a client with a user account ........................................................................................... 24

8.3.1 /associate request ........................................................................................................................................ 24

8.3.2 /associate response ...................................................................................................................................... 24

8.3.2.1 Pairing the client with a user account .................................................................................................... 24

8.3.2.2 Confirmation required before granting access to a new service ............................................................ 25

8.3.2.3 Access automatically granted to a new service ..................................................................................... 26

8.4 /token - Obtain a bearer token .......................................................................................................................... 27

8.4.1 /token request .............................................................................................................................................. 27

8.4.1.1 Client mode ........................................................................................................................................... 27

8.4.1.2 User mode ............................................................................................................................................. 27

8.4.1.3 Refreshing an expired access token ...................................................................................................... 28

8.4.2 /token response ........................................................................................................................................... 28

8.5 Verification endpoint ........................................................................................................................................ 30

8.5.1 Verification endpoint request ...................................................................................................................... 30

8.5.2 User permission request .............................................................................................................................. 30

8.5.3 Redirection response ................................................................................................................................... 30

9 Service Provider/Authorization Provider API ........................................................................................ 31

9.1 Overview .......................................................................................................................................................... 31

9.2 Establishing trust between the service provider and authorization provider .................................................... 31

9.3 /authorized - Access token verification endpoint ............................................................................................. 31

9.3.1 /authorized request ...................................................................................................................................... 31

9.3.2 /authorized response ................................................................................................................................... 31

Annex A (informative): How to integrate applications with the CPA protocol ........................................ 33

A.1 Introduction ............................................................................................................................................ 33

A.2 Authentication challenge ........................................................................................................................ 33

A.3 Accessing a protected resource .............................................................................................................. 34

Annex B (informative): Bibliography ........................................................................................................... 35

B.1 Reference implementation ...................................................................................................................... 35

B.2 Related documents ................................................................................................................................. 35

Annex C (informative): Change History ...................................................................................................... 36

History .............................................................................................................................................................. 37

IPRs essential or potentially essential to the present document may have been declared to ETSI. The information

pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found

in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in

respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee

can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web

This Technical Specification (TS) has been produced by Joint Technical Committee (JTC) Broadcast of the European

Broadcasting Union (EBU), Comité Européen de Normalisation ELECtrotechnique (CENELEC) and the European

NOTE: The EBU/ETSI JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the

specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body

by including in the Memorandum of Understanding also CENELEC, which is responsible for the

standardization of radio and television receivers. The EBU is a professional association of broadcasting

organizations whose work includes the co-ordination of its members' activities in the technical, legal,

programme-making and programme-exchange domains. The EBU has active members in about 60

In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and

"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of

"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.

The Cross Platform Authentication (CPA) protocol defines how to securely associate an IP-connected media device

(such as a hybrid radio, set top box or Smart TV) with the online account of a user of a set of web services delivered to

The present document specifies version 1.0 of the Cross Platform Authentication (CPA) protocol.

The CPA protocol is specifically designed for devices with limited input and display capabilities that are not addressed

by existing standards and to cater for companies that share a back-end authorization provider for managing identities

The CPA protocol defines a clear separation of responsibilities between the service provider and the authorization

provider. This enables the protocol to be applied in a variety of business configurations typical of the broadcast

• the service provider and the authorization provider are both managed by the same company;

• an umbrella company manages the authorization provider (so centralizing identity management) but keeps its

• service providers from different companies use the same central authorization provider managed by a separate

The protocol described in the present document is intended for devices with limited input capabilities, such as hybrid

radios, IP-connected set top boxes and Smart TVs, that can communicate with web services over HTTPS.

• the API between a client device and an authorization provider by which a client obtains a bearer token;

• the API between a service provider and an authorization provider by which a service provider verifies an

The present document gives an overview of the protocol (clause 4), covering the core concepts (clause 5) and roles

The CPA APIs are specified in the present document in clauses 8, Client/Authorization Provider API and clause 9,

An informative annex A describes how service providers can tell clients that the option to authenticate using the CPA

protocol is available, and how the bearer token obtained via CPA should be used to access protected resources.

Although this clause is not normative, it is strongly recommended these conventions are followed where possible to

References are either specific (identified by date of publication and/or edition number or version number) or

non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the

Referenced documents which are not found to be publicly available in the expected location might be found at

NOTE While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee

The following referenced documents are necessary for the application of the present document:

[2] IETF RFC 7159: "The JavaScript Object Notation (JSON) Data Interchange Format".

References are either specific (identified by date of publication and/or edition number or version number) or

non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the

NOTE While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee

The following referenced documents are not necessary for the application of the present document but they assist the

[i.2] IETF RFC 6750: "The OAuth 2.0 Authorization Framework: Bearer Token Usage".

For the purposes of the present document, the following terms and definitions apply:

access token: bearer token used by a client as authority to access a service provider

authenticated association: association in which the client identity is associated with a user identity

authorization provider: service that manages client identities and the association between client identities and

bearer token: security token the possession of which entitles the bearer to all rights associated with it

client: application managed entity uniquely identified by an authorization provider

client mode: authorization mode where the client relation is not associated with a user account

device flow: series of exchanges between the client and the authorization provider by which the client obtains a bearer

identity provider: service that manages identity information on behalf of users and services

limited display device: device with the ability to display at least two rows of sixteen alphanumeric characters from the

limited input device: device that has at least the ability to accept or cancel a proposed action

registration: process by which a client obtains a client identity from an authorization provider

service provider: service requiring authorization to access its protected resources

token: unique opaque string used to represent a specific granting of authorization to use a service

unauthenticated association: association in which the client identity is not associated with a user identity

user mode: authorization mode where the client relation is associated with a user account

The present document defines the protocol between a client device and an authorization provider by which a client

device acquires an authorization token it may use to access protected resources and by which the service provider can

Cross Platform Association (CPA) is based on OAuth 2.0 IETF RFC 6749 [i.1] and the bearer tokens used in CPA are

compatible with OAuth 2.0 bearer tokens IETF RFC 6750 [i.2]. While CPA can be used more generally, the focus of

the present document is on IP-connected media devices with limited input and display. When such a device cannot run a

fully capable HTTP User Agent such as a browser, the user needs access to another device which can run such software

In the typical CPA device flow described below, the application-specific steps are prefixed with (App) and the

• (App): An application on the device requests a protected resource from the service provider.

• (App): The service provider checks with the authorization provider to see if the device is authorized.

• (App): The service provider response to the device includes the endpoint where the device may initiate the

• (CPA): The device registers itself with the authorization provider and receives a client_id and

• (CPA): The device makes a request to the authorization provider to associate the device.

• (CPA): The authorization provider returns a verification URI and one-time user_code which the device

displays to the user. It also returns a corresponding device_code which is not displayed.

• (CPA): The device polls the authorization provider using the device_code as identification.

• (App): In the meantime, the user uses a browser on another computer to open the supplied verification URI to

enter the code. As part of this process, the user will be required to authenticate their user identity, typically by

• (CPA): Once the user has verified the association by entering their code, the authorization provider responds to

• (App): The application running on the device can then reissue the request for the protected resource, this time

In the device flow outlined above, CPA specifies the protocols between a) the client device and the authorization

The client/authorization provider API (see clause 8) consists of the following endpoints supplied by the authorization

• /register to obtain a client identity consisting of a client_id and client_secret;

• the verification endpoint to authenticate the user's identity and verify the association.

The service provider/authorization provider API (see clause 9) consists of one endpoint supplied by the authorization

All other interactions between the participants in the CPA protocol are outside the scope of the present document.

However, the present document includes illustrative examples to show how CPA may be integrated into an

• how the service provider and authorization provider establish a trusted relationship (see clause 9.2);

• how a user verifies the association between their client and their user account (see clause 8.5).

CPA defines two modes of association: authenticated association ('user mode') which links a device to a user account,

and unauthenticated association ('client mode'), which provides a client identity to a device without linking it to a user

In both cases, the client is issued a persistent client ID so that it can be identified across requests to service providers

If the authorization provider offers user mode, then the client ID may be linked with a user account so that requests

from the device can be linked to that user. This linking of device and user is called 'authenticated association', or user

Once an authenticated association has been set up, a service provider can provide a unified personalized service across a