1、 ETSI TS 103 407 V1.1.1 (2016-04) Cross Platform Authentication for limited input hybrid consumer equipment TECHNICAL SPECIFICATION ETSI ETSI TS 103 407 V1.1.1 (2016-04)2 Reference DTS/JTC-033 Keywords authentication, authorization, protocol ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex
2、 - 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 enregistre la Sous-Prfecture 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
3、 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 pr
4、int, 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
5、this and other ETSI documents is available at https:/portal.etsi.org/TB/ETSIDeliverableStatus.aspx If you find errors in the present document, please send your comment to one of the following services: https:/portal.etsi.org/People/CommiteeSupportStaff.aspx Copyright Notification No part may be repr
6、oduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm except as authorized by written permission of ETSI. The content of the PDF version shall not be modified without the written authorization of ETSI. The copyright and the foregoing restricti
7、on extend to reproduction in all media. European Telecommunications Standards Institute 2016. All rights reserved. DECTTM, PLUGTESTSTM, UMTSTMand the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members. 3GPPTM and LTE are Trade Marks of ETSI registered for the benefit of its
8、Members and of the 3GPP Organizational Partners. GSM and the GSM logo are Trade Marks registered and owned by the GSM Association. ETSI ETSI TS 103 407 V1.1.1 (2016-04)3 Contents Intellectual Property Rights 5g3Foreword . 5g3Modal verbs terminology 5g3Executive summary 6g3Introduction 6g31 Scope 7g3
9、1.1 General . 7g32 References 7g32.1 Normative references . 7g32.2 Informative references 7g33 Definitions and abbreviations . 8g33.1 Definitions 8g33.2 Abbreviations . 8g34 Protocol overview 9g34.1 Introduction 9g34.2 Modes of association 10g34.2.1 Overview 10g34.2.2 Authenticated association (user
10、 mode) 10g34.2.3 Unauthenticated association (client mode) 10g35 Core concepts . 10g35.1 Bearer token . 10g35.2 Domain . 11g36 Roles . 11g36.1 Client 11g36.2 Service provider . 11g36.3 Authorization provider . 11g37 The device flow 12g37.1 Protocol version 12g37.2 Basic principles 12g37.2.1 HTTPS 12
11、g37.2.2 JSON . 12g37.2.3 Integrating applications with the CPA protocol 12g37.2.4 Example of authenticated association using the CPA device flow . 12g37.3 User mode 13g37.4 Client mode 14g37.5 Automatic provisioning of tokens 16g37.5.1 Overview 16g37.5.2 User signs in and enters a pairing code . 16g
12、37.5.3 User signs in and gives confirmation 17g37.5.4 Token is automatically granted . 19g37.5.5 Refreshing an expired access token 20g37.6 Deleting the association between a client and an authorization provider . 21g37.6.1 Overview 21g37.6.2 Deleting the association on the client side 21g37.6.3 Del
13、eting the association on the authorization provider side . 22g38. Client/Authorization Provider API . 22g38.1 Overview 22g38.2 /register - Register a client 23g38.2.1 /register request . 23g38.2.2 /register response 23g38.3 /associate - Associate a client with a user account . 24g3ETSI ETSI TS 103 4
14、07 V1.1.1 (2016-04)4 8.3.1 /associate request 24g38.3.2 /associate response 24g38.3.2.1 Pairing the client with a user account 24g38.3.2.2 Confirmation required before granting access to a new service 25g38.3.2.3 Access automatically granted to a new service . 26g38.4 /token - Obtain a bearer token
15、27g38.4.1 /token request 27g38.4.1.1 Client mode. 27g38.4.1.2 User mode . 27g38.4.1.3 Refreshing an expired access token 28g38.4.2 /token response . 28g38.5 Verification endpoint 30g38.5.1 Verification endpoint request 30g38.5.2 User permission request 30g38.5.3 Redirection response . 30g39 Service
16、Provider/Authorization Provider API 31g39.1 Overview 31g39.2 Establishing trust between the service provider and authorization provider 31g39.3 /authorized - Access token verification endpoint . 31g39.3.1 /authorized request 31g39.3.2 /authorized response . 31g3Annex A (informative): How to integrat
17、e applications with the CPA protocol 33g3A.1 Introduction 33g3A.2 Authentication challenge 33g3A.3 Accessing a protected resource 34g3Annex B (informative): Bibliography . 35g3B.1 Reference implementation 35g3B.2 Related documents . 35g3Annex C (informative): Change History 36g3History 37g3ETSI ETSI
18、 TS 103 407 V1.1.1 (2016-04)5 Intellectual Property Rights 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 0
19、00 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 server (https:/ipr.etsi.org/). Pursuant to the ETSI IPR Policy, no invest
20、igation, 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 server) which are, or may be, or may become, essential to the present document. Foreword This Technical Specifi
21、cation (TS) has been produced by Joint Technical Committee (JTC) Broadcast of the European Broadcasting Union (EBU), Comit Europen de Normalisation ELECtrotechnique (CENELEC) and the European Telecommunications Standards Institute (ETSI). NOTE: The EBU/ETSI JTC Broadcast was established in 1990 to c
22、o-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 i
23、s 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 countries in the European broadcasting area; its headquarters is
24、 in Geneva. European Broadcasting Union CH-1218 GRAND SACONNEX (Geneva) Switzerland Tel: +41 22 717 21 11 Fax: +41 22 717 24 81 Modal verbs terminology In the present document “shall“, “shall not“, “should“, “should not“, “may“, “need not“, “will“, “will not“, “can“ and “cannot“ are to be interprete
25、d as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions). “must“ and “must not“ are NOT allowed in ETSI deliverables except when used in direct citation. ETSI ETSI TS 103 407 V1.1.1 (2016-04)6 Executive summary The Cross Platform Authentication (CPA) pr
26、otocol 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 that device. Introduction The present document specifies version 1.0 of the Cross Platform Authentication (C
27、PA) 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 but implement services separately. The CPA prot
28、ocol 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 industry. For example, the CPA protocol can be used in the following scenarios: th
29、e 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 separate from one another; service providers from different companies use the same cent
30、ral authorization provider managed by a separate company (e.g. a national federated identity service). ETSI ETSI TS 103 407 V1.1.1 (2016-04)7 1 Scope 1.1 General The protocol described in the present document is intended for devices with limited input capabilities, such as hybrid radios, IP-connecte
31、d set top boxes and Smart TVs, that can communicate with web services over HTTPS. The protocol specifies two APIs: 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 servi
32、ce provider verifies an access token. The present document gives an overview of the protocol (clause 4), covering the core concepts (clause 5) and roles (clause 6) used in CPA and how the device flow works (clause 7). The CPA APIs are specified in the present document in clauses 8, Client/Authorizat
33、ion Provider API and clause 9, Service Provider/Authorization Provider API. 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 resour
34、ces. Although this clause is not normative, it is strongly recommended these conventions are followed where possible to maximize interoperability. 2 References 2.1 Normative references References are either specific (identified by date of publication and/or edition number or version number) or non-s
35、pecific. For specific references, only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies. Referenced documents which are not found to be publicly available in the expected location might be found at http:/docbox.e
36、tsi.org/Reference. NOTE While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee their long term validity. The following referenced documents are necessary for the application of the present document: 1 IETF RFC 2818: “HTTP Over TLS“. 2 IETF RFC 7159:
37、 “The JavaScript Object Notation (JSON) Data Interchange Format“. 3 IETF RFC 4122: “A Universally Unique Identifier (UUID) URN Namespace“. 2.2 Informative references References are either specific (identified by date of publication and/or edition number or version number) or non-specific. For specif
38、ic references, only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies. NOTE While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee their long term validity. The f
39、ollowing referenced documents are not necessary for the application of the present document but they assist the user with regard to a particular subject area. i.1 IETF RFC 6749: “The OAuth 2.0 Authorization Framework“. i.2 IETF RFC 6750: “The OAuth 2.0 Authorization Framework: Bearer Token Usage“. E
40、TSI ETSI TS 103 407 V1.1.1 (2016-04)8 3 Definitions and abbreviations 3.1 Definitions 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 w
41、hich the client identity is associated with a user identity authorization: granting of permission based on authenticated identification authorization provider: service that manages client identities and the association between client identities and authenticated user identities bearer token: securit
42、y 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: IP-connected hardware inten
43、ded for user interaction device flow: series of exchanges between the client and the authorization provider by which the client obtains a bearer token identity provider: service that manages identity information on behalf of users and services limited display device: device with the ability to displ
44、ay at least two rows of sixteen alphanumeric characters from the ISO-646 Invariant Code Set (loosely, 7-bit ASCII) 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
45、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 NOTE: See also access token and bearer token. unauthenticated association: association in which the client
46、identity is not associated with a user identity user: person or agent using an application user mode: authorization mode where the client relation is associated with a user account 3.2 Abbreviations For the purposes of the present document, the following abbreviations apply: API Application Programm
47、ing Interface CPA Cross Platform Authentication NOTE The subject of the present document. HTTP Hypertext Transfer Protocol HTTPS HTTP Secure OAuth Open Authorization URI Uniform Resource Identifier ETSI ETSI TS 103 407 V1.1.1 (2016-04)9 4 Protocol overview 4.1 Introduction The present document defin
48、es 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 identify the client device and any associated user account. Cross Platform Association (CPA) i
49、s 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 to complete the authorization. In the typical CPA device flow described below, the application-specific steps are prefixed with (
