GlobalPlatform Technology

Entity Attestation Protocol
Specification
Version 0.0.0.26
Public Review #2
July 2024
Document Reference: GPP_SPE_001

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.
Recipients of this document are invited to submit, with their comments, notification of any
relevant patents or other intellectual property rights of which they may be aware which might benecessarily infringed by the implementation of the specification or other work product set forth in
this document, and to provide supporting documentation. This document (and the information
herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be
disseminated without restriction. Use of the information herein (whether or not obtained directlyfrom GlobalPlatform) is subject to the terms of the corresponding GlobalPlatform license
agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to
sublicensing) inconsistent with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 2 / 91
THIS SPECIFICATION OR OTHER WORK PRODUCT IS BEING OFFERED WITHOUT ANY WARRANTYWHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NON-INFRINGEMENT IS EXPRESSLYDISCLAIMED. ANY IMPLEMENTATION OF THIS SPECIFICATION OR OTHER WORK PRODUCT SHALL
BE MADE ENTIRELY AT THE IMPLEMENTER’S OWN RISK, AND NEITHER THE COMPANY, NOR ANY
OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY
IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER DIRECTLY OR
INDIRECTLY ARISING FROM THE IMPLEMENTATION OF THIS SPECIFICATION OR OTHERWORK PRODUCT.

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 3 / 91

Contents
1

Introduction .............................................................................................................................. 92

Overview ................................................................................................................................. 17

3

Principles and Concepts ....................................................................................................... 19

4

Entity Attestation API............................................................................................................. 24

1.1
1.2
1.3
1.4
1.5
1.6

3.1
3.2

Audience ...............................................................................................................................................9
IPR Disclaimer ......................................................................................................................................9
References ............................................................................................................................................9
Terminology and Definitions ...............................................................................................................10
Abbreviations and Notations ...............................................................................................................14
Revision History ..................................................................................................................................16

Entity ...................................................................................................................................................19
Entity Attestation .................................................................................................................................193.2.1 Relying Party ................................................................................................................................19
3.2.2 Entity Attestation Client ................................................................................................................19
3.2.3 Entity Attestation Service .............................................................................................................19
3.2.4 Remote Attestation.......................................................................................................................19
3.2.5 Entity Attestation Service Protocol ...............................................................................................19
3.3
Operation ............................................................................................................................................20
3.4
Claim ...................................................................................................................................................20
3.5
Claims Set ...........................................................................................................................................20
3.6
Unendorsed Claims Set ......................................................................................................................20
3.7
COSE Object.......................................................................................................................................20
3.8
COSE Messages.................................................................................................................................21
3.9
CBOR Web Token ..............................................................................................................................21
3.10
Entity Attestation Token ......................................................................................................................21
3.11
Signed EAT .........................................................................................................................................21
3.12
Encrypted EAT ....................................................................................................................................21
3.13
MACed EAT ........................................................................................................................................22
3.14
Tagged EAT ........................................................................................................................................22
3.15
Entity Attestation Parcel ......................................................................................................................22
3.16
CBOR and CDDL ................................................................................................................................22
3.16.1 Normative nature of CDDL definitions .........................................................................................22
3.16.2 CDDL prelude ..............................................................................................................................22
3.16.3 CBOR Deterministic Encoding .....................................................................................................22
3.16.4 Validity of CBOR encoding ..........................................................................................................22
4.1
4.2
4.3
4.4
4.5
4.6
4.7

Overview .............................................................................................................................................24
Architecture .........................................................................................................................................25
Security ...............................................................................................................................................26
Message Encoding..............................................................................................................................26
Entity Attestation Session ...................................................................................................................26
Entity Attestation Transaction .............................................................................................................26
Entity Attestation Messages ................................................................................................................27
4.7.1 Parameters ...................................................................................................................................27
4.7.2 TPSEAP_Attest ............................................................................................................................28

5

Operations .............................................................................................................................. 29

5.1
5.2

Outline of Parcel Exchange Operations ..............................................................................................29
Parcel Exchange .................................................................................................................................29

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 4 / 91
5.3

Request EAP Claims...........................................................................................................................30
5.3.1 Nonce Request Claim ..................................................................................................................30
5.3.2 Context Request Claim ................................................................................................................30
5.3.3 Justification Request Claim ..........................................................................................................30
5.3.4 Important Request Claim .............................................................................................................31
5.3.5 Unnecessary Request Claim .......................................................................................................31

6

Claims...................................................................................................................................... 32

6.1

Data Types ..........................................................................................................................................32
6.1.1 Binary Coded Decimal .................................................................................................................32
6.1.2 UUID.............................................................................................................................................32
6.1.3 Claim Prompt ...............................................................................................................................32
6.1.3.1 Simple Claim Prompt ...........................................................................................................33
6.1.3.2 Subclaim Claim Prompt .......................................................................................................33
6.1.3.3 Hierarchical Claim Prompt ...................................................................................................33
6.1.4 Security Rating .............................................................................................................................34
6.1.5 SE Secure Element Type .............................................................................................................34
6.1.6 SE Card Lifecycle State Type ......................................................................................................35
6.1.7 SE Supplementary Security Domain Type ..................................................................................35
6.1.7.1 issuer_number .....................................................................................................................35
6.1.7.2 image_number .....................................................................................................................36
6.1.7.3 key_derivation_data ............................................................................................................36
6.1.7.4 key_information_data ..........................................................................................................36
6.1.7.5 default_kvn ..........................................................................................................................36
6.1.7.6 default_kvn_sequence_ctr...................................................................................................36
6.1.8 TEE Lifecycle State Type .............................................................................................................36
6.1.9 TEE Trusted OS Architectures Type............................................................................................37
6.1.9.1 isa_processor_type .............................................................................................................37
6.1.9.2 isa_instruction_set ...............................................................................................................37
6.1.9.3 isa_address_Size ................................................................................................................37
6.1.9.4 isa_abi_information .............................................................................................................37
6.1.10 isa_endianness ............................................................................................................................38
6.1.11 TEE Options Type ........................................................................................................................38
6.1.12 TEE Implementation Properties Type ..........................................................................................39
6.1.13 TEE Properties Value Type .........................................................................................................41
6.1.14 TEE Identity Type.........................................................................................................................42
6.1.15 TEE Trusted Applications Type ...................................................................................................42
6.1.15.1 parent.................................................................................................................................42
6.1.15.2 lifecycle_state ....................................................................................................................42
6.1.15.3 version ...............................................................................................................................42
6.1.15.4 measurement .....................................................................................................................43
6.1.15.5 description .........................................................................................................................43
6.1.15.6 properties ...........................................................................................................................43
6.1.15.7 extra_data ..........................................................................................................................43
6.1.16 TEE Trusted Application Lifecycle State Type .............................................................................43
6.1.17 TEE Security Domains Type ........................................................................................................44
6.1.17.1 sd_parent ...........................................................................................................................44
6.1.17.2 sd_lifecycle_state ..............................................................................................................44
6.1.17.3 sd_authority .......................................................................................................................44
6.1.17.4 sd_privileges ......................................................................................................................44
6.1.17.5 sd_protocols ......................................................................................................................44
6.1.18 TEE Security Domain Lifecycle State Type .................................................................................45
6.1.19 TEE Security Domain Authority Type ..........................................................................................45

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 5 / 91
6.1.20 TEE Security Domain Privileges Type .........................................................................................46
6.1.21 TEE Security Domain Protocols Type..........................................................................................46
6.1.22 TEE Client Properties Type .........................................................................................................47
6.2
Privacy.................................................................................................................................................48
6.3
Claims from the CBOR Web Token Specification ..............................................................................48
6.4
Claims from the Entity Attestation Token Specification ......................................................................49
6.5
Top Level Claims ................................................................................................................................51
6.5.1 GlobalPlatform Component ..........................................................................................................51
6.6
Claims Applicable to All Entities ..........................................................................................................52
6.6.1 Security Rating .............................................................................................................................52
6.6.2 MUD File URL ..............................................................................................................................52
6.6.3 Legacy Material ............................................................................................................................52
6.6.4 Justification ..................................................................................................................................52
6.6.5 Context .........................................................................................................................................52
6.6.6 Important ......................................................................................................................................53
6.6.7 Unnecessary ................................................................................................................................53
6.6.8 GP EAT Version ...........................................................................................................................53
6.7
Claims Applicable to Secure Elements ...............................................................................................54
6.7.1 SE ISD Issuer Identification Number ...........................................................................................54
6.7.2 SE ISD Card Image Number ........................................................................................................54
6.7.3 SE ISD CRD Runtime Type .........................................................................................................54
6.7.4 SE ISD CRD Runtime Version .....................................................................................................54
6.7.5 SE ISD CRD GlobalPlatform Configuration Identifier ..................................................................55
6.7.6 SE ISD CRD GlobalPlatform Configuration Version ....................................................................55
6.7.7 SE ISD CCI Secure Channel Protocols .......................................................................................55
6.7.7.1 SE ISD CCI Secure Channel Protocol Options ...................................................................55
6.7.7.2 SE ISD CCI Secure Channel Protocol SCP03 Keys ...........................................................56
6.7.7.3 SE ISD CCI Secure Channel Protocol SCP81 TLS Suites .................................................56
6.7.7.4 SE ISD CCI Secure Channel Protocol SCP81 Max Length ................................................56
6.7.8 SE ISD CCI SSD Privileges .........................................................................................................56
6.7.9 SE ISD CCI Application Privileges ...............................................................................................56
6.7.10 SE ISD CCI LFDB Hash Algorithms ............................................................................................57
6.7.11 SE ISD CCI LFDB Encryption Cypher Suites ..............................................................................57
6.7.12 SE ISD CCI Token Cypher Suites ...............................................................................................57
6.7.13 SE ISD CCI Receipt Cypher Suites .............................................................................................57
6.7.14 SE ISD CCI DAP Cypher Suites ..................................................................................................57
6.7.15 SE ISD CCI Key Parameters .......................................................................................................57
6.7.16 SE Secure Element Type .............................................................................................................58
6.7.17 SE Operating System Vendor ......................................................................................................58
6.7.18 SE Operating System Version .....................................................................................................58
6.7.19 SE Chip Manufacturer ..................................................................................................................58
6.7.20 SE Chip Serial Number ................................................................................................................58
6.7.21 SE Chip Version ...........................................................................................................................58
6.7.22 SE Card Lifecycle State ...............................................................................................................59
6.7.23 SE Card Content Management Restriction Parameters ..............................................................59
6.7.24 SE Supplementary Security Domains ..........................................................................................59
6.7.25 SE CASD Certificate Store ..........................................................................................................59
6.8
Claims Applicable to Trusted Execution Environments ......................................................................60
6.8.1 TEE Platform Label ......................................................................................................................60
6.8.2 TEE Root Security Domains ........................................................................................................60
6.8.3 TEE Lifecycle State ......................................................................................................................60
6.8.4 TEE Device Name........................................................................................................................60
Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 6 / 91
6.8.5
6.8.6
6.8.7
6.8.8
6.8.9
6.8.106.8.11
6.8.12
6.8.136.8.14

TEE Device Manufacturer ............................................................................................................60
TEE Device Type .........................................................................................................................61
TEE Trusted OS Name ................................................................................................................61
TEE Trusted OS Architectures .....................................................................................................61
TEE Trusted OS Options .............................................................................................................61
TEE Optional APIs .......................................................................................................................61
TEE Implementation Properties ...................................................................................................62
TEE Trusted Applications ............................................................................................................62
TEE Security Domains .................................................................................................................62
TEE Client Properties...................................................................................................................62

7

Claims Sets ............................................................................................................................. 63

8

Unendorsed Claims Sets ....................................................................................................... 65

9

Entity Attestation Tokens ...................................................................................................... 66

7.1
7.2

Subclaims ............................................................................................................................................63
Submodules ........................................................................................................................................63

8.1
8.2

Construction ........................................................................................................................................65
Interpretation .......................................................................................................................................65

10 Signed Entity Attestation Tokens ......................................................................................... 67
10.1
10.2
10.3

Prerequisites .......................................................................................................................................67
Context ................................................................................................................................................67
Construction ........................................................................................................................................68
10.3.1 Creating the Content ....................................................................................................................68
10.3.2 Signing the EAT ...........................................................................................................................68
10.4
Interpretation .......................................................................................................................................69

11 Encrypted Entity Attestation Tokens ................................................................................... 70
11.1

Prerequisites .......................................................................................................................................70
11.1.1 Symmetric Encryption ..................................................................................................................70
11.1.2 Asymmetric Encryption ................................................................................................................70
11.2
Context ................................................................................................................................................70
11.3
Construction ........................................................................................................................................71
11.3.1 Creating the Content ....................................................................................................................71
11.3.2 Encrypting the EAT ......................................................................................................................71
11.4
Interpretation .......................................................................................................................................72

12 MACed Entity Attestation Tokens......................................................................................... 73
12.1
12.2
12.3

Prerequisites .......................................................................................................................................73
Context ................................................................................................................................................73
Construction ........................................................................................................................................74
12.3.1 Creating the Content ....................................................................................................................74
12.3.2 MACing the EAT ..........................................................................................................................74
12.4
Interpretation .......................................................................................................................................75

13 Multiply Endorsed Entity Attestation Tokens ...................................................................... 76
14 Tagging Entity Attestation Tokens ....................................................................................... 77
14.1
14.2

Construction ........................................................................................................................................77
Interpretation .......................................................................................................................................77

15 Detached EAT Bundles .......................................................................................................... 78
16 Dependencies on Other Specifications ................................................................................ 79
16.1

Dependency on [RFC 8949] ...............................................................................................................79

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 7 / 91
16.2
16.3
16.4
16.5
16.6

Dependency on [RFC 8152] ...............................................................................................................79
Dependency on [RFC 8230] ...............................................................................................................79
Dependency on [RFC 8392] ...............................................................................................................79
Dependency on [draft-ietf-rats-eat] .....................................................................................................79
Dependency on [draft-birkholz-rats-uccs] ...........................................................................................79

17 IANA Considerations ............................................................................................................. 80
17.1
17.2
17.3
17.4
17.5
17.6
17.7

Reuse of Concise Binary Object Representation (CBOR) Registries ................................................80
Reuse of CBOR Object Signing and Encryption (COSE) Registries ..................................................80
Reuse of RSA Algorithms with COSE Messages Registries ..............................................................80
Reuse of CBOR Web Token (CWT) Registries ..................................................................................80
Reuse of Entity Attestation Token (EAT) Registries ...........................................................................80
Reuse of Unprotected CWT Claims Set (UCCS) Registries...............................................................81
Claims Registered by This Document.................................................................................................81

Annex A

Configurations ......................................................................................................... 82

Annex B

Examples .................................................................................................................. 83

B.1

Example Claims Sets ..........................................................................................................................83
B.1.1 Example Flat SE Claims Set ........................................................................................................83
B.1.2 Example Flat TEE Claims Set......................................................................................................84
B.1.3 Example Claims Set with Subclaims ...........................................................................................85
B.1.4 Example Claims Set with Submodules ........................................................................................86
B.2
Example Unendorsed Claims Sets .....................................................................................................88
B.2.1 Example Unendorsed Claims Set ................................................................................................88
B.2.2 Example Tagged Unendorsed Claims Set...................................................................................88
B.3
Example Entity Attestation Tokens .....................................................................................................89
B.3.1 Example Signed Token ................................................................................................................89
B.3.2 Example Encrypted Token ...........................................................................................................89
B.3.3 Example MACed Token ...............................................................................................................90
B.3.4 Example Signed Then Encrypted Token .....................................................................................90
B.3.5 Example Tagged Encrypted Token..............................................................................................91

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 8 / 91

TablesTable 1-1: Normative References......................................................................................................................9
Table 1-2: Terminology and Definitions ...........................................................................................................10
Table 1-3: Abbreviations and Notations ..........................................................................................................14
Table 1-4: Revision History .............................................................................................................................16
Table 4-1: Entity Attestation Parameters and Assigned Values......................................................................27
Table 4-2: Status Values and Meanings .........................................................................................................27
Table A-1: Restrictions on Claims (Example)..................................................................................................82
Table A-2: Restrictions on Signing Algorithms (Example) ..............................................................................82
Table A-3: Restrictions on Encryption Algorithms (Example) .........................................................................82

FiguresFigure 4-1: Entity Attestation Overview ...........................................................................................................24
Figure 4-2: Entity Attestation Architecture .......................................................................................................25

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 9 / 91

1

1

INTRODUCTION2
3

The aim of this document is to define Claims and how to assemble, encrypt, and sign them for use in
Attestation.

4

1.1

5
6

This document is intended primarily for the use of device manufacturers aiming to implement attestation
procedures, and for developers of applications that rely on the information provided by such devices.

7

1.2

8
9
10
11
12
13

Attention is drawn to the possibility that some of the elements of this GlobalPlatform specification or other work
product may be the subject of intellectual property rights (IPR) held by GlobalPlatform members or others. For
additional information regarding any such IPR that have been brought to the attention of GlobalPlatform,
please visit https://globalplatform.org/specifications/ip-disclaimers/. GlobalPlatform shall not be held
responsible for identifying any or all such IPR, and takes no position concerning the possible existence or theevidence, validity, or scope of any such IPR.

14

1.3

15
16

The tables below list references applicable to this specification. The latest version of each reference applies
unless a publication date or version is explicitly stated.

17

Table 1-1: Normative References

Audience

IPR Disclaimer

References

Standard / Specification

Description

Ref

GPC_SPE_034

GlobalPlatform Technology
Card Specification v2.3.1[GPCS]

GP_REQ_025

GlobalPlatform Technology
Root of Trust Definitions and Requirements v1.1

[RoT]

GPC_SPE_095

GlobalPlatform Technology
Digital Letter of Approval v1.0

[DLoA]

GPD_SPE_010

GlobalPlatform Technology
TEE Internal Core API Specification v1.3

[TEE Core]

GPD_SPE_120

GlobalPlatform Technology
TEE Management Framework including ASN.1 Profile
v1.1.2[TMF]

GPP_SPE_009

GlobalPlatform Technology
TPS Client API Specification v1.0

[TPS Client]

IETF RFC 2119

Key words for use in RFCs to Indicate Requirement
Levels[RFC 2119]

IETF RFC NNNN

Entity Attestation Token[draft-ietf-ratseat]

Pending publication (draft-ietf-rats-eat-29)

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 10 / 91
Standard / Specification

Description

Ref

IETF RFC NNNN

Unprotected CWT Claims Sets
Pending publication (draft-ietf-rats-uccs-10)[draft-birkholzrats-uccs]

IETF RFC 4122

A Universally Unique Identifier (UUID)[RFC 4122]

IETF RFC 6979

Deterministic Usage of the Digital Signature Algorithm(DSA) and Elliptic Curve Digital Signature Algorithm(ECDSA)[RFC 6979]

IETF RFC 8949

Concise Binary Object Representation (CBOR)[RFC 8949]

IETF RFC 8152

CBOR Object Signing and Encryption (COSE)[RFC 8152]

IETF RFC 8230

Using RSA Algorithms with COSE Messages[RFC 8230]

IETF RFC 8392

CBOR Web Token (CWT)[RFC 8392]

IETF RFC 8520

Manufacturer Usage Description (MUD)[RFC 8520]

IETF RFC 8610

Concise Data Definition Language (CDDL)[RFC 8610]

ISO/IEC 7812-1:2017

Identification cards -- Identification of issuers -- Part 1:
Numbering system[ISO 7812-1]

18
19

1.4

Terminology and Definitions

20
21

The following meanings apply to SHALL, SHALL NOT, MUST, MUST NOT, SHOULD, SHOULD NOT, and
MAY in this document (refer to [RFC 2119]):

22• SHALL indicates an absolute requirement, as does MUST.

23• SHALL NOT indicates an absolute prohibition, as does MUST NOT.

24

• SHOULD and SHOULD NOT indicate recommendations.

25• MAY indicates an option.

26

Selected terms used in this document are included in Table 1-2.

27

Table 1-2: Terminology and Definitions
Term

Definition

Application

Device/terminal/mobile application. An application that is installed in andruns within the device.

Application Programming
Interface (API)A set of rules that software programs can follow to communicate witheach other.

Attestation

The process of providing information about credentials within an Entity,
with some level of assurance of authenticity.

Basic Parcel Exchange

The generic Operation (described in section 5.2) on which more specificOperations are based.

Bootstrapped Root of Trust

A Root of Trust whose implementation required several components. It is
composed of one Initial Root of Trust Component and one or more
Extended Root of Trust Components.

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 11 / 91
Term

Definition

Chain of Trust

A transitive trust relationship starting from a Root of Trust that is
propagated to the Validated/Measured Modules (as discussed in [RoT])
when a software module verifies/measures the next software module andkeeps a reportable record of this verification.

Claim

A piece of information in the form of a key/value pair that represents anassertion about a single characteristic either internal to an Entity orprovided to it by a third party.

Claim KeyThe CBOR map key used to identify a Claim.

Claim Name

The human-readable name used to identify a Claim.

Claim Value

The CBOR map value representing the value of a Claim.

Claimant

A producer of evidence about its own characteristics.

Claims Set

An aggregation of one or more Claims.

Detached EAT Bundle

Optional structure that can be used to convey claim sets for which adigest is included in an EAT.

DeviceAn end-user product that includes at least one Platform.

Empty EAPIn the context of this document, an Entity Attestation Parcel with an empty
Claims Set.

EndorseTo provide additional information – signature, encryption, or MAC – toenhance the integrity, confidentiality, or authenticity of the underlying
information.

EntityA Platform that has the capability to generate Claims Entity Attestation
Parcels.

Entity Attestation Client(EAC)

A service within an Entity that is responsible for generating a Request
Entity Attestation Parcel.

Entity Attestation Parcel(EAP)

An aggregation of credential information that is provided to a Relying
Party; can be either endorsed or unendorsed.

Entity Attestation Service(EAS)

A service within an Entity that is responsible for generating a Response
Entity Attestation Parcel.

Entity Attestation Token(EAT)

An endorsed aggregation of credential information that is provided to a
Relying Party.

Evidence

A piece of information that is included in a Claim.

Execution Environment (EE)An environment that hosts and executes software. This could be a REE,with hardware hosting Android, Linux, Windows, an RTOS, or othersoftware; it could be a Secure Element or a TEE.

Key Construction Algorithm

A cryptographic mechanism by which a key can be constructed frompre-existing or supplied key material. Key construction can include key
agreement and/or key derivation.

Key Distribution

A mechanism by which cryptographic key material can be provided fromone device to another by secure means. This can be achieved by Key
Construction or Key Wrapping.

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 12 / 91
Term

Definition

Key Wrapping

A mechanism by which a private key can be provided to a remote device
by encrypting it with key material known by both parties.

Message Authentication
Code (MAC)

A symmetric cryptographic transformation of data that provides data origin
authentication and data integrity. In the context of this specification,
created as described in section 12.3.2.

Non-Bootstrapped Root ofTrust

A Root of Trust that is composed of only one block of code.

Operation

A defined mechanism by which an Entity Attestation Client can obtainattestation information from an Entity Attestation Service; takes the formof challenge and response. Formally, because an EAT is constructed,
transported, and processed in each direction, an Operation is comprisedof a Remote Attestation from Client to Service, followed by a Remote
Attestation from Service to Client.

Platform

One computing engine and executable code that provides a set offunctionalities. SE, TEE, and REE are examples of platforms.

Regular Execution
Environment (REE)An Execution Environment comprising at least one Regular OS and allother components of the device (IC packages, other discrete components,
firmware, and software) that execute, host, and support the Regular OSes
(excluding any Secure Components included in the device).
From the viewpoint of a Secure Component, everything in the REE isconsidered untrusted, though from the Regular OS point of view there
may be internal trust structures.
(Formerly referred to as a Rich Execution Environment (REE).)
Contrast Trusted Execution Environment (TEE).

Regular OS

An OS executing in a Regular Execution Environment. May be anythingfrom a large OS such as Linux down to a minimal set of statically linked
libraries providing services such as a TCP/IP stack.
(Formerly referred to as a Rich OS or Device OS.)

Relying Party

In the context of this document, a party that receives an Entity Attestation
Token, potentially in response to a request, in order to determine thevalue or authenticity of credentials contained within it.

Remote Attestation

The process by which attestation information is assembled by an Entity
Attestation Service, transferred to a Relying Party, and processed.

Request EAPAn EAP sent from the Entity Attestation Client to the Entity Attestation
Service.

Response EAPAn EAP returned by the Entity Attestation Service to the Entity Attestation
Client.

Root of Trust (RoT)

A computing engine, code, and possibly data, all co-located on the same
platform; provides security services.
No ancestor entity is able to provide a trustable attestation (in digest orother form) for the initial code and data state of the Root of Trust.
Depending on the implementation, the Root of Trust is either a
Bootstrapped or a Non-Bootstrapped Root of Trust.

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 13 / 91
Term

Definition

Secure Component

A security hardware/firmware combination that acts as an on-device trust
anchor. Facilitates collaboration between service providers and device
manufacturers, empowering them to ensure adequate security within all
devices to protect against threats.
Examples include GlobalPlatform’s Secure Element and Trusted
Execution Environment.

Secure Element (SE)A tamper-resistant secure hardware component that is used in a device toprovide the security, confidentiality, and multiple application environment
required to support various business models. May exist in any form factor,
such as embedded or integrated SE, SIM/UICC, smart card, smart
microSD, etc.
For more information, see [GPCS] and related specifications.

Subclaim

In the context of this document, a Claim that has a defined meaning only
when included in the value field of a parent Claim.

submodule (submod)

A grouping of information, such as Claims, describing a subsystem withina device. For more information, see [draft-ietf-rats-eat] and section 7.2 ofthis specification.

TPS Client

An entity that uses the TPS Client API to discover and communicate witha TPS Service. A TPS Client can be either an Application or another TPS
Service.

TPS Service

A service in a Secure Component, providing a service to entities in theoperating system; accessed using a TPS Service Protocol that is
specified in a TPS Service specification.

TPS Service Protocol

A protocol that is used to communicate with the TPS Service; consists ofa set of TPS Operations.

Trusted Execution
Environment (TEE)An Execution Environment that runs alongside but isolated from
Execution Environments outside of the TEE. A TEE has security
capabilities and meets certain security-related requirements: It protects
TEE assets against a set of defined threats which include generalsoftware attacks as well as some hardware attacks, and defines rigid
safeguards as to data and functions that a program can access. There
are multiple technologies that can be used to implement a TEE, and thelevel of security achieved varies accordingly.
Contrast Regular Execution Environment (REE).

Trusted OS

An OS executing in a Secure Component.
Contrast Regular OS.

Unendorsed Claims Set

An unendorsed aggregation of credential information that is provided to a
Relying Party.

28

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 14 / 91

29

1.5

Abbreviations and Notations

30

Table 1-3: Abbreviations and Notations
Abbreviation / Notation

Meaning0-9

Decimal digits are not enclosed in quotation marks.

'0' - '9' and 'A' - 'F'

Hexadecimal values are enclosed in straight single quotation marks.

ABI

Application Binary Interface

AES

Advanced Encryption Standard

API

Application Programming Interface

BCD

Binary Coded Decimal

CASD

Controlling Authority Security Domain

CBOR

Concise Binary Object Representation

CCI

Card Capability Information

CCM

Card Content Management

CIN

Card Image Number

COSE

CBOR Object Signing and Encryption

CRD

Card Recognition DataCWTCBOR Web Token

DAP

Data Authentication Pattern

DLoA

Digital Letter of Approval

DSA

Digital Signature Algorithm

EAC

Entity Attestation Client

EAP

Entity Attestation Parcel

EAS

Entity Attestation Service

EAT

Entity Attestation Token

ECDSA

Elliptic Curve Digital Signature Algorithm

EE

Execution EnvironmenteSE

Embedded Secure Element

GCM

Galois Counter Mode

HLOS

High Level Operating System

IANA

Internet Assigned Numbers Authority

IETF

Internet Engineering Task Force

IIN

Issuer Identification Number

ISD

Issuer Security Domain

JOSE

JavaScript Object Signing and Encryption

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 15 / 91
Abbreviation / Notation

Meaning

JSON

JavaScript Object Notation

JWT

JSON Web Token

LFDB

Load File Data Block

MAC

Message Authentication Code

OAEP

Optimal Asymmetric Encryption Padding

PKI

Public Key Infrastructure

PSS

Probabilistic Signature Scheme

RATS

Remote ATtestation ProcedureS

REE

Regular Execution Environment

RoT

Root of Trust

RSA

Rivest / Shamir / Adleman asymmetric algorithm

SE

Secure Element

SHA

Secure Hash Algorithm

SSD

Supplementary Security Domain

submodsubmoduleSW

Status Word

TEE

Trusted Execution Environment

UCCS

Unprotected CWT Claims Set

UCS

Unendorsed Claims Set

UEID

Universal Entity ID

URI

Uniform Resource Identifier

UTF-8

Unicode Transformation Format – 8-bit

31

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 16 / 91

32

1.6

Revision History

33
34
35
36
37

GlobalPlatform technical documents numbered n.0 are major releases. Those numbered n.1, n.2, etc., areminor releases where changes typically introduce supplementary items that do not impact backward
compatibility or interoperability of the specifications. Those numbered n.n.1, n.n.2, etc., are maintenancereleases that incorporate errata and clarifications; all non-trivial changes are indicated, often with revisionmarks.

38

Table 1-4: Revision History
Date

VersionDescription

May 2019

0.0.0.3

Committee Review

Nov 2020

0.0.0.11

Member Review

Feb 2023

0.0.0.19

Member Review #2

July 2023

0.0.0.20

Public Review

July 2024

0.0.0.26

Public Review #2

TBD

1.0

Initial release39

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 17 / 91

40

2

OVERVIEW

41
42
43
44

The GlobalPlatform Root of Trust Definitions and Requirements document ([RoT]) describes the concept of a
Platform that contains a computing engine and executable code that provides a set of functionalities. Examples
of a Platform are a Trusted Execution Environment (TEE) and an embedded Secure Element (eSE). In thecontext of a Chain of Trust, a Platform contains a Root of Trust.

45
46
47
48
49
50

The IETF NNNN specification ([draft-ietf-rats-eat]) introduces the concept of Attestation, which is a mechanism
by which an Entity can provide information about itself with some level of assurance to a Relying Party. The
term Entity in this specification corresponds to the term Platform in [RoT]. During Attestation, an Entity
Attestation Service builds a set of Claims, each of which consists of a piece of evidence provided by a Claimant.
There can be multiple Claimants providing evidence to an Entity Attestation Service, and the EAS itself canalso be a Claimant.

51
52
53
54
55

There is a need to keep the size of the code in a Root of Trust to a minimum, and to limit the amount of datathat has to be transmitted over potentially bandwidth- and power-constrained links. For these reasons, thisspecification only defines the use of COSE ([RFC 8152]) for the construction of Entity Attestation Tokens.
COSE is compact, but has all the necessary features to support both the claims structure and a wide variety
of different protection mechanisms including signing and encryption.

56
57
58
59
60
61

The Claims are aggregated, optionally signed using a signing algorithm, optionally encrypted using an
encryption algorithm, and optionally MACed using a MAC algorithm; the result is an Entity Attestation Token.
This Token is provided to the Entity Attestation Client within the Relying Party, which can then determine thenecessary information about the Platform from the Claims and decide its level of confidence in the authenticityof this information. The process of creating an Entity Attestation Token, transferring it, and processing it in an
Entity Attestation Client is referred to as Remote Attestation.

62
63
64
65
66

There are circumstances in which the communication used to transport claims sets is already sufficiently
secure that there is no benefit to further endorsement. In such circumstances, it is possible to avoid theoverhead of unnecessary cryptographic algorithms and send a claims set in an unendorsed form. The IETF
NNNN specification [draft-birkholz-rats-uccs] introduced the concept of an Unprotected CWT Claims Set, inwhich the claims set is simply prefixed with a defined value that indicates the nature of the information.

67
68

In this document, the term Entity Attestation Parcel (EAP) is used to cover cases in which a claims set iswrapped in either an endorsed (EAT) or unendorsed (UCS) form.

69
70
71
72
73
74

Where a device is composed of multiple platforms, as defined in [RoT], it is possible for a given platform toinclude Claims from other platforms within the device using the concept of submodules. If the other platform
has the ability to create a complete Entity Attestation Token, this can be included as a nested EAT. Otherwise,
Claims from the other platform can be nested directly. In the first case, the credibility of the Claims isestablished by the security level of the platform that generated the nested EAT. In the second case, it isestablished by the security level of the platform that is including the submodule Claims.

75
76
77
78
79

The Entity Attestation Client consists of two conceptually distinct functions: a party that determines whichclaims it needs in order to decide whether to trust a remote device, and a party that verifies the claims that arereceived. The verifying party can be local, or it can be delegated to a separate entity. However, since thisdocument defines the mechanisms by which verification can take place, but not the policies that drive where
this occurs, it covers both cases.

80
81
82
83
84

This specification introduces Operations by which the Entity Attestation Client can request an Entity Attestation
Parcel from an Entity Attestation Service using an API. The Relying Party can instruct the Entity Attestation
Client to provide various types of information to the Entity Attestation Service, which can influence the content
and structure of the Token. An EAP sent from the Entity Attestation Client to the Entity Attestation Service iscalled a Request EAP, and an EAP returned to the Entity Attestation Client is called a Response EAP.

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 18 / 91

85
86
87

This specification defines various options that are available for Entity Attestation but makes no restrictions for
specific uses. Any such restrictions that assist with interoperability are expected to be defined in configuration
documents.

88

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 19 / 91

89

3

PRINCIPLES AND CONCEPTS

90

This section defines the principles and concepts used or introduced in this specification.

91

3.1

92
93
94
95

An Entity corresponds to a Platform in [RoT] and the terms may be used interchangeably. It contains a Rootof Trust, which has the capability to store and/or receive Claims, aggregate them, optionally sign them,
optionally encrypt them, and optionally MAC them to produce an Entity Attestation Parcel (EAP, as describedin section 3.15).

Entity96
97

3.2

Entity Attestation

98
99

Entity Attestation is the process of acquiring attestation information by exchanging Entity Attestation Parcels
with another Entity. The process of attestation could involve multiple exchanges of Entity Attestation Parcels.

100

3.2.1

101
102

A Relying Party is an application, or a proxy for an application, that wishes to obtain a degree of assurance
about the origin, state, and/or attributes of another Entity.

103

3.2.2

104
105
106

An Entity Attestation Client is an application within a Relying Party that communicates with an Entity Attestation
Service to obtain attestation information on its behalf. The Entity Attestation Client is responsible for evaluating
evidence and determining its level of trustworthiness.

107

3.2.3

108
109
110
111

An Entity Attestation Service is a service provided to Relying Parties that receives and parses request Entity
Attestation Parcels, and constructs response Entity Attestation Parcels. The Entity Attestation Service
assembles claims from its own environment, and/or claims provided by other environments, and optionallyuses cryptographic methods to provide authenticity and/or confidentiality.

112

3.2.4

113
114

Remote Attestation refers to the complete process in which an Entity Attestation Parcel is created, transferred,and processed by a party distinct (remote) from the party providing evidence.

115

3.2.5

116
117
118

The Entity Attestation Service Protocol is the interface that allows a Relying Party to communicate with an
Entity Attestation Service. The Entity Attestation Service Protocol makes use of the Trusted Platform Services
Client API ([TPS Client]).

119

The Entity Attestation Service Protocol is defined in section 4.

Relying Party

Entity Attestation Client

Entity Attestation Service

Remote Attestation

Entity Attestation Service Protocol

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 20 / 91

120

3.3

Operation

121

An exchange of Entity Attestation Parcels using the API is referred to as an Operation.

122

Operations are defined in section 5.

123

3.4

124
125
126
127
128
129

A Claim is an identified piece of evidence either internal to the Root of Trust or received from elsewhere within
the Platform. Claims might originate from RoT services such as Measurement or Reporting (as discussed in[RoT]). An example of a Claim originating within the RoT is “here is my boot status providing evidence that I
debug is currently disabled”. An example of a Claim not originating within the RoT is “here is a measurementthat was provided to me by an installed REE”. For compactness of storage and transfer, a Claim consists of a
Claim Key plus a Claim Value. For human readability, a Claim Name is also defined for each Claim.

130

A Claim can be represented as a pair of CBOR Data Items, as discussed in [RFC 8949].

131
132

By defining a Claim for which the value is a compound structure defined below, it is possible to introduce
hierarchy (see section 6.1.3.3).

133

Claims are defined in section 6.

134

3.5

135
136
137

A Claims Set is an aggregation of one or more Claims. There is no requirement for the Claims to be related inany way, other than by origination. Compound structures such as submod SHOULD be used to group claims
with the same originator.

138
139

A Claims Set SHALL be represented as a CBOR Map, as discussed in [RFC 8949], even when only a single
Claim is present.

140

Rules for Claims Sets are given in section 7.

Claim

Claims Set

141
142

3.6

Unendorsed Claims Set

143
144

An Unendorsed Claims Set is a Claims Set that is prefixed by a defined tag value, but is not encapsulated in
COSE format.

145

Rules for constructing and interpreting Unendorsed Claims Sets are given in section 8.

146
147

3.7

COSE Object

148
149
150

At the core of an Entity Attestation Token is a COSE Object as defined in [RFC 8152]. This consists of aprotected header, an unprotected header, and a byte string containing the content. In the context of thisspecification, the content is a Claims Set that is encapsulated in a CBOR Byte String.

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 21 / 91

151

3.8

COSE Messages

152
153
154
155
156

A COSE Message as defined in [RFC 8152] consists of a COSE Object along with other items specific to themessage type. Single and double layer messages are defined for encryption, signing, and the addition of a
Message Authentication Code (MAC). COSE Messages can be untagged (COSE_Untagged_Message) ortagged (COSE_Tagged_Message). A COSE_Tagged_Message is a COSE_Untagged_Message prepended
by the appropriate COSE tag.

157

3.9

158
159

A CBOR Web Token as defined in [RFC 8392] is a COSE Message, optionally prepended by the CWT tag.
Given the restrictions imposed by [RFC 8392], this means a CBOR Web Token can take one of three forms.

CBOR Web Token160• A COSE_Untagged_Message

161
162

• A COSE tag followed by a COSE_Untagged_Message (this can also be thought of as a
COSE_Tagged_Message)

163
164

• A CWT tag followed by a COSE tag followed by a COSE_Untagged_Message (this can also bethought of as a CWT tag followed by a COSE_Tagged_Message)

165

3.10

Entity Attestation Token

166
167
168

An Entity Attestation Token is a CBOR Web Token (as defined in [RFC 8392] and extended in [draft-ietf-ratseat] and this specification) that includes an encapsulated Claims Set, and is represented as a COSE Message.
A Token can include a signature or a MAC, and can be encrypted.

169

Rules for Entity Attestation Tokens are given in section 9.

170

3.11

171
172
173

A Signed Entity Attestation Token is an EAT which has at least one signature added, and contains suitable
information in the protected and unprotected headers (and in the signatures array when present) to enable thereceiver to verify the signature.

174
175

An untagged signed EAT contains a COSE_Sign or a COSE_Sign1 Message. A tagged signed EAT contains
a COSE_Sign_Tagged or a COSE_Sign1_Tagged message, and is optionally prefixed with the CWT tag.

176

Rules for constructing and interpreting signed Tokens are given in section 10.

177

3.12

178
179
180
181
182

An Encrypted Entity Attestation Token is an EAT in which the payload has been replaced by ciphertext, andwhich contains suitable information in the protected and unprotected headers (and in the recipients array whenpresent) to enable the receiver to decrypt the ciphertext. Some algorithms may rely on context information toderive key material. Context information can be known in advance by both parties, transferred as part of the
EAT, or a combination of both.

183
184
185

An untagged encrypted EAT contains a COSE_Encrypt or a COSE_Encrypt0 Message. A tagged encrypted
EAT contains a COSE_Encrypt_Tagged or a COSE_Encrypt0_Tagged message, and is optionally prefixedwith the CWT tag.

186

Rules for constructing and interpreting encrypted Tokens are given in section 11.

Signed EAT

Encrypted EAT

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 22 / 91

187

3.13

MACed EAT

188
189
190
191
192

A MACed Entity Attestation Token is an EAT which has an added MAC, and which contains suitable
information in the protected and unprotected headers (and in the recipients array when present) to enable thereceiver to authenticate the MAC. Some algorithms may rely on context information to derive key material.
Context information can be known in advance by both parties, transferred as part of the EAT, or a combinationof both.

193
194

An untagged MACed EAT contains a COSE_Mac or a COSE_Mac0 Message. A tagged MACed EAT contains
a COSE_Mac_Tagged or a COSE_Mac0_Tagged message, and is optionally prefixed with the CWT tag.

195

Rules for constructing and interpreting MACed Tokens are given in section 12.

196

3.14

197

Any Entity Attestation Token can be tagged with values that can help the recipient to identify its nature.

198
199
200

An untagged EAT takes the form of a COSE_Untagged_Message. This can be prepended with the appropriate
COSE tag value to become a tagged EAT, which takes the form of a COSE_Tagged_Message. For example,
a tagged unendorsed EAT would contain a COSE_Sign_Tagged Message.

201
202

A COSE_Tagged_Message can also be prepended with the CWT tag value. Note that [RFC 8152] forbids theuse of the CWT tag value with a COSE_Untagged_Message.

203

Rules for constructing and interpreting tagged Tokens are given in section 13.

204

3.15

205
206

An Entity Attestation Parcel can take the form of an Entity Attestation Token, an Unendorsed Claims Set, or a
Detached EAT Bundle.

207

3.16

CBOR and CDDL

208

3.16.1

Normative nature of CDDL definitions

209
210

CDDL [RFC 8610] is used to provide normative descriptions of Claims and other structures defined in thisdocument. Where the CDDL definition differs from the text description, the CDDL SHALL prevail.

211

3.16.2

212
213

CDDL [RFC 8610] defines a standard prelude. Definitions in this document assume the availability ofdefinitions in the CDDL prelude.

214

3.16.3215

Encoders SHOULD generate deterministically encoded CBOR as defined in [RFC 8949].

216

3.16.4217
218

Encoders MUST NOT generate invalid CBOR data items (as defined in [RFC 8949], section 5.3). Decoders
MUST reject an Entity Attestation Parcel containing invalid CBOR item(s).

219
220

With specific regard to UTF-8, decoders MUST consider as invalid any string containing invalid UTF-8 byte
sequences.

Tagged EAT

Entity Attestation Parcel

CDDL prelude

CBOR Deterministic Encoding

Validity of CBOR encoding

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 23 / 91

221
222

Decoders MUST ignore unknown CBOR items but SHOULD NOT reject an Entity Attestation Parcel containing
valid, but unknown CBOR items.

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 24 / 91

223

4

ENTITY ATTESTATION API

224

4.1

225
226

The Entity Attestation API consists of an Entity Attestation Protocol used to convey operational instructions toan Entity Attestation Service implementation via the TPS Client API.

227

Figure 4-1: Entity Attestation Overview

Overview

228
229
230
231
232
233

The Entity Attestation API provides means for TPS Clients (i.e. Applications or other TPS Services) tocommunicate with an Entity Attestation Service and utilize the functionalities it can provide. Entity Attestation
Protocol messages are conveyed between a TPS Client and an Entity Attestation Service using the TPS Client
API.

234
235
236
237

An Entity Attestation Service can be implemented on any entity which needs to be able to provide evidence of
its nature, status, or condition in order for a client to be able to assess its trustworthiness. In general, the moresecure the entity the higher the degree of confidence may be in assessing the evidence. This specification
does not limit the environments where an Entity Attestation Service can be implemented.

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 25 / 91

238

4.2

239

The following figure outlines the relationship between Entity Attestation related components.

240

Architecture
Figure 4-2: Entity Attestation Architecture

241
242
243
244
245
246

TPS Client API is the component used to establish a TPS Session between a TPS Client (an Application or
another TPS Service) and an Entity Attestation Service, and to exchange Entity Attestation Protocol messages
through the TPS Session. The TPS Session can be viewed as a connection or a channel between the TPS
Client and the Entity Attestation Service through which a set of attestation operations can be executed.

247
248
249
250
251
252
253
254

An Entity Attestation Service can be accessed using a Language Specific API. In this case, a TPS Client uses
the Language Specific API to use the attestation services provided by the Entity Attestation Service. The
functions and methods of the Language Specific API are mapped to the Entity Attestation Protocol by a binding.
The binding is responsible for converting function and method calls to Entity Attestation Protocol message
requests and sending them to the Entity Attestation Service using the TPS Client API. It is also responsible fordecoding the incoming Entity Attestation Protocol message response coming from the Entity Attestation
Service via the TPS Client API, and constructing the return parameters and values for function and method
calls of the Language Specific API.

255
256

A device may have more than one Entity Attestation Service available. The TPS Client or the binding is
responsible for discovering the required Entity Attestation Service.

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 26 / 91

257

4.3

Security

258
259
260
261
262
263
264
265

This specification does not impose any security requirements on an environment that implements an Entity
Attestation Service. Environments from tamper-resistant Secure Elements to Trusted Execution Environments
to Regular Operating Systems can implement an Entity Attestation Service. A given Entity Attestation Parcel
might contain nested parcels from different environments, potentially with very different security levels. The
environment does need to be a Root of Trust with respect to what is being attested. A Relying Party needs totake into account the nature of the environment that generated an Entity Attestation Parcel when assessing
the trustworthiness of the evidence contained within the claims. (Section 5.3 provides an example of how to
get information about the nature of the environment.)

266

4.4

267
268
269
270

Entity Attestation Protocol messages are CBOR encoded. A message from a client to a service is termed arequest, and a message from the service back to the client is termed a response. Each message takes theform of an Entity Attestation Parcel, with an additional tag that indicates the request or response code. The
structure of an Entity Attestation Parcel is described in detail in later sections.

271
272
273
274

This specification does not place any serialization restrictions on the CBOR used to form the Entity Attestation
Parcel, although because Entity Attestation Services may be implemented on resource-limited devices, it isrecommended that minimum sizes are used for values, and that indefinite lengths are avoided where possible.
Configuration documents can impose restrictions on the serialization to be used.

275

4.5

276
277
278
279
280

An Entity Attestation Session is a session between a TPS Client and an Entity Attestation Service. It is initiatedwhen the TPS Client opens a TPS Session with the Entity Attestation Service using the TPSC_SessionOpenfunction of the TPS Client API. It is destroyed when the TPS Session with the Entity Attestation Service isclosed either by the TPS Client using the TPSC_SessionClose function of the TPS Client API, or when the
TPS Communication Stack or TPS Client API determines that the TPS Client is no longer active.

281
282

When an Entity Attestation Session is closed to a TPS Client, any pending operations related to this TPS Client
are abandoned in the Entity Attestation Service.

283

4.6

284
285
286
287

An Entity Attestation Transaction is a combination of a request message and a response message which
achieves an Entity Attestation Operation. The request message is always sent first, and is only sent by a TPS
Client. The request message is always followed by a response message, which is only sent by the Entity
Attestation Service.

Message Encoding

Entity Attestation Session

Entity Attestation Transaction

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 27 / 91

288

4.7

Entity Attestation Messages

289
290

As with all TPS defined messaging, messages are tagged such that the lowest four digits are the message
number and higher digits indicate the specification number.

291
292
293
294
295
296

In this specification, message tags 60000 to 60999 are reserved. Message tags in the range 60000 to 60899
are for GlobalPlatform defined messages. Message tags in the range 60900 to 60999 can be used forproprietary extensions to the GlobalPlatform Entity Attestation Protocol. API users are expected to takeappropriate measures to ensure that proprietary extensions are used only when supported, and to be awarethat different implementations may have different interpretation of the meaning of a given tag. Proprietary
implementations SHALL NOT use any tag reserved to GlobalPlatform use.

297

4.7.1

298
299

The following table lists all parameters defined by this specification that can be present in Entity Attestation
Protocol messages.

300

Table 4-1: Entity Attestation Parameters and Assigned Values

Parameters

Name

Value

Description

parcel-1

Entity Attestation Parcel

status-30

Status of an operation

301
302

The “parcel” parameter contains an Entity Attestation Parcel.

303

The “status” parameter contains an integer value that indicates the result of the attempted operation.

304

Table 4-2: Status Values and Meanings
Name

Value

Description

SUCCESS0

The operation requested in the corresponding request was
successful.

IO_ERROR-1

The operation failed due to an unspecified I/O error.

INVALID_ARGUMENT-3

One or more arguments in the request are invalid.

GENERAL_FAILURE-254

The Entity Attestation Service has suffered a general failure.

305

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 28 / 91

306

4.7.2

307

Description

308

Informs the Entity Attestation Service that it is to perform an attestation operation.

309

Request

310
311
312
313

TPSEAP_AttestRequest = #6.60000 ({-1 => parcel})
Request Parameters

314
315
316

• parcel: The request Entity Attestation Parcel which can be used to provide information to the Entity
Attestation Service about evidence it should include in the response
Response

317
318
319
320
321

TPSEAP_Attest

TPSEAP_AttestResponse = #6.60001 ({-1 => parcel,-30 => status})
Response Parameters322• parcel: The response Entity Attestation Parcel which can contain evidence323• status: Indication of whether the requested operation was successful

324

Implementation Notes

325
326
327

The status field is used to indicate problems with a request itself, for example that the Entity Attestation Parcel
in the request is invalid. When the status is anything other than SUCCESS, the Relying Party cannot rely on
any information provided in the parcel parameter.

328
329
330

Responses with status SUCCESS can still include information about problems with parts of the request in thevalues it returns in the parcel parameter. For example, requested claims that are unrecognized might beomitted from the response.

331.

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 29 / 91

332

5

OPERATIONS

333
334
335
336

An Operation is a defined mechanism by which an Entity Attestation Client can obtain attestation informationfrom an Entity Attestation Service. An Operation takes the form of challenge and response. Formally, because
an EAP is constructed, transported, and processed in each direction, an Operation is comprised of a Remote
Attestation from Client to Service, followed by a Remote Attestation from Service to Client.

337
338

For brevity, the term “empty EAP” is used to mean an EAP with an empty Claims Set. Note that it might still
be signed, encrypted, or MACed.

339

5.1

340

Every Operation consists of the following steps:

Outline of Parcel Exchange Operations

341• An Entity Attestation Client creates a Request EAP and sends it to an Entity Attestation Service.

342
343

• The Entity Attestation Service parses the Request EAP, constructs a Response EAP, and returns it to
the Entity Attestation Client.

344
345
346

If an Operation takes place in a secure channel, it might be that no further cryptographic protection is neededon the EAPs being exchanged, although of course it is still possible to sign, encrypt, or MAC Parcels even ina secure channel.

347
348

It is possible to proceed with a more complex attestation procedure in a series of individual steps, for example
sending a request for a default Parcel, followed by one or more requests for additional information.

349
350
351

Note that there might be devices which are only capable of returning a fixed Response EAP. However, topromote interoperability for a specific use case, configuration documents could be created that impose
requirements for the support of certain Operations.

352

5.2

353

The Relying Party performs the following steps to construct a Request EAP.

Parcel Exchange354• Construct a request Claims Set (which can be empty).

355• Perform one of the following steps to create a Request Entity Attestation Parcel:356

o Add a tag to the Claims Set to create a Request Unendorsed Claims Set

357
358

o Sign, encrypt, or MAC the Claims Set, and optionally add a tag to create a Request Entity
Attestation Token

359

The Request EAP is sent to the Entity Attestation Service.

360

On receipt of a Request EAP, the EAS performs the following steps to construct a Response EAP:

361
362
363
364
365
366
367

• Check the tag values if present.
o If a tag value is not recognized, return an empty EAP with a suitable error code.
o Otherwise, interpret the content following the tags according to whether it represents an Entity
Attestation Token or an Unendorsed Claims Set.
• If the content is an Entity Attestation Token:
o If the EAT is MACed, attempt to authenticate the Message Authentication Code, and return anempty EAP with a suitable error code if unable to successfully authenticate the Request EAT.

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 30 / 91

368
369

o If the EAT is encrypted, attempt to decrypt it, and return an empty EAP with a suitable error code if
unable to successfully decrypt the Request EAT or interpret the plaintext.

370
371

o If the EAT is signed, attempt to verify all signatures present, and return an empty EAP with asuitable error code if unable to successfully verify the Request EAT.

372

• If the content is an Unendorsed Claims Set:

373

o No cryptographic operations are necessary.

374• Parse the request Claims Set.

375

• Retrieve a suitable Response EAP if available.

376
377

• Otherwise construct a Response EAP containing a response Claims Set which may consider
information in the request Claims Set (especially for Claims that have privacy implications).

378• Optionally sign and/or encrypt and/or MAC the Response EAP.

379

• Optionally tag the (optionally signed, optionally encrypted, optionally MACed) Response EAP.

380

The Response EAP is returned to the Relying Party.

381

5.3

382
383
384
385
386

In some cases, such as where it is known that the Response EAP is fixed, there is no need for the Request
EAP to contain additional information. However, there are cases where the Relying Party provides parametersthat influence the construction of the Claims Set in the Response EAP. Claims sent in the Request EAP havespecific meanings, defined below. Any other Claim in the Request EAP SHOULD be ignored by the Entity
Attestation Service.

387

5.3.1

388
389
390

A Nonce Claim included in the Request EAP SHALL include one or more octets. The length and value of theoctets is outside the scope of this specification. The Response EAP SHALL contain a Nonce Claim that
includes the same length and value of octets in the Request EAP.

391
392

This can be used to ensure freshness, in that the Response EAP was generated in response to the Request
EAP.

393

5.3.2

394
395
396

A Context Claim included in the Request EAP SHALL include one or more octets. The length, meaning, andvalue of the octets is outside the scope of this specification. The Response EAP SHALL contain a Context
Claim that includes the same length and value of octets in the Request EAP.

397
398

This can be used to provide a reference for the Entity Attestation Service that allows it to understand what ismaking the attestation request, and also to assist the Relying Party in linking a Request / Response EAP pair.

399

5.3.3

400
401
402

A Justification Claim included in the Request EAP SHALL include a CBOR Byte String. The length, meaningand value of the octets is outside the scope of this specification. The Response EAP SHOULD not contain a
Justification Claim.

403
404
405

This can be used to provide information to the Entity Attestation Service about the reason why the Relying
Party is entitled to receive some or all the evidence in the Response EAP. For example, it could include proofof possession of a secret value known only to the two parties involved in the Operation.

Request EAP Claims

Nonce Request Claim

Context Request Claim

Justification Request Claim

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 31 / 91

406

5.3.4

407
408
409
410

An Important Claim included in the Request EAP SHALL include an array containing one or more Claim
Prompts. Each element in the array represents a hint to the Entity Attestation Service about specific Claims
which the Relying Party wants to see returned. The Entity Attestation Service SHOULD include the claims
matching these hints when constructing the Response EAP.

411
412
413
414
415

For various reasons, such as privacy concerns, or uncertainty about the source of the Request EAP, the EAS
MAY choose not to include the Claim, or MAY choose to include the Claim without the evidence. If the Relying
Party is not provided with evidence it identified as important it might lower its assessment of trustworthiness.
However, it could also attempt to retrieve the information another way, for example by sending a further
Request EAP with a Claims Set that includes a suitable Justification Claim.

416

5.3.5

417
418
419
420

An Unnecessary Claim included in the Request EAP SHALL include an array containing one or more Claim
Prompts. Each element in the array represents a hint to the Entity Attestation Service about specific Claims
which the Relying Party does not need to see returned. The Entity Attestation Service SHOULD NOT include
the claims matching these hints when constructing the Response EAP.

421
422

For various reasons, the EAS MAY choose to include the Claim including its evidence, but the Relying Party
might not use this evidence in its assessment of trustworthiness.

Important Request Claim

Unnecessary Request Claim

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 32 / 91

423

6

424
425

This specification defines all Claims defined by GlobalPlatform, but imposes no requirements on which Claims
need to be supported in any given system.

426
427

Certain Claims are identified as “Subclaims”. A Subclaim has an identical format to other Claims, but has adefined meaning only when included in the value field of the parent Claim.

428
429

Unless restricted by other documents, any claim can be included in any type of Entity Attestation Parcel,
including both an Unendorsed Claims Set and an Entity Attestation Token.

430

6.1

Data Types

431

6.1.1

Binary Coded Decimal

432
433
434
435

A Binary Coded Decimal is a number encapsulated in the smallest possible CBOR Byte String (as discussed
in [RFC 8949]) using a BCD format where each digit of the integer is encoded in four bits, with these bits taking
values from 0 to 9, from the most significant digit to the least. A single decimal point MAY be encoded in agiven number using the decimal value 15. It is an error if the value 15 occurs more than once.

436
437
438

A number containing an odd number of digits (or an even number with a decimal point) SHALL be left justified
in the CBOR Byte String, with the most significant digit set to zero. While this encoding is less efficient thansome numeric codings, the loss of efficiency may be acceptable for certain types of value.

439
440

Examples: 1234567 has the CBOR encoding 4401234567, and 123.4567 has the CBOR encoding
44123F4567.

441

CLAIMS

gp_bcd_type = bstr

442

6.1.2

443

UUIDs [RFC 4122] are often used as identifiers that are expected to be unique within a given Entity.

444

UUIDs are encoded as CBOR Byte Strings with a fixed length constraint.

445

UUID

uuid = bstr .size 16

446

6.1.3

447
448
449

A Claim Prompt is a data type that can reference any Claim Identifier or Subclaim Identifier, whether at thecurrent level of a Claims Set or at a lower level of hierarchy. It is used to provide hints to the Entity Attestation
Service about what particular evidence a Relying Party considers important when evaluating trustworthiness.

450

A Claim Prompt takes one of the following forms:

Claim Prompt451• Simple452• Subclaims

453• Hierarchical

454
455
456
457

gp_claim_prompt_type =gp_simple_claim_prompt_type /gp_subclaim_claim_prompt_type /gp_hierarchical_claim_prompt_type

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 33 / 91458

6.1.3.1

459
460

To prompt for a simple Claim at the current level of hierarchy, the Claim Identifier is included as a CBOR
Unsigned Integer.

461

Simple Claim Prompt

gp_simple_claim_prompt_type = uint462

6.1.3.2

463
464
465

To prompt for Subclaims within a Claim at the current level of hierarchy, a CBOR Array with two entries isused. The first entry is a CBOR Unsigned Integer with the value of the Claim Identifier, and the second entry
is a nested CBOR Array with zero or more entries.

466
467

Each entry in the nested array is a CBOR Unsigned Integer with the value of the Subclaim identifier. An empty
array of Subclaim identifiers SHOULD be interpreted to mean a prompt for all Subclaims.

468

Subclaim Claim Prompt

gp_subclaim_claim_prompt_type = [ uint, [ * uint ] ]469

6.1.3.3

470
471
472

To prompt for Claims at a lower level of hierarchy, a CBOR Map with a single map pair is used. The map key
is a CBOR Unsigned Integer with the value of the Claim Identifier, and the map value is a nested CBOR Map
with one or more map pairs.

473
474
475
476

Each map key in the nested map is an identifier for the hierarchical item. The format of the identifier depends
on the Claim Identifier. If the Claim Identifier is “submods” as defined in [draft-ietf-rats-eat], the identifier is a
CBOR Text String. Other Claim Identifiers can use a CBOR Unsigned Integer, a CBOR Byte String, or a CBOR
Text String.

477
478
479

Each map value in the nested map is a CBOR Array with one or more elements, each of which is a Claim
Prompt. In general, it is unlikely that Hierarchical Claim Prompts will be nested, and configurations mightchoose to disallow this. However, Simple and Subclaim Claim Prompts can normally be freely used.

480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498

Hierarchical Claim Prompt

gp_hierarchical_claim_prompt_type = {uint => {+ gp_hierarchical_claim_identifier_prompt_type => [+ gp_claim_prompt_type]}}
gp_hierarchical_claim_identifier_prompt_type = uint / bstr / tstr
Examples:• A prompt for the debug status Claim is 263, with the CBOR encoding:

190107.
• A prompt for the latitude and longitude Subclaims in the location Claim is [ 264 , [ 1 , 2 ] ],with the CBOR encoding:82190108820102.
• A prompt for the hardware version and location Claims in a submodule “board” is{ 266: { "board" : [ 260 , [ 264 , [ 1 , 2 ] ] ] } }, with the CBOR encoding:a119010aa165626f6172648219010482190108820102.
Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 34 / 91

499
500
501
502

• A prompt for the lifecycle state and version Subclaims of a TEE Trusted Application with the identifier
24eba45dc1bb43a49d831221677ab639 is{ 70500: { h'24eba45dc1bb43a49d831221677ab639' : [ 70501 , 70502 ] } }, with the
CBOR encoding:

503
504
505

a11a00011364a15024eba45dc1bb43a49d831221677ab639821a000113651a00011366.
• A prompt for the options and SCP03 keys of an SE Secure Channel Protocol ‘03’ is{ 80400: { 3 : [ 80401 , 80402 ] } } with the CBOR encoding:506

a11a00013a10a103821a00013a111a00013a12.

507

6.1.4

508
509

The Security Rating type encodes information about how secure the Entity is. It is an integer value that takes
one of the values defined by the GlobalPlatform Security Task Force:

510
511
512
513
514
515
516
517
518
519
520
521
522

•
•
•
•

Security Rating

0: Unknown
5: Basic
10: Substantial
15: High

The value Unknown can be used if a value is not relevant in a given context. The Claim Value SHALL be
represented as a CBOR Unsigned Integer containing one of the values defined above. All other values arereserved for future use.
gp_security_rating_type = &(unknown: 0,
basic: 5,
substantial: 10,
high: 15
)

523

6.1.5

524

SE Secure Element Type type defines the form factor of the Secure Element implementation.

525

It is an integer encoding that takes one of the values:

526
527
528
529
530
531
532
533

SE Secure Element Type• 0: SE• 5: eSE• 10: iSE
All other values are reserved.
gp_se_secure_element_type_type = &(se : 0,ese : 5,
ise : 10

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 35 / 91

534

6.1.6

535

The SE Card Lifecycle State type encodes the lifecycle state of the Secure Element.

536

It is an integer encoding that takes one of the values:

537
538
539
540
541
542
543
544
545
546
547
548
549

•
•
•
•
•

SE Card Lifecycle State Type

0: OP_READY
5: INITIALIZED
10: SECURED
15: CARD_LOCKED
20: TERMINATED

All other values are reserved for future use.
gp_se_card_lifecycle_state_type = &(op_ready: 0,
initialized: 5,
secured: 10,
card_locked: 15,
terminated: 20
)

550

6.1.7

551
552

The SE Supplementary Security Domains Type allows the Supplementary Security Domains installed on the
Secure Element to be encoded.

553
554
555
556

It is defined as a CBOR Map with zero or more entries. Each map pair SHALL consist of a map key that
represents the Supplementary Security Domain ID in the form of a CBOR Byte String, and a map value that
represents the Supplementary Security Domain parameters in the form of a CBOR Map with zero or more
entries, each of which is one of the identified SE SSD Subclaims.

557
558
559
560
561
562
563
564
565
566
567
568

SE Supplementary Security Domain Type

gp_se_supplementary_security_domains_type = {* gp_se_supplementary_security_domain_id => { * $$GP-SSD-Claims }}$$GP-SSD-Claims //= ( &( issuer_number: 1 ) => gp_bcd_type )$$GP-SSD-Claims //= ( &( image_number: 2 ) => bstr )$$GP-SSD-Claims //= ( &( key_derivation_data: 3 ) => bstr )$$GP-SSD-Claims //= ( &( key_information_data: 4 ) => bstr )$$GP-SSD-Claims //= ( &( default_kvn: 5 ) => uint )$$GP-SSD-Claims //= ( &( default_kvn_sequence_ctr: 6 ) => bstr )gp_se_supplementary_security_domain_id = bstr569

6.1.7.1

570
571
572

The SE Supplementary Security Domain Issuer Number (SIN) Subclaim uniquely identifies the SSD Issuer
according to ISO/IEC 7812-1 [ISO 7812-1]. The SIN is of variable length in general, but as used by
GlobalPlatform it is limited to either three or four digits.

573
574

The Subclaim value SHALL be represented as a CBOR Byte String containing the octets comprising the SIN,
in the Binary Coded Decimal form defined in section 6.1.1.

issuer_number

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 36 / 91575

6.1.7.2

576
577
578

The SE Supplementary Security Domain Image Number (SDIN) Subclaim uniquely identifies an SSD createdby a given SSD Issuer. The pair (SIN, SDIN) form a unique identifier for a given SSD. The SDIN is of variable
length.

579

The Subclaim value SHALL be represented as a CBOR Byte String containing the octets comprising the SDIN.

580

6.1.7.3

581
582

The SE Supplementary Security Domain Key Derivation Data Subclaim contains key derivation data for the
Security Domain.

583

The Subclaim Value SHALL be represented as a CBOR Byte String containing the key derivation data.

584

6.1.7.4

585
586

The SE Supplementary Security Domain Key Information Data Subclaim contains key information data for the
Security Domain.

587

The Subclaim Value SHALL be represented as a CBOR Byte String containing the key information data.

588

6.1.7.5

589
590

The SE Supplementary Security Domain Default KVN Subclaim contains the default KVN in the Security
Domain.

591

The Subclaim Value SHALL be represented as a CBOR Unsigned Integer containing the default KVN.

592

6.1.7.6

593
594

The SE Supplementary Security Domain Default KVN Sequence Counter Subclaim contains the sequence
counter for the default KVN in the Security Domain.

595
596

The Subclaim Value SHALL be represented as a CBOR Byte String containing the default KVN sequence
counter.

597

6.1.8

598
599

The TEE Lifecycle State Type gives an indication of the lifecycle state of the TEE (as defined by [TMF]
Tee::state).

600

It uses an integer encoding that takes one of the values:

601
602
603
604
605
606
607

image_number

key_derivation_data

key_information_data

default_kvn

default_kvn_sequence_ctr

TEE Lifecycle State Type• 0: TEE_LOCKED• 1: TEE_SECURED
All other values are reserved for future use.
gp_tee_lifecycle_state_type = &(tee_locked: 0,
tee_secured: 1)

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 37 / 91

608

6.1.9

609
610

The TEE Trusted OS Architectures Type defines how to encode details of instruction sets and architectures
which can be used by Trusted Applications running in the TEE.

611
612
613
614

It represents data as a CBOR Map with zero or more entries. Each map pair ([TMF] ISA) SHALL consist of amap key that represents the Instruction Set Architecture Name in the form of a CBOR Text String, and a map
value that represents the TEE Trusted OS Architecture parameters in the form of a CBOR Map with zero or
more entries, each of which is one of the identified TEE Trusted OS ISA Subclaims.

615
616
617
618
619
620
621
622
623
624

TEE Trusted OS Architectures Type

gp_tee_trusted_os_architectures_type = {* &(arch_name: tstr) => {? &( isa_processor_type: 0) => tstr,? &( isa_instruction_set: 1) => tstr,? &( isa_address_size: 2) => uint,? &( isa_abi_information: 3) => uint,? &( isa_endianness: 4) => gp_endianness_type}}
Note: Endianness is encoded using Endianness, defined in section 38.

625

6.1.9.1

626

The ISA Processor Type Subclaim indicates the type of the processor ([TMF] ISA::processorType).

627

The Subclaim Value SHALL be represented as a CBOR Text String containing the processor type.

628

6.1.9.2

629

The ISA Instruction Set Subclaim specifies the instruction set as a string ([TMF] ISA::instructionSet).

630

The Subclaim Value SHALL be represented as a CBOR Text String containing the instruction set description.

631

6.1.9.3

632

The ISA Address Size defines the size of addresses in bits ([TMF] ISA::addressSize).

633

The Subclaim Value SHALL be represented as a CBOR Unsigned Integer containing the address size in bits.

634

6.1.9.4

635

The SA Application Binary Interface Information Claim specifies the ABI that is in use ([TMF] ISA::abi).

636

The Subclaim Value SHALL be represented as a CBOR Text String containing information about the ABI.

isa_processor_type

isa_instruction_set

isa_address_Size

isa_abi_information

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 38 / 91637

6.1.10638
639

The Endianness Type specifies how values greater than 1 byte in length are stored ([TMF]
ISA::endianness).

640

It is an integer encoding that takes one of the values:

isa_endianness

641
642
643

• 0: Little Endian• 1: Big Endian• 2..127: Reserved

644• 128..255: Implementation dependent

645
646
647
648
649

gp_endianness_type = &(little_endian: 0,
big_endian: 1,
other_endian: 2..255)

650

6.1.11651

The Options Type allows list of options, in the form of pairs of (name, integer), to be encoded.

652
653

Options SHALL be encoded on a CBOR Map with zero or more entries, each of which SHALL be a CBOR
Text String containing the name (key) and a CBOR Unsigned Integer containing the version (value).

654
655
656

TEE Options Type

gp_tee_options_type = {* tstr => uint}

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 39 / 91657

6.1.12658
659

The TEE Implementation Properties Type allows TEE properties to be encoded. There is a set of defined keys
for standardized properties and the ability to encode implementation-defined properties.

660
661
662

TEE Implementation Properties SHALL be represented as a CBOR Map with zero or more entries. Each entry
is identified by an integer key. Unused positive integer values are reserved for future versions of thisspecification. Negative keys can be used for implementation-specific properties.

663
664
665

Note: The key values given below are informative only. The normative source for TEE property identifier
keys is [TEE Core], section 4.7, and keys defined therein MUST be used in the event of conflict with thisspecification.

666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710

TEE Implementation Properties Type

gp_tee_implementation_properties_type = {? &( gpd_tee_apiversion: 0 ) => tstr,? &( gpd_tee_internalCore_version: 1 ) => int,
? &( gpd_tee_description: 2 ) => tstr,? &( gpd_tee_deviceID: 3 ) => uuid,? &( gpd_tee_name: 4 ) => tstr,? &( gpd_tee_implementationstackhash: 5 ) => bstr,? &( gpd_tee_implementationstack: 6 ) => bstr .cbor
gp_tee_globalplatform_component,? &( gpd_tee_systemTime_protectionLevel: 7 ) => int,
? &( gpd_tee_TAPersistentTime_protectionLevel: 8 ) => int,
? &( gpd_tee_arith_maxBigIntSize: 9 ) => int,
? &( gpd_tee_cryptography_ecc: 10 ) => bool,? &( gpd_tee_cryptography_nist: 11 ) => bool,? &( gpd_tee_cryptography_bsi_r: 12 ) => bool,? &( gpd_tee_cryptography_bsi_t: 13 ) => bool,? &( gpd_tee_cryptography_ietf: 14 ) => bool,? &( gpd_tee_cryptography_octa: 15 ) => bool,? &( gpd_tee_cryptography_sec: 16 ) => bool,? &( gpd_tee_cryptography_NISTpqc_crystals: 17 ) => bool,? &( gpd_tee_cryptography_NISTpqc_SLHDSA: 19 ) => bool,? &( gpd_tee_cryptography_statefulverification: 20 ) => bool,? &( gpd_tee_cryptography_statefulsignatures: 21 ) => bool,? &( gpd_tee_cryptography_FrodoKEM: 22 ) => bool,? &( gpd_tee_cryptography_NTRU: 23 ) => bool,? &( gpd_tee_cryptography_maxretaineddata: 25 ) => int,
? &( gpd_tee_trustedStorage_private_rollbackProtection: 26 ) => int,
? &( gpd_tee_trustedStorage_perso_rollbackProtection: 27 ) => int,
? &( gpd_tee_trustedStorage_protected_rollbackProtection: 28 ) => int,
? &( gpd_tee_trustedStorage_antiRollback_protectionLevel: 29 ) => int,
? &( gpd_tee_trustedStorage_rollbackDetection_protectionLevel: 30 ) =>int,
? &( gpd_tee_trustedos_implementation_version: 31 ) => tstr,? &( gpd_tee_trustedos_implementation_binaryversion: 32 ) => bstr,? &( gpd_tee_trustedos_manufacturer: 33 ) => tstr,? &( gpd_tee_firmware_implementation_version: 34 ) => tstr,? &( gpd_tee_firmware_implementation_binaryversion: 35 ) => bstr,? &( gpd_tee_firmware_manufacturer: 36 ) => tstr,? &( gpd_tee_event_maxSources: 37 ) => int,
? &( gpd_tee_maskState: 38 ) => bool,* uint .gt 38 => any,
* nint => gp_tee_properties_value}

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 40 / 91

711

References to property definitions below:712• gpd_tee_apiversion: defined as gpd.tee.apiversion in [TEE Core] section 4.7.

713
714

• gpd_tee_internalCore_version: defined as gpd.tee.internalCore.version in [TEE Core]section 4.7.

715

• gpd_tee_description: defined as gpd.tee.description in [TEE Core] section 4.7.

716

• gpd_tee_deviceID: defined as gpd.tee.deviceID in [TEE Core] section 4.7.

717

• gpd_tee_name: defined as gpd.tee.name in [TEE Core] section 4.7.

718
719

• gpd_tee_implementationstackhash: defined as gpd.tee.implementationstackhash in [TEECore] section 4.7.

720
721

• gpd_tee_implementationstack: defined as gpd.tee.implementationstack in [TEE Core]section 4.7.

722
723

• gpd_tee_systemTime_protectionLevel: defined as gpd.tee.systemTime.protectionLevelin [TEE Core] section 4.7.

724
725

• gpd_tee_TAPersistentTime_protectionLevel: defined as
gpd.tee.TAPersistentTime.protectionLevel in [TEE Core] section 4.7.

726
727

• gpd_tee_arith_maxBigIntSize: defined as gpd.tee.arith.maxBigIntSize in [TEE Core]section 4.7.

728

• gpd_tee_cryptography_ecc: defined as gpd.tee.cryptography.ecc in [TEE Core] section 4.7.

729
730

• gpd_tee_cryptography_nist: defined as gpd.tee.cryptography.nist in [TEE Core]section 4.7.

731
732

• gpd_tee_cryptography_bsi_r: defined as gpd.tee.cryptography.bsi-r in [TEE Core]section 4.7.

733
734

• gpd_tee_cryptography_bsi_t: defined as gpd.tee.cryptography.bsi_t in [TEE Core]section 4.7.

735
736

• gpd_tee_cryptography_ietf: defined as gpd.tee.cryptography.ietf in [TEE Core]section 4.7.

737
738

• gpd_tee_cryptography_octa: defined as gpd.tee.cryptography.octa in [TEE Core]section 4.7.

739

• gpd_tee_cryptography_sec: defined as gpd.tee.cryptography.sec in [TEE Core] section 4.7.

740
741

• gpd_tee_cryptography_NISTpqc_crystals: defined as
gpd.tee.cryptography.NISTpqc.crystals in [TEE Core] section 4.7.

742
743

• gpd_tee_cryptography_NISTpqc_SLHDSA: defined as
gpd.tee.cryptography.NISTpqc.SLHDSA in [TEE Core] section 4.7.

744
745

• gpd_tee_cryptography_statefulverification: defined as
gpd.tee.cryptography.statefulverification in [TEE Core] section 4.7.

746
747

• gpd_tee_cryptography_statefulsignatures: defined as
gpd.tee.cryptography.statefulsignatures in [TEE Core] section 4.7.

748
749

• gpd_tee_cryptography_FrodoKEM: defined as gpd.tee.cryptography.FrodoKEM in [TEE Core]section 4.7.

750
751

• gpd_tee_cryptography_NTRU: defined as gpd.tee.cryptography.NTRU in [TEE Core]section 4.7.
Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 41 / 91

752
753

• gpd_tee_cryptography_maxretaineddata: defined as
gpd.tee.cryptography.maxretaineddata in [TEE Core] section 4.7.

754
755

• gpd_tee_trustedStorage_private_rollbackProtection: defined as
gpd.tee.trustedStorage.private.rollbackProtection in [TEE Core] section 4.7.

756
757

• gpd_tee_trustedStorage_perso_rollbackProtection: defined as
gpd.tee.trustedStorage.perso.rollbackProtection in [TEE Core] section 4.7.

758
759

• gpd_tee_trustedStorage_protected_rollbackProtection: defined as
gpd.tee.trustedStorage.protected.rollbackProtection in [TEE Core] section 4.7.

760
761

• gpd_tee_trustedStorage_antiRollback_protectionLevel: defined as
gpd.tee.trustedStorage.antiRollback.protectionLevel in [TEE Core] section 4.7.

762
763

• gpd_tee_trustedStorage_rollbackDetection_protectionLevel: defined as
gpd.tee.trustedStorage.rollbackProtection.protectionLevel in [TEE Core] section 4.7.

764
765

• gpd_tee_trustedos_implementation_version: defined as
gpd.tee.trustedos.implementation.version in [TEE Core] section 4.7.

766
767

• gpd_tee_trustedos_implementation_binaryversion: defined as
gpd.tee.trustedos.implementation.binaryversion in [TEE Core] section 4.7.

768
769

• gpd_tee_trustedos_manufacturer: defined as gpd.tee.trustedos.manufacturer in [TEECore] section 4.7.

770
771

• gpd_tee_firmware_implementation_version: defined as
gpd.tee.firmware.implementation.version in [TEE Core] section 4.7.

772
773

• gpd_tee_firmware_implementation_binaryversion: defined as
gpd.tee.firmware.implementation.binaryversion in [TEE Core] section 4.7.

774
775

• gpd_tee_firmware_manufacturer: defined as gpd.tee.firmware.manufacturer in [TEE Core]section 4.7.

776

• gpd_tee_event_maxsources: defined as gpd.tee.event.maxSources in [TEE Core] section 4.7.

777

• gpd_tee_maskState: defined as gpd.tee.maskState in [TEE Core] section 4.7.

778
779

Implementation-defined properties can be represented using the TEE Properties Value type defined in
section 6.1.13.

780

6.1.13781
782

TEE Properties Value Type allows implementation-specific properties to be encoded. [TEE Core] section 4.4
provides normative information on property encoding.

783
784
785
786
787

TEE Properties Value Type

gp_tee_properties_value = (bool/ uint/ tstr/ bstr
/ gp_tee_identity)

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 42 / 91788

6.1.14789
790

TEE Identity Type allows a TEE_Identity to be encoded. [TEE Core], sections 4.1.1 and 4.4 provide
normative information on TEE_Identity.

791
792
793
794
795

TEE Identity Type

gp_tee_identity = {&( loginMethod: 0 ) => uint,&( uuid: 1 ) => uuid}796

6.1.15797

TEE Trusted Applications Type allows information about Trusted Applications hosted by a TEE to be encoded.

798
799
800
801

It is defined as a CBOR Map with zero of more entries. Each map pair ([TMF] TrustedApplication) SHALL
consist of a map key that represents the Trusted Application ID in the form of a CBOR Byte String, and a map
value that represents the Trusted Application parameters in the form of a CBOR Map with zero or more entries,
each of which is one of the identified TEE TA Subclaims.

802
803
804
805
806
807
808
809
810
811
812

TEE Trusted Applications Type

gp_tee_trusted_applications_type = { * &(application_)id: bstr) => {? &( parent: 0)=> uuid,? &( lifecycle_state: 1 ) => gp_tee_ta_lifecycle_state_type,? &( version: 2 )=> tstr,? &( measurement: 3 )=> bstr,? &( description: 4 )=> tstr,? &( properties: 5 )=> { * tstr => gp_tee_properties_value },? &( extra_data: 6 )=> bstr}}813

6.1.15.1

814
815

The parent Subclaim provides
TrustedApplication::parent).

816
817

The Subclaim Value SHALL be represented as a CBOR Byte String containing the UUID of the parent Security
Domain.

818

6.1.15.2

819

The lifecycle_state Subclaim is encoded as defined in section 6.1.16.

820

6.1.15.3

821
822

The
versionSubclaim
providesTrustedApplication::version).

823
824

The Subclaim Value SHALL be represented as a CBOR Text String containing the version of the Trusted
Application.

parent
the

UUID

of

the

parentSecurity

Domain([TMF]

lifecycle_stateversiontheversionCopyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

of

the

TrustedApplication([TMF]

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 43 / 91825

6.1.15.4

826

The measurement Subclaim provides a measurement for the TA.

827
828
829

measurement

Note: This specification leaves the mechanism used to generate a measurement to the implementation.
Examples of possible measurements include but are not limited to: hash of the TA binary; DICE-based
chained measurement value.

830

6.1.15.5831
832

The description Subclaim provides an informative text description of the TA. The format of the contents ofthis description are defined by the TA implementation and outside of the scope of this specification.

833

6.1.15.6

834
835
836

The properties Subclaim allows TA properties to be encoded using a CBOR Map where the keys are property
names (as CBOR String types) and the values are encoded using the TEE Properties Value Type (section
6.1.13).

837

6.1.15.7

838
839

The extra_data Subclaim allows implementation-specific information about a TA to be encoded as a CBOR
bstr. This specification does not further specify the format of the contents of the bstr.

840

6.1.16841
842

The TEE Trusted Application Lifecycle State Type encodes the lifecycle state of the Trusted Application ([TMF]
TrustedApplication::lifecycleState).

843

It is an integer encoding that takes one of the values:

844
845
846
847
848
849
850
851
852

description

properties

extra_data

TEE Trusted Application Lifecycle State Type• 0: taInactiveState• 1: taExecutableState• 2: taLockedStateAll other values are reserved for future use.
gp_tee_ta_lifecycle_state_type = &(ta_inactive: 0,ta_executable : 1,
ta_locked : 2)

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 44 / 91853

6.1.17854

The TEE Security Domains Type encodes the set of Security Domains present in the TEE.

855
856
857
858

The Security Domain set SHALL be represented as a CBOR Map with zero or more entries. Each map pair([TMF] SecurityDomain) SHALL consist of a map key that represents the Security Domain ID in the form of
a CBOR Byte String, and a map value that represents the Security Domain parameters in the form of a CBOR
Map with zero or more entries, each of which is one of the identified TEE SD Subclaims.

859
860
861
862
863
864
865
866
867
868
869

TEE Security Domains Type

gp_tee_security_domains_type = {* gp_tee_security_domain_id => {? &( sd_parent: 0 )=> uuid,? &( sd_lifecycle_state: 1 ) => gp_tee_sd_lifecycle_state_type,? &( sd_authority: 2 )=> gp_tee_sd_authority_type,? &( sd_privileges: 3 )=> gp_tee_sd_privileges_type,? &( sd_protocols: 4 )=> gp_tee_sd_protocols_type}}
gp_tee_security_domain_id = bstr

870

6.1.17.1

871
872

The TEE Security Domain Parent Subclaim provides the UUID of the parent Security Domain ([TMF]
SecurityDomain::parent) if applicable.

873

The Subclaim Value SHALL be represented as a uuid type encoding the UUID of the parent Security Domain.

874

6.1.17.2

875
876

The TEE Security Domain Lifecycle State Subclaim provides the lifecycle state of the Security Domain ([TMF]
SecurityDomain::lifecycleState).

877

The Subclaim Value SHALL be represented as a TEE Security Domain Lifecycle State Type (section 6.1.18)

878

6.1.17.3

879
880

The TEE Security Domain Authority Subclaim provides additional information about the Authority that manages
the Security Domain ([TMF] SecurityDomain::authority).

881

The Subclaim Value SHALL be represented TEE Security Domain Authority Type (section 6.1.19).

882

6.1.17.4

883
884

The TEE Security Domain Privileges Subclaim contains the privileges of the Security Domain ([TMF]
SecurityDomain::privileges).

885

The Subclaim SHALL be encoded using a TEE Security Domain Privileges Type (section 6.1.20).

886

6.1.17.5

887
888

The TEE Security Domain ID Subclaim contains a list of protocols supported by the Security Domain related
to the Security Layer implementation ([TMF] SecurityDomain::protocols).

889

The Subclaim SHALL be encoded using a TEE Security Domain Protocols Type (section 6.1.21).

sd_parent

sd_lifecycle_statesd_authority

sd_privileges

sd_protocols

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 45 / 91890

6.1.18891
892

The TEE Security Domain Lifecycle State Type encodes the lifecycle state of the Security Domain ([TMF]
SecurityDomain::lifecycleState).

893

It is a CBOR integer that takes one of the values:

894
895
896
897
898
899
900
901
902

TEE Security Domain Lifecycle State Type• 0: sdBlockedState• 1: sdActiveState• 2: sdRestrictedStateAll other values are reserved for future use.
gp_tee_sd_lifecycle_state_type = &(sd_blocked: 0,
sd_active: 1,
sd_restricted: 2)903

6.1.19904
905

The TEE Security Domain Authority Type encodes additional information about the Authority that manages
the Security Domain ([TMF] SecurityDomain::authority).

906

It is a CBOR Map containing either one or two entries.

TEE Security Domain Authority Type

907
908

• The first entry SHALL have a key of 1 and a value of type CBOR Text String containing the Authority
name.

909
910

• If present, the second entry SHALL have a key of 2 and a value of type CBOR Text String containing a
URL for the Authority.

911
912
913
914

gp_tee_sd_authority_type = {&( name: 0 )=> tstr,? &( urlInfo: 1 ) => tstr}

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 46 / 91915

6.1.20916
917

The TEE Security Domain Privileges Type encodes information about the privileges of the Security Domain([TMF] SecurityDomain::privileges).

918

The Subclaim Value SHALL be represented as a CBOR Map containing either one or two entries.

919
920
921
922
923
924
925
926
927
928
929
930
931
932

TEE Security Domain Privileges Type• The first entry SHALL have key 0 and value of a CBOR Array containing zero or more entries (value).
Each element in the array SHALL be a CBOR Map containing either one or two entries:o The first entry SHALL have key 0 and a value of type CBOR Unsigned Integero If present, the second entry SHALL have key 1 and a value of type CBOR Byte String containing
privilege parameters (value)• If the Security Domain is a root SD, a second entry SHALL be included with key 1 and value of type
CBOR simple(21) representing “true” (value). Otherwise, a second entry SHALL NOT be included.
gp_tee_sd_privileges_type = {&( listOfPrivileges: 0 ) => [ * {&( privilegeID: 0 ) => uint,? &( privilegeParams: 1 ) => bstr
} ],? &( isRootSD: 1 ) => true}933

6.1.21934
935

The TEE Security Domain Protocols Type encodes a set of protocols supported by a Security Domain related
to the Security Layer implementation ([TMF] SecurityDomain::protocols).

936
937

It SHALL be represented as a CBOR Array containing zero or more entries. Each element in the array SHALL
be a CBOR Map containing either one or two entries.

938• The first entry SHALL have key 0 and value of type UUID representing the protocol UUID (value)

939
940

• If present, the second entry SHALL have key 1 and value of type CBOR Byte String containing
privilege parameters (value)

941
942
943
944

TEE Security Domain Protocols Type

gp_tee_sd_protocols_type = [ * {&( protocols: 0 )=> uuid,? &( protocolInfo: 1 ) => bstr
} ]Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 47 / 91945

6.1.22946
947

The TEE Client Properties Type encodes information related to the TEE managed by a given instance of the
TEE Client API.

948

It SHALL be represented as a CBOR Map containing one or more entries.

TEE Client Properties Type

949
950

• The first entry SHALL have key 0 and a value of type TEE Identity Type (section 6.1.14) encoding the
TEE_Identity as specified in [TEE Core].

951
952

• If present, the second entry SHALL have key 1 and a value of type isa_endianness (section 6.1.10)
specifying how values stored over more than one byte are stored by the TEE.

953
954

• If present, the third entry SHALL have key 2 and a CBOR byte string containing an encoded
gp_tee_pathList, as specified in [TEE Core], section 4.7.

955
956
957

• Additional keys and values MAY be present. Positive integer keys are reserved by GlobalPlatform and
MUST NOT be used to specify implementation-specific properties. Negative keys MAY be used to
specify implementation-specific properties

958
959
960
961
962
963
964
965
966
967
968

gp_tee_client_properties_type = {&( gpd_client_identity: 0 ) => gp_tee_identity,? &( gpd_client_endian: 1 )=> gp_tee_ta_endianness_type,? &( gpd_client_path: 2 )=> bstr .cbor gp_tee_pathList; Positive keys are reserved for future GlobalPlatform use
uint .gt 3 => any,}

; Impementation specific properties must have negative keys
nint => gp_tee_implementation_properties_value

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 48 / 91

969

6.2

Privacy

970

Some Claims may contain information with privacy implications, for example:

971• Fixed device identifiers.

972• Signing or encryption key material that is unique to a given device.

973• Current device location.

974
975
976

Because what is regarded as private depends on the context, it is not possible to label Claims as “private” or“not private” in this specification. Configuration documents could include requirements on privacy aspects ofClaims.

977

6.3

978
979

The following Claims are included from the CBOR Web Token specification [RFC 8392], maintaining the same
Claim Key, Claim Name, and requirements for the formatting of the Claim Value.

Claims from the CBOR Web Token Specification

980• iss (Issuer) Claim981• sub (Subject) Claim982• aud (Audience) Claim983• exp (Expiration Time) Claim984• nbf (Not Before) Claim

985• iat (Issued At) Claim986• cti (CWT ID) Claim

987
988
989

The evidence contained in Issuer, Subject, and Audience Claims might contain information that can be used
for identification and tracking. As such, care needs to be taken to ensure that the Claim Value in these Claims
is compliant with any applicable privacy policies.

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 49 / 91

990

6.4

Claims from the Entity Attestation Token Specification

991
992

The following Claims are included from the IETF Entity Attestation Token specification [draft-ietf-rats-eat],maintaining the same Claim Key, Claim Name, and requirements for the formatting of the Claim Value.

993• EAT Nonce Claim (eat_nonce)994• Universal Entity ID Claim (ueid)995• Semi-Permanent UEIDs Claim (sueids)996• Hardware OEM Identification Claim (oemid)997• Hardware Model Claim (hwmodel)

998• Hardware Version Claim (hwversion)999• Software Name Claim (swname)1000• Software Version Claim (swversion)

1001• OEM Authorized Boot Claim (oemboot)1002• Debug Status Claim (dbgstat)1003• Location Claim (location)

1004
1005
1006
1007
1008
1009
1010
1011
1012

o Latitude Sub-Claim (latitude)o Longitude Sub-Claim (longitude)o Altitude Sub-Claim (altitude)o Accuracy Sub-Claim (accuracy)o Altitude Accuracy Sub-Claim (altitude-accuracy)o Heading Sub-Claim (heading)o Speed Sub-Claim (speed)o Timestamp Sub-Claim (timestamp)o Age Sub-Claim (age)1013• Uptime Claim (uptime)1014• Boot Count Claim (bootcount)1015• Boot Seed Claim (bootseed)1016• Digital Letters of Approval Claim (dloas)

1017• Software Manifests Claim (manifests)

1018• Measurements Claim (measurements)

1019• Software Measurement Results Claim (measres)

1020• Submodules (submods)

1021• Timestamp Claim (iat)1022• EAT Profile Claim (eat_profile)1023• Intended Use Claim (intuse)

1024[draft-ietf-rats-eat] also includes all the Claims defined in the CBOR Web Token specification [RFC 8392].

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 50 / 91

1025
1026
1027

The evidence contained in claims such as Location might contain information that can be used for identificationand tracking. As such, care needs to be taken to ensure that the Claim Value in these Claims is compliant withany applicable privacy policies.

1028
1029

Because of the possibility of location spoofing, care needs to be taken in evaluating the evidence provided ina Location Claim, even from a trusted source.

1030
1031

Similarly, because insecure clocks can be tampered with, care needs to be taken in evaluating the evidence
provided in claims such as “Uptime” or “Issued At”.

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 51 / 91

1032

6.5

1033
1034

Top-level claims are included within the main EAT claims map. Therefore, they MUST be registered with IANA
on the CWT registry.

1035

6.5.1

1036
1037

The GlobalPlatform Component claim defines a map under which all claims for GlobalPlatform components
are managed.

1038
1039

IANA Considerations: The value of globalplatform_component MUST be a value assigned on the IANA
CBOR Web Token (CWT) Claims registry.

1040
1041
1042

Editor’s note: Document cannot be published until IANA has returned a value for
globalplatform_component. The value <IANA_ASSIGNED> below MUST be replaced with the IANA
assigned value. This note can be removed when IANA assignment is complete.

1043
1044
1045
1046
1047

Top Level Claims

GlobalPlatform Component$$Claims-Set-Claims //= (globalplatform_component => gp_component_claims)
globalplatform_component = <IANA_ASSIGNED>
gp_component_claims = { * $$GP-Claims }Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 52 / 91

1048

6.6

Claims Applicable to All Entities

1049

6.6.1

Security Rating

1050

The Security Rating Claim provides information about how secure the Entity is.

1051
1052

The claim key SHALL be 100 and the claim value SHALL be of type gp_security_rating_type defined in
section 6.1.4.

1053
1054
1055

$$GP-Claims //= (&(gp_security_rating: 100) => gp_security_rating_type
)

1056

6.6.2

1057
1058

The MUD File URL Claim includes information about where a Manufacturer Usage Description (MUD)([RFC 8520]) file can be found.

1059

The claim key SHALL be 101 and the claim value SHALL be represented as a CBOR Text String.

1060

MUD File URL$$GP-Claims //= ( &(gp_mud_file_url: 101) => tstr )

1061

6.6.3

1062
1063

A Claims Set may need to include material that is not defined by this specification. The Legacy Material Claimallows this to be included. The generation and parsing of the content are out of scope of this specification.

1064
1065
1066

The claim key SHALL be 102 and the claim value SHALL be represented as a CBOR Byte String. If the material
is in the form of a string of octets, they are placed directly into the payload. If the material is in the form of text,
the UTF-8 equivalent is placed into the payload.

1067

Legacy Material$$GP-Claims //= ( &(gp_legacy_material: 102) => bstr )

1068

6.6.4

1069
1070
1071

The Justification Claim allows the Relying Party to provide some justification as to why it is entitled to theevidence it needs. The generation and parsing of the content are out of scope of this specification, but for
example it might consist of proof of ownership of a shared secret.

1072
1073
1074

The claim key SHALL be 103 and the claim value SHALL be represented as a CBOR Byte String. If the material
is in the form of a string of octets, they are placed directly into the payload. If the material is in any other form,
the CBOR encoding is placed into the payload.

1075

Justification$$GP-Claims //= ( &(gp_justification: 103) => bstr )

1076

6.6.5

1077
1078
1079

The Context Claim allows the Relying Party to provide context to be considered when processing a request.
The generation and parsing of the content are out of scope of this specification, but for example it might consistof an application identifier.

1080
1081
1082

The claim key SHALL be 104 and the claim value SHALL be represented as a CBOR Byte String. If the material
is in the form of a string of octets, they are placed directly into the payload. If the material is in any other form,
the CBOR encoding is placed into the payload.

1083

Context$$GP-Claims //= ( &(gp_context: 104) => bstr )Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 53 / 91

1084

6.6.6

1085
1086
1087

The Important Claim allows the Relying Party to provide information about the specific claims or subclaims
which it needs to assess trustworthiness. This can assist the Entity Attestation Service in ensuring that relevant
information is provided where possible.

1088
1089

The claim key SHALL be 105 and the claim value SHALL be represented as a CBOR Array with zero or more
entries, each of which SHALL be of the Claim Prompt data type (section 6.1.2).

1090

Important$$GP-Claims //= ( &(gp_important: 105) => [* gp_claim_prompt_type ] )

1091

6.6.7

1092
1093
1094

The Unnecessary Claim allows the Relying Party to provide information about the specific claims or subclaims
which it does not require to assess trustworthiness. This can help the Entity Attestation Service minimize theamount of information it returns.

1095
1096

The claim key SHALL be 106 and the claim value SHALL be represented as a CBOR Array with zero or more
entries, each of which SHALL be of the Claim Prompt data type (section 6.1.2).

1097

Unnecessary$$GP-Claims //= ( &(gp_unnecessary: 106) => [* gp_claim_prompt_type ] )

1098

6.6.8

1099

The GP EAT Version claim allows an Attester to indicate the version of this specification that it supports.

1100
1101

The claim key SHALL be 107 and the claim value SHALL be represented as an array containing two, three orfour units, where:

GP EAT Version

1102• The first entry contains the major version of the specification.

1103• The second entry contains the minor version of the specification.

1104• The third entry, if present, contains the update version of the specification.

1105• The fourth entry, if present, contains the patch number of the specification.

1106
1107
1108

As an example, [1,3] represents specification version 1.3 and [1,0,1,3] represents specification version
1.0.1.3.
$$GP-Claims //= ( &gp_eat_version: 107) => [ 2*4 uint ] )Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 54 / 91

1109

6.7

1110
1111

This section defines Claims which are applicable to Secure Elements conforming to the GlobalPlatform Card
Specification [GPCS].

1112

6.7.1

1113
1114
1115
1116

The SE ISD Issuer Identification Number (IIN) Claim uniquely identifies the Card Issuer according to
ISO/IEC 7812-1 [ISO 7812-1]. According to [GPCS] section 7.4.1.1, it may be used to associate the card witha particular Card Management System. The IIN is of variable length in general, but as used by GlobalPlatform
it is limited to either three or four digits.

1117
1118

The claim key SHALL be 150 and the claim value SHALL be represented as a CBOR Byte String containing
the octets comprising the IIN, in the Binary Coded Decimal form defined in section 6.1.1.

1119

Claims Applicable to Secure Elements

SE ISD Issuer Identification Number$$GP-Claims //= ( &(gp_se_isd_issuer_id_number: 150) => gp_bcd_type )

1120

6.7.2

1121
1122
1123

The SE ISD Card Image Number (CIN) Claim uniquely identifies a card provided by a given Card Issuer. The
pair (IIN, CIN) form a unique identifier for a given Card. According to [GPCS], it may be used to identify anindividual Card with a particular Card Management System. CIN is of variable length.

1124
1125

The claim key SHALL be 151 and the claim value SHALL be represented as a CBOR Byte String containing
the octets comprising the CIN.

1126

SE ISD Card Image Number$$GP-Claims //= ( &(gp_se_isd_card_image_number: 151) => bstr )

1127

6.7.3

1128
1129

The SE ISD CRD Runtime Type Claim contains information from the Card Recognition Data about the type ofthe runtime environment.

1130
1131

The claim key SHALL be 152 and the claim value SHALL be represented as a CBOR Unsigned Integer
containing the relevant code.

1132

SE ISD CRD Runtime Type$$GP-Claims //= ( &(gp_se_isd_crd_runtime_type: 152) => uint )

1133

6.7.4

1134
1135

The SE ISD CRD Runtime Version Claim contains information from the Card Recognition Data about theversion of the runtime environment.

1136
1137

The claim key SHALL be 153 and the claim value SHALL be represented as a CBOR Byte String containing
3 octets comprising the version number beginning with the major version number octet.

1138
1139
1140

SE ISD CRD Runtime Version$$GP-Claims //= (&(gp_se_isd_crd_runtime_version: 153) => bstr .size (3))

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 55 / 91

1141

6.7.5

1142
1143

The SE ISD CRD GlobalPlatform Configuration Identifier Claim contains information from the Card Recognition
Data about the identity of the GlobalPlatform Configuration.

1144
1145

The claim key SHALL be 154 and the claim value SHALL be represented as a CBOR Unsigned Integer
containing the relevant code.

1146

SE ISD CRD GlobalPlatform Configuration Identifier$$GP-Claims //= ( &(gp_se_isd_gp_configuration_id: 154) => uint )

1147

6.7.6

1148
1149

The SE ISD CRD GlobalPlatform Configuration Version Claim contains information from the Card Recognition
Data about the version of the GlobalPlatform Configuration.

1150
1151

The claim key SHALL be 155 and the claim value SHALL be represented as a CBOR Byte String containing
3 octets comprising the version number beginning with the major version number octet.

1152
1153
1154

SE ISD CRD GlobalPlatform Configuration Version$$GP-Claims //= (&(gp_se_isd_crd_gp_configuration_version: 155) => bstr .size (3)
)

1155

6.7.7

1156
1157

The SE ISD CCI Secure Channel Protocols Claim contains information from the Card Capability Information
about secure channels that are supported.

1158
1159
1160
1161

The claim key SHALL be 156 and the claim value SHALL be represented as a CBOR Map with zero of more
entries. Each map pair SHALL consist of a map key that represents the Secure Channel Protocol Type in theform of a CBOR Unsigned Integer, and a map value that represents the Secure Channel Protocol parametersin the form of a CBOR Map with zero or more entries, each of which is one of the identified SE SCP Subclaims.

1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176

SE ISD CCI Secure Channel Protocols$$GP-Claims //= (&(gp_se_isd_cci_secure_channel_protocols: 156) =>gp_se_isd_cci_secure_channel_protocols_type)
gp_se_isd_cci_secure_channel_protocols_type = {* gp_se_isd_cci_secure_channel_protocol_number => { * $$GP-SCP-Claim }}$$GP-SCP-Claim //= ( &(gp_se_isd_cci_scp_options: 1) => bstr)$$GP-SCP-Claim //= ( &(gp_se_isd_cci_scp_scp03_keys: 2) => bstr)$$GP-SCP-Claim //= ( &(gp_se_isd_cci_scp_scp81_tls_suites : 3) => bstr)$$GP-SCP-Claim //= ( &(gp_se_isd_cci_scp_scp81_max_length: 4) => uint)
gp_se_isd_cci_secure_channel_protocol_number = uint1177

6.7.7.1

1178
1179

The SE ISD CCI Secure Channel Protocol Options Subclaim contains information about options relevant tothe secure channel protocol.

1180

The subclaim value SHALL be represented as a CBOR Byte String containing octets for the options.

SE ISD CCI Secure Channel Protocol Options

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 56 / 911181

6.7.7.2

1182
1183

The SE ISD CCI Secure Channel Protocol SCP03 Keys Subclaim defines the keys supported for Secure
Channel Protocol ‘03’.

1184

The subclaim value SHALL be represented as a CBOR Byte String containing octets for the supported keys.

1185

6.7.7.3

1186
1187

The SE ISD CCI Secure Channel Protocol SCP81 TLS Suites Subclaim defines the TLS cypher suites
supported for Secure Channel Protocol ‘81’.

1188
1189

The subclaim value SHALL be represented as a CBOR Byte String containing octets for the supported TLS
cypher suites.

1190

6.7.7.4

1191
1192

The SE ISD CCI Secure Channel Protocol SCP81 Max Length Subclaim defines the maximum length of preshared keys in bytes for Secure Channel Protocol ‘81’.

1193

The subclaim value SHALL be represented as a CBOR Unsigned Integer containing relevant length in bytes.

1194

6.7.8

1195
1196

The SE ISD CCI SSD Privileges Claim contains information about privileges that can be assigned to a
Supplementary Security Domain.

1197
1198

The claim key SHALL be 157 and the claim value SHALL be represented as a CBOR Byte String containing
3 octets for the privileges that can be assigned.

1199
1200
1201

SE ISD CCI Secure Channel Protocol SCP03 KeysSE ISD CCI Secure Channel Protocol SCP81 TLS Suites

SE ISD CCI Secure Channel Protocol SCP81 Max Length

SE ISD CCI SSD Privileges$$GP-Claims //= (&(gp_se_isd_cci_ssd_privileges: 157) => bstr .size (3)
)

1202

6.7.9

1203
1204

The SE ISD CCI Application Privileges Claim contains information about privileges that can be assigned to an
application.

1205
1206

The claim key SHALL be 158 and the claim value SHALL be represented as a CBOR Byte String containing
3 octets for the privileges that can be assigned.

1207
1208
1209

SE ISD CCI Application Privileges$$GP-Claims //= (&(gp_se_isd_cci_application_privileges: 158) => bstr .size (3))

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 57 / 911210

6.7.101211

The SE ISD CCI LFDB Hash Algorithms Claim defines the supported Load File Data Block hash algorithms.

1212
1213

The claim key SHALL be 159 and the claim value SHALL be represented as a CBOR Byte String containing
octets for the supported algorithms.

1214

SE ISD CCI LFDB Hash Algorithms$$GP-Claims //= ( &(gp_se_isd_cci_lfdb_hash_algorithms: 159) => bstr )1215

6.7.11

1216
1217

The SE ISD CCI LFDB Encryption Cypher Suites Claim defines the supported cypher suites for Load File Data
Block encryption.

1218
1219

The claim key SHALL be 160 and the claim value SHALL be represented as a CBOR Byte String containing
octets for the supported cypher suites.

1220
1221
1222

SE ISD CCI LFDB Encryption Cypher Suites$$GP-Claims //= (&(gp_se_isd_cci_lfdb_encryption_cypher_suites : 160) => bstr)1223

6.7.121224

The SE ISD CCI Token Cypher Suites Claim defines the supported cypher suites for tokens.

1225
1226

The claim key SHALL be 161 and the claim value SHALL be represented as a CBOR Byte String containing
octets for the supported cypher suites.

1227

SE ISD CCI Token Cypher Suites$$GP-Claims //= ( &(gp_se_isd_cci_token_cypher_suites: 161) => bstr )1228

6.7.131229

The SE ISD CCI Receipt Cypher Suites Claim defines the supported cypher suites for receipts.

1230
1231

The claim key SHALL be 162 and the claim value SHALL be represented as a CBOR Byte String containing
octets for the supported cypher suites.

1232

SE ISD CCI Receipt Cypher Suites$$GP-Claims //= ( &(gp_se_isd_cci_receipt_cypher_suites: 162) => bstr )1233

6.7.14

1234
1235

The SE ISD CCI DAP Cypher Suites Claim defines the supported cypher suites for Data Authentication
Patterns.

1236
1237

The claim key SHALL be 163 and the claim value SHALL be represented as a CBOR Byte String containing
octets for the supported cypher suites.

1238

SE ISD CCI DAP Cypher Suites$$GP-Claims //= ( &(gp_se_isd_cci_dap_cypher_suites: 163) => bstr )1239

6.7.151240

The SE ISD CCI Key Parameters Claim provides a list of key parameter references.

1241
1242

The claim key SHALL be 164 and the claim value SHALL be represented as a CBOR Byte String containing
octets for the key parameter references.

1243

SE ISD CCI Key Parameters$$GP-Claims //= ( &(gp_se_isd_cci_key_parameters: 164) => bstr )Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 58 / 911244

6.7.161245

The SE Secure Element Type Claim defines the type of the Secure Element.

1246
1247

The claim key SHALL be 165 and the claim value SHALL be represented using the SE Secure Element Typedefined in section 6.1.5.

1248
1249
1250

SE Secure Element Type$$GP-Claims //= (&(gp_se_secure_element_type : 165) => gp_se_secure_element_type_type)

1251

6.7.171252

The SE Operating System Vendor Claim contains the name of the OS vendor.

1253
1254

The claim key SHALL be 166 and the claim value SHALL be represented as a CBOR Text String containing
the octets for the UTF-8 encoded OS vendor name.

1255

SE Operating System Vendor$$GP-Claims //= ( &(gp_se_operating_system_vendor: 166) => tstr )1256

6.7.181257

The SE Operating System Version Claim contains the version of the OS.

1258
1259

The claim key SHALL be 167 and the claim value SHALL be represented as a CBOR Text String containing
the octets for the UTF-8 encoded OS version.

1260

SE Operating System Version$$GP-Claims //= ( &(gp_se_operating_system_version: 167) => tstr )1261

6.7.191262
1263

The SE Chip Manufacturer Claim contains the name of the chip manufacturer (or in the case of an integrated
SE, the name of the SoC manufacturer).

1264
1265

The claim key SHALL be 168 and the claim value SHALL be represented as a CBOR Text String containing
the octets for the UTF-8 encoded chip manufacturer name.

1266

SE Chip Manufacturer$$GP-Claims //= ( &(gp_se_chip_manufacturer: 168) => tstr )1267

6.7.20

1268
1269

The SE Chip Version Claim contains the serial number of the chip (or in the case of an integrated SE, theserial number of the SoC).

1270
1271

The claim key SHALL be 169 and the claim value SHALL be represented as a CBOR Byte String containing
the octets for the serial number.

1272

SE Chip Serial Number$$GP-Claims //= ( &(gp_se_chip_serial_number: 169) => bstr )1273

6.7.21

1274
1275

The SE Chip Version Claim contains the version of the chip (or in the case of an integrated SE, the version of
the SoC).

1276
1277

The claim key SHALL be 170 and the claim value SHALL be represented as a CBOR Text String containing
the octets for the UTF-8 encoded chip version.

1278

SE Chip Version$$GP-Claims //= ( &(gp_se_chip_version: 170) => tstr )Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 59 / 911279

6.7.22

1280

The SE Card Lifecycle State Claim defines the lifecycle state of the Secure Element.

1281
1282

The claim key SHALL be 171 and the claim value SHALL be encoded as an SE Card Lifecycle State Type as
specified in section 6.1.6.

1283
1284
1285

SE Card Lifecycle State$$GP-Claims //= (&(gp_se_card_lifecycle_state: 171) => gp_se_card_lifecycle_state_type)

1286

6.7.23

1287
1288

The SE Card Content Management Restriction Parameters Claim contains a list of content management
restrictions.

1289
1290

The claim key SHALL be 172 and the claim value SHALL be represented as a CBOR Byte String containing
the octets of the content management restrictions.

1291

SE Card Content Management Restriction Parameters$$GP-Claims //= ( &(gp_se_ccm_restriction_parameters: 172) => bstr )1292

6.7.241293
1294

The SE Supplementary Security Domains Claim contains a list of Supplementary Security Domains installedon the Secure Element.

1295
1296

The claim key SHALL be 173 and the claim value SHALL be represented using the SE Supplementary Security
Domain Type defined in section 6.1.6.

1297
1298

SE Supplementary Security Domains$$GP-Claims //= ( &( gp_se_supplementary_security_domains: 173 ) =>gp_se_supplementary_security_domains_type )1299

6.7.251300

The SE CASD Certificate Store Claim contains certificates held by the Controlling Authority Security Domain.

1301
1302

The claim key SHALL be 174 and the claim value SHALL be represented as a CBOR Byte String containing
the octets of the CASD certificate store, formatted as defined by the ASN.1 encoding in [GPCS].

1303

SE CASD Certificate Store$$GP-Claims //= ( &(gp_se_casd_certificate_store: 174) => bstr )Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 60 / 91

1304

6.8

1305
1306

This section defines Claims which correspond to properties of Trusted Execution Environments conforming to
the TEE Internal Core API Specification ([TEE Core]) and the TEE Management Framework ([TMF]).

1307

6.8.1

1308
1309

The TEE Platform Label Claim gives an indication about the certification by GlobalPlatform of the TEE ([TMF]
Tee::teePlatformLabel).

1310
1311

The claim key SHALL be 200 and the claim value SHALL be represented as a CBOR Text String containing
the UTF-8 encoded label.

1312

Claims Applicable to Trusted Execution Environments

TEE Platform Label$$GP-Claims //= ( &(gp_tee_platform_label: 200) => tstr )

1313

6.8.2

1314
1315

The TEE Root Security Domains Claim contains a list of root Security Domains (rSDs) installed in the TEE([TMF] Tee::roots).

1316
1317
1318

The claim key SHALL be 201 and the claim value SHALL be represented as a CBOR Array with zero or more
entries, each of which being a CBOR Byte String containing the octets that form the UUID of a relevant root
Security Domain.

1319

TEE Root Security Domains$$GP-Claims //= ( &(gp_tee_root_security_domains: 201) => [* bstr] )

1320

6.8.3

1321

The TEE Lifecycle State Claim gives an indication of the lifecycle state of the TEE ([TMF] Tee::state).

1322
1323

The claim key SHALL be 202 and the claim value SHALL be encoded using the TEE Lifecycle State Typedefined in section 6.1.7.

1324
1325
1326

TEE Lifecycle State$$GP-Claims //= (&(gp_tee_lifecycle_state: 202) => gp_tee_lifecycle_state_type
)

1327

6.8.4

1328

The TEE Device Name Claim contains the name of the device ([TMF] Tee::device::name).

1329
1330

The claim key SHALL be 203 and the claim value SHALL be a CBOR Text String containing the UTF-8
encoded device name.

1331

TEE Device Name$$GP-Claims //= ( &(gp_tee_device_name: 203) => tstr )

1332

6.8.5

1333
1334

The TEE Device Manufacturer Claim contains the name of the firmware manufacturer ([TMF]
Tee::device::manufacturer).

1335
1336

The claim key SHALL be 204 and the claim value SHALL be a CBOR Text String containing the UTF-8
encoded device manufacturer name.

1337

TEE Device Manufacturer$$GP-Claims //= ( &(gp_tee_device_manufacturer: 204) => tstr )Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 61 / 91

1338

6.8.6

1339

The TEE Device Type Claim contains the type of the device ([TMF] Tee::device::type).

1340
1341

The claim key SHALL be 205 and the claim value SHALL be a CBOR Text String containing the UTF-8
encoded device type.

1342

TEE Device Type$$GP-Claims //= ( &(gp_tee_device_type: 205) => tstr )

1343

6.8.7

1344

The TEE Trusted OS Name Claim contains the name of the Trusted OS ([TMF] Tee::TrustedOS::name).

1345
1346

The claim key SHALL be 206 and the claim value SHALL be a CBOR Text String containing the UTF-8
encoded Trusted OS name.

1347

TEE Trusted OS Name$$GP-Claims //= ( &(gp_tee_trusted_os_name: 206) => tstr )

1348

6.8.8

1349
1350

The TEE Trusted OS Architectures Claim includes details of instruction sets and architectures which can beused by Trusted Applications running in the TEE.

1351
1352

The claim key SHALL be 207 and the claim value SHALL be a TEE Trusted OS Architectures Type defined in
section 6.1.9.

1353
1354
1355
1356

TEE Trusted OS Architectures$$GP-Claims //= (&(gp_tee_trusted_os_architectures: 207) =>gp_tee_trusted_os_architectures_type
)

1357

6.8.9

1358
1359

The TEE Trusted OS Options Claim contains a list of options supported by the TEE ([TMF]
Tee::TrustedOS::options).

1360

The claim key SHALL be 208 and the claim value SHALL be a TEE Options Type, specified in section 6.1.11.

1361
1362
1363

TEE Trusted OS Options$$GP-Claims //= (&(gp_tee_trusted_os_options: 208) => gp_tee_options_type)1364

6.8.101365
1366

The TEE Optional APIs Claim contains a list of optional APIs implemented by the TEE ([TMF]
Tee::optionalApis).

1367

The claim key SHALL be 209 and the claim value SHALL be a TEE Options Type, specified in section 6.1.11.

1368
1369
1370
1371

TEE Optional APIs$$GP-Claims //= (&(gp_tee_optional_apis: 209) => gp_tee_options_type)

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 62 / 911372

6.8.111373
1374

The TEE Implementation Properties
Tee::teeImplementationProperties).

1375
1376

The claim key SHALL be 210 and the claim value SHALL be a TEE Implementation Properties Type (section
6.1.12).

1377
1378
1379
1380

TEE Implementation Properties
Claim

contains

a

list

of

TEE

properties([TMF]$$GP-Claims //= (&(gp_tee_implementation_properties: 210) =>gp_tee_implementation_properties_type}1381

6.8.121382

The TEE Trusted Applications Claim contains a list of Trusted Applications installed in the TEE.

1383

The claim key SHALL be 211 and the claim value SHALL be a TEE Trusted Applications Type (section 6.1.15).

1384
1385
1386
1387
1388

TEE Trusted Applications$$GP-Claims //= (&(gp_tee_trusted_applications: 211) =>gp_tee_trusted_applications_type)1389

6.8.131390

The TEE Security Domains Claim contains a list of Security Domains present in the TEE.

1391

The claim key SHALL be 212 and the claim value SHALL be a TEE Security Domains Type (section 6.1.17).

1392
1393
1394
1395

TEE Security Domains$$GP-Claims //= (&(gp_tee_security_domains: 212) =>gp_tee_security_domains_type ))1396

6.8.141397
1398

The TEE Client Properties Claim contains properties related to the TEE which may be of use to clients in the
REE, particularly when there is more than one accessible TEE on a system.

1399

The claim key SHALL be 213 and the claim value SHALL be a TEE Client Properties Type (section 6.1.22).

1400
1401
1402
1403

TEE Client Properties$$GP-Claims //= (&(gp_tee_client_properties: 213)=>
gp_tee_client_properties_type ))Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 63 / 91

1404

7

CLAIMS SETS

1405
1406
1407

A Claims Set is an aggregation of Claims from an entity which can be regarded as a group. If signed or
encrypted, all Claims within a Claims Set will be processed with the same algorithm, key material, and context
information.

1408
1409

A Claims Set is represented as a CBOR Map, each element of which represents a single Claim. Claims otherthan those defined in section 6 can be included, but their interpretation is out of scope of this specification.

1410
1411

The value field of most Claims is a straightforward parameter. However, some types of Claim introduce
hierarchy, as defined below.

1412

7.1

1413
1414
1415
1416
1417

Some Claims only have a defined meaning when associated with another Claim. These are referred to as
Subclaims. Note that a Subclaim has exactly the same structure as a normal Claim. The association is madeby including the Subclaims in the Claim Value of a normal Claim. Subclaims SHOULD only be included in the
Claim Value of a Claim for which their meaning is defined. If a Claims Set includes Subclaims not included in
the Claim Value of a Claim for which their meaning is defined, those Subclaims MAY be ignored.

1418
1419

It is possible to have more than one Claim that has Subclaims in a given Claims Set, but because Claim Keys
need to be unique in a CBOR Map, all related Subclaims have to be grouped under a single Claim.

1420

To prepare related Subclaims for use in a Claims Set:

Subclaims

1421
1422

1. Assemble all Subclaims that are related to a single Claim into a nested Claims Set in the normal formof a CBOR Map (even if there is only a single Subclaim).

1423

2. Create a Claim with the relevant Claim Key and the CBOR Map created in step 1 as the Claim Value.

1424

To parse Subclaims included in a Claim present in a Claims Set:

1425
1426

1. If the Claim Key indicates that it can include Subclaims, extract the Subclaims by interpreting theClaim Value as a CBOR Map.

1427
1428

2. Treating the CBOR Map as a nested Claims Set, parse each Subclaim in the context of the Claim Key
obtained in step 1.

1429

7.2

Submodules

1430
1431
1432
1433

Where a device has more than one platform capable of generating evidence for inclusion in an Entity
Attestation Token, it is possible to group claims sets or tokens from the various sources together using thesubmods Claim. The Claims Sets or Tokens from each source are grouped together as an array, then thearray is included in the Claim Value of a submods Claim.

1434
1435

Because Claim Keys need to be unique in a CBOR Map, only a single submods Claim can be present, so
Claims Sets and Tokens from all submodules have to be grouped under a single submods Claim.

1436
1437
1438
1439
1440
1441

Claims Sets, Entity Attestation Tokens, and Detached Submodule Digests can be included in the submods
Claim, and effectively a Claims Set is included as an untagged Unendorsed Claims Set. An untagged
Unendorsed Claims Set takes the form of a CBOR Map, and an untagged Entity Attestation Token or Detached
Submodule Digest takes the form of a CBOR Array, so it may be distinguished at the CBOR level. Although
not described in [draft-ietf-rats-eat], it is also possible to assist the parser by including the Unendorsed Claims
Set tag and the CWT tag plus the COSE tag for an Entity Attestation Token.

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 64 / 911442

To prepare a Claims Set from a submodule for inclusion in a submods Claim:

1443

1. Create a Submod Name Claim with a descriptive label as the Claim Value.

1444
1445

2. Optionally create a Security Rating Claim with values suitable for the submodule, with the restrictionthat the submodule cannot be marked as higher security than that of the EAS.

1446

3. Optionally create other Claims with additional information relevant to the submodule.

1447
1448

4. Assemble the Claims from steps 1, 2, and 3 together with all the Claims from the submodule into an
Unendorsed Claims Set in the normal form of a CBOR Map (even if there is only a single Claim).

1449

5. Optionally prefix the Claims Set with the Unendorsed Claims Set tag.

1450
1451
1452
1453

To prepare an Entity Attestation Token from a submodule for inclusion in a submods Claim:
1. If not already present, optionally prefix the token with the CWT tag and the appropriate COSE tag.
To prepare a Detached Submodule Digest from a submodule for inclusion in a submods Claim:
1. No further action is required.

1454
1455

To prepare Claims Sets, Entity Attestation Tokens, and Detached Submodule Digests from all submodules foruse in a Claims Set:

1456
1457

1. For each Claims Set, Entity Attestation Token, or Detached Submodule Digest, prepare a nested
Entity Attestation Parcel as described above.

1458
1459

2. Assemble all the nested Entity Attestation Parcels from step 1 into a CBOR Array (even if there is onlya single Entity Attestation Parcel).

1460

3. Create a submods Claim with the CBOR Array created in step 2 as the Claim Value.

1461

To parse submodule Claims Sets included in a submods Claim present in a Claims Set:

1462

1. Extract the Claims Sets for all submodules by interpreting the Claim Value as a CBOR Array.

1463
1464

2. For each element in the CBOR Array, extract an Entity Attestation Parcel by interpreting the arrayentry as an Unendorsed Claims Set, Entity Attestation Token, or Detached Submodule Digest.

1465

To parse a Claims Set from a submodule included in a nested Unendorsed Claims Set:

1466
1467

1. If present, check that the tag value matches the Unendorsed Claims Set tag value, and exit with anerror if it does not.

1468

2. Check that the CBOR Major Type is Map, and exit with an error if it is not.

1469

3. Treat the CBOR Map as a nested Claims Set.

1470
1471

4. If the nested Claims Set does not contain a Submod Name Claim, the Claims from the submodule
MAY be ignored.

1472

To parse an Entity Attestation Token from a submodule included in a nested Entity Attestation Token:

1473
1474

1. If present, check that the tag value matches the Entity Attestation Token tag, and exit with an error if it
does not.

1475
1476

2. If an Entity Attestation Token is present, check that it is followed by a valid COSE tag, and exit with anerror if not.

1477

3. Check that the CBOR Major Type is Array, and exit with an error if it is not.

1478

4. Treat the CBOR Array as an Entity Attestation Token.

1479
1480

To parse a Detached Submodule Digest from a submodule included in a nested Detached Submodule Digest:
1. No further action is required.
Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 65 / 91

1481

8

UNENDORSED CLAIMS SETS

1482
1483

An Unendorsed Claims Set is based on the Unprotected CWT Claims Set [draft-birkholz-rats-uccs] which is
not based on COSE, but does use CBOR for encoding. It includes the following elements:

1484
1485

• The tag used to identify the content as a Claims Set (required only if the meaning of the payload is nototherwise obvious from context)

1486• An unencapsulated Claims Set (the payload)

1487

8.1

1488

The Unendorsed Claims Set is constructed as follows:1489

1. Create the unencapsulated Claims Set:

1490
1491

Construction

a. Create the Claims Set as a CBOR Map.
2. Optionally prefix the CBOR Map constructed in step 1 with the UCCS tag.

1492

8.2

Interpretation

1493

To obtain a Claims Set from the content of an Unendorsed Claims Set, the following steps are taken:

1494

1. Interpret the string of bytes according to [RFC 8949], and exit with an error if it is not well formed.

1495

2. If a tag is present, check that it matches the UCCS value, and exit with an error if it does not.

1496

3. Check that the CBOR Major Type is Map, and exit with an error if it is not.

1497

4. Interpret the CBOR Map as a Claims Set.

1498

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 66 / 91

1499

9

ENTITY ATTESTATION TOKENS

1500
1501

An Entity Attestation Token is based on the CBOR Web Token (CWT) [RFC 8152] which itself uses the COSE
Messages defined in [RFC 8152], and as such includes at least the following elements:

1502• A set of protected header parameters

1503• A set of unprotected header parameters1504• The content of the message

1505

The format of each element is defined in [RFC 8152].

1506
1507

An EAT can also include additional elements, as defined in [RFC 8152], for each of the defined COSE
Messages.

1508

The unprotected header can contain countersignatures.

1509
1510

The content of the message is always a CBOR Byte String which encapsulates the CBOR encoding of the
CBOR Map that contains the Claims.

1511

An Entity Attestation Token is endorsed in one of the following ways.

1512
1513

• A Signed Entity Attestation Token consists of the encapsulated Claims Set as the content plus at least
one signature; it is defined in section 10.

1514
1515

• An Encrypted Entity Attestation Token consists of the ciphertext equivalent of the Claims Set as thecontent, and may contain key distribution information; it is defined in section 11.

1516
1517

• A MACed Entity Attestation Token consists of the encapsulated Claims Set as the content plus a
MAC, and may contain key distribution information; it is defined in section 12.

1518

Section 13 defines how to apply more than one type of endorsement.

1519

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 67 / 91

1520

10 SIGNED ENTITY ATTESTATION TOKENS

1521
1522
1523

This specification defines how to create a signed Token but imposes no requirements on which algorithms
need to be supported in any given system. Configuration documents could mandate specific signing algorithms
for particular use cases.

1524

In the GlobalPlatform usage, Entity Attestation Tokens SHALL be signed by a Root of Trust.

1525

10.1

1526
1527
1528

When using a PKI scheme, the recipient will only be able to verify a signature if it has access to the public key
corresponding to the private key used for signing. There are many well-established ways by which public key
material can be distributed, and this specification takes as a prerequisite that this has been done.

1529

10.2

1530

The following context is required in order to construct a Signed Entity Attestation Token.

Prerequisites

Context

1531• Number of signatures required

1532• Algorithm for each signature

1533• Key identifier for each signature

1534• Any other body or recipient header parameters

1535• Any external data

1536
1537

The choice of algorithm for each signature is dependent on security requirements and the capability of therecipient, and is out of scope of this document.

1538
1539

The inclusion of header parameters not directly related to the signing process, and any policies regarding
verifying or using any such parameters, are application dependent, and are out of scope of this document.

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 68 / 91

1540

10.3

Construction1541

10.3.1Creating the Content

1542

The content is created as follows:1543

1. Create the CBOR encoding for the Claims Set as a series of bytes.

1544

2. Create a CBOR Byte String with the payload set to the series of bytes generated in step 1.

1545

10.3.2

1546
1547
1548

For each required signer, a signature is created following the process defined in [RFC 8152]. At a minimum,
header parameters are created which contain the algorithm and key identifier used in generating the signature.
Other header parameters can also be included.

1549
1550

If only a single signature is required, then a COSE_Sign1 message SHOULD be used because the size of
the CBOR representation is slightly smaller. In all other cases, a COSE_Sign message SHALL be used.

1551

In the case of COSE_Sign1, the Signed EAT is constructed as follows:Signing the EAT

1552

1. Construct protected and unprotected headers from parameters including the signature algorithm.

1553

2. Add the content constructed in section 10.3.1.

1554

3. Create the signature following the process defined in [RFC 8152].

1555

4. Add the signature as a fourth element in the COSE_Sign1 Message.

1556
1557

In the case of COSE_Sign, the Signed EAT is constructed as follows:
1. For each signer:

1558
1559

a. Construct protected and unprotected headers from parameters including the signature algorithm
and the key identifier.

1560

b. Create the signature following the process defined in [RFC 8152].

1561
1562

c. Create a COSE_Signature from the protected and unprotected headers plus the signature itself
as the content.

1563

2. Create an array including each COSE_Signature created in step 1.

1564
1565

3. Construct body protected and unprotected headers which can contain header parameters unrelated tothe signatures.

1566

4. Add the content constructed in section 10.3.1.

1567

5. Add the array created in step 2 as a fourth element of the COSE_Sign Message.

1568
1569

In both cases, the COSE Message can be tagged with the appropriate value if the nature of the Signed EAT
is not obvious from context, as defined in section 14.1.

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 69 / 91

1570

10.4

Interpretation

1571
1572
1573

If the nature of the Signed EAT is known from context, for example if it comes from a COSE tagged EAT as
defined in section 14.2, this can be used to check the structure of the COSE Message in the content data of
the CBOR Tag. Otherwise, the determination is made by checking the fourth item.

1574
1575

• If this is a CBOR Array of COSE_Signature, handle the EAT as if tagged with the COSE_Signvalue.

1576• If this is a CBOR Byte String, handle the EAT as if tagged with the COSE_Sign1 value.

1577• Otherwise exit with the code “UNVERIFIED”.

1578
1579
1580

If the Signed EAT contains a COSE_Sign1 message, the verification parameters, including the algorithm andkey identifier to be used, are determined from the body protected and unprotected headers, and the signature
is obtained from the fourth data element of the COSE_Sign1 Message.

1581
1582
1583

If the Signed EAT contains a COSE_Sign message, then for each signature, the necessary information isdetermined from the protected and unprotected headers plus the content element of each COSE_Signaturein the array.

1584

In both cases, the payload is in the body content field.

1585

The following applies for each signature in the Signed EAT:

1586
1587

• Check whether the algorithm used for the signature verification is supported, and exit with the code
“UNVERIFIED” if it is not.

1588
1589

• Check whether the key used for the signature verification is available, and exit with the code
“UNVERIFIED” if it is not.

1590
1591

• Verify the signature following the process defined in [RFC 8152], and exit with the code “INVALID” if
the verification is unsuccessful.

1592• Exit with the code “VALID”.

1593

This specification imposes no requirements on:

1594• How to proceed if a signature cannot be verified because a key or algorithm is not available

1595• Whether all signatures need to be verified or only a subset

1596• How to process any header parameters unrelated to the signature verification

1597

Configuration documents may choose to impose requirements in this area.

1598

Once verification of the Signed EAT is complete, the content is interpreted as follows:

1599

1. Check that the CBOR Major Type is Byte String, and exit with an error if it is not.

1600

2. Extract the payload of the byte string as a series of bytes.

1601

3. Interpret the string of bytes according to [RFC 8949], and exit with an error if it is not well formed.

1602

4. Check that the CBOR Major Type is Map, and exit with an error if it is not.

1603

5. Interpret the CBOR Map as a Claims Set.

1604

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 70 / 91

1605

11 ENCRYPTED ENTITY ATTESTATION TOKENS

1606
1607
1608

This specification defines how to create an encrypted Token but imposes no requirements on which algorithms
need to be supported in any given system. Configuration documents could mandate specific encryption
algorithms for particular use cases.

1609

In the GlobalPlatform usage, Entity Attestation Tokens SHALL be encrypted and decrypted by a Root of Trust.

1610

11.1

1611
1612

In order to be able to decrypt an Encrypted Entity Attestation Token, the recipient needs either to possess asuitable key or to be given the information necessary to construct one.

1613

11.1.1

1614
1615
1616

The simplest case of symmetric encryption is where both parties possess a common shared secret by somemeans out of scope of this specification. Such means include provisioning during manufacturing, a previous
key agreement procedure, or a previous key distribution procedure.

1617
1618
1619

Alternatively, each party could possess a static public key generated by the other. In this case, a commonshared secret can be constructed using key agreement providing that information about the keys used isincluded in the Encrypted EAT.

1620
1621
1622
1623

Finally, the generator of the EAT could possess a static public key for the recipient, but either knows that therecipient does not possess a public key from the generator, or chooses to use an ephemeral key. Here, acommon shared secret can be constructed using key agreement providing that information about the recipient
key and the value of the ephemeral public key are included in the Encrypted EAT.

1624
1625

In all cases, including that of the fixed shared secret, key derivation can be applied for a specific use, providingthat context information is already known by both parties, or included in the headers of the Encrypted EAT.

1626

11.1.2

1627
1628
1629

The simplest case of asymmetric encryption is where the generator of the EAT possesses a public key for a
private key held by the recipient by some means out of scope of this specification. In this case, the EAT cancontain the name of the private key, or this can be omitted if the key to use is implicitly known.

1630
1631
1632

Alternatively, the generator can use key wrapping to send the private key to the recipient. The recipient canunwrap the private key using a shared secret which is either pre-shared or derived from header information in
the Encrypted EAT.

1633

11.2

1634

The following context is required in order to construct an Encrypted Entity Attestation Token.

Prerequisites

Symmetric Encryption

Asymmetric Encryption

Context

1635• Encryption algorithm

1636• Optionally, key distribution algorithm

1637• Key identifier(s)1638• Any other body or recipient header parameters

1639• Any external data

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 71 / 91

1640
1641
1642

The choice of encryption algorithm is dependent on security requirements and the capability of the recipient,and is out of scope of this document. The choice of key distribution algorithm is dependent on security
requirements and key availability, and is out of scope of this document.

1643
1644

The inclusion of header parameters not directly related to the encryption process, and any policies regarding
verifying or using any such parameters, are application dependent, and are out of scope of this document.

1645

11.3

Construction

1646

11.3.1Creating the Content

1647

The content is created as follows:

1648

1. Create the CBOR encoding for the Claims Set as a series of bytes.

1649

2. Create a CBOR Byte String with the payload set to the series of bytes generated in step 1.

1650

11.3.2

1651
1652
1653
1654

Ciphertext is created following the process defined in [RFC 8152]. At a minimum, header parameters are
created which contain the algorithm and key identifier(s) or key value used in generating the ciphertext. Certain
algorithms can require the inclusion of additional header parameters such as an initial value. Other header
parameters can also be included.

1655
1656
1657

If a shared secret is already known to both the Relying Party and the Entity Attestation Service, and no key
derivation is required, then a COSE_Encrypt0 message SHOULD be used because the size of the CBOR
representation is slightly smaller. In all other cases, a COSE_Encrypt message SHALL be used.

1658

In the case of COSE_Encrypt0, the Encrypted EAT is constructed as follows:

Encrypting the EAT

1659
1660

1. Construct protected and unprotected headers from parameters including the encryption algorithm andany additional values required by the algorithm.

1661
1662

2. Create the ciphertext from the content constructed in section 11.3.1 plus any associated data,
following the process defined in [RFC 8152].

1663

3. Add the ciphertext as the content of the COSE_Encrypt0 Message.

1664

In the case of COSE_Encrypt, the Encrypted EAT is constructed as follows:

1665
1666

1. Construct recipient protected and unprotected headers from parameters including the key distribution
algorithm, the key identifiers or values, and any additional values such as salt or context information.

1667
1668

2. Create a COSE_Recipient from the protected and unprotected headers plus the ciphertext as thecontent.

1669

3. Create an array of COSE_Recipients with the single entry created in step 2.

1670
1671

4. Construct body protected and unprotected headers from parameters including the encryption
algorithm and any additional values required by the algorithm.

1672
1673
1674

5. Create the ciphertext from the content constructed in section 11.3.1 plus any associated data, using a
key generated using a mechanism defined in one of the recipients, following the process defined in[RFC 8152].

1675
1676

6. Add the array of COSE_Recipients constructed in step 3 as a fourth element of the COSE_Encrypt
Message.

1677
1678

In both cases, the COSE Message can be tagged with the appropriate value if the nature of the Encrypted
EAT is not obvious from context, as defined in section 14.1.
Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 72 / 91

1679

11.4

Interpretation

1680
1681
1682

If the nature of the Encrypted EAT is known from context, for example if it comes from a COSE tagged EAT
as defined in section 14.2, then the nature can be used to check the structure of the COSE Message in thecontent data of the CBOR Tag. Otherwise, the determination is made by checking the fourth item.

1683• If there is no fourth item present, handle the EAT as if tagged with the COSE_Encrypt0 value.

1684
1685

• If the fourth item is a CBOR Array of COSE_Recipients, handle the EAT as if tagged with the
COSE_Encrypt value.

1686
1687

• Otherwise, either handle the EAT as if tagged with the COSE_Encrypt0 value (ignoring theinformation in the fourth item), or exit with the code “UNVERIFIED”.

1688
1689
1690
1691
1692

The decryption parameters including the algorithm to be used are determined from the body protected andunprotected headers. The ciphertext is obtained from the body content. If the Encrypted EAT contains a
COSE_Encrypt Message, the key distribution parameters including the algorithm to be used are determinedfrom the protected and unprotected headers of the COSE_Recipients. Otherwise, the key material to use is
expected to be present and known from context.

1693

If the Encrypted EAT contains a COSE_Encrypt message, the decryption key is constructed as follows:

1694

1. Check whether the algorithm used for key distribution is supported, and exit if it is not.

1695

2. Check whether all indicated keys are available, and exit if they are not.

1696
1697

3. Construct the key using the algorithm, keys, and any other relevant parameters in the recipient
protected and unprotected headers.

1698
1699

If there is more than one recipient present, the verifier may choose any one to derive the decryption key basedon which mechanisms it supports.

1700

The ciphertext is verified as follows.

1701
1702

1. Check whether the algorithm used for decryption is supported, and exit with the code “UNVERIFIED” if
it is not.

1703
1704

2. Check whether the key used for decryption is available, and exit with the code “UNVERIFIED” if it is
not.

1705
1706

3. Decrypt the ciphertext following the process defined in [RFC 8152], and exit with the code “INVALID” if
the verification is unsuccessful.

1707

4. Exit with the plaintext and the code “VALID”.

1708
1709

This specification imposes no requirements on:• How to process any header parameters unrelated to key distribution or decryption

1710

Configuration documents may choose to impose requirements in this area.

1711

Once verification of the Encrypted EAT is complete, the plaintext is interpreted as follows:

1712

1. Check that the CBOR Major Type is Byte String, and exit with an error if it is not.

1713

2. Extract the payload of the byte string as a series of bytes.

1714

3. Interpret the string of bytes according to [RFC 8949], and exit with an error if it is not well formed.

1715

4. Check that the CBOR Major Type is Map, and exit with an error if it is not.

1716

5. Interpret the CBOR Map as a Claims Set.

1717
Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 73 / 91

1718

12 MACED ENTITY ATTESTATION TOKENS

1719
1720
1721

This specification defines how to create a MACed Token but imposes no requirements on which algorithms
need to be supported in any given system. Configuration documents could mandate specific MAC algorithms
for particular use cases.

1722

12.1

1723
1724
1725

In order to be able to authenticate the MAC included in an Encrypted Entity Attestation Token, the recipientneeds either to possess a suitable key, or to be given the information necessary to construct one. The basis
for MAC authentication key generation is identical to that for decryption key generation in section 11.1.

1726

12.2

1727

The following context is required in order to construct a MACed Entity Attestation Token.

Prerequisites

Context

1728• MAC algorithm

1729• Optionally, key distribution algorithm

1730• Key identifier(s)1731• Any other body or recipient header parameters

1732• Any external data

1733
1734
1735

The choice of MAC algorithm is dependent on security requirements and the capability of the recipient, and isout of scope of this document. The choice of key distribution algorithm is dependent on security requirements
and key availability, and is out of scope of this document.

1736
1737

The inclusion of header parameters not directly related to the MAC process, and any policies regarding
verifying or using any such parameters, are application dependent, and are out of scope of this document.

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 74 / 91

1738

12.3

Construction1739

12.3.1Creating the Content

1740

The content is created as follows:

1741

1. Create the CBOR encoding for the Claims Set as a series of bytes.

1742

2. Create a CBOR Byte String with the payload set to the series of bytes generated in step 1.

1743

12.3.2

1744
1745
1746
1747

A Message Authentication Code (MAC) is created following the process defined in [RFC 8152]. At a minimum,
header parameters are created which contain the algorithm and key identifier(s) or key value used ingenerating the MAC. Certain algorithms can require the inclusion of additional header parameters. Other
header parameters can also be included.

1748
1749
1750

If a shared secret is already known to both the Relying Party and the Entity Attestation Service, and no key
derivation is required, then a COSE_Mac0 message SHOULD be used because the size of the CBOR
representation is slightly smaller. In all other cases, a COSE_Mac message SHALL be used.

1751

In the case of COSE_Mac0, the MACed EAT is constructed as follows:

MACing the EAT

1752
1753

1. Construct protected and unprotected headers from parameters including the MAC algorithm and any
additional values required by the algorithm.

1754
1755

2. Create the MAC from the content constructed in section 11.3.1 plus any associated data, following theprocess defined in [RFC 8152].

1756

3. Add the MAC as a fourth element in the COSE_Mac0 Message.

1757

In the case of COSE_Mac, the MACed EAT is constructed as follows:

1758
1759

1. Construct recipient protected and unprotected headers from parameters including the key distribution
algorithm, the key identifiers or values, and any additional values such as context information.

1760
1761

2. Create a COSE_Recipient from the protected and unprotected headers plus the ciphertext as thecontent.

1762

3. Create an array of COSE_Recipients with the single entry created in step 2.

1763
1764

4. Construct body protected and unprotected headers from parameters including the encryption
algorithm and any additional values required by the algorithm.

1765
1766
1767

5. Create the MAC from the content constructed in section 12.3.1 plus any associated data, using a key
generated using a mechanism defined in one of the recipients, following the process defined in[RFC 8152].

1768

6. Add the MAC created in step 5 as a fourth element of the COSE_Mac message.

1769
1770

7. Add the array of COSE_Recipients constructed in step 3 as a fifth element of the COSE_Mac
message.

1771
1772

In both cases, the COSE Message can be tagged with the appropriate value if the nature of the MACed EAT
is not obvious from context, as defined in section 14.1.

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 75 / 91

1773

12.4

Interpretation

1774
1775
1776

If the nature of the MACed EAT is known from context, for example if it comes from a COSE tagged EAT as
defined in section 14.2, this can be used to check the structure of the COSE Message in the content data of
the CBOR Tag. Otherwise, the determination is made by checking the fifth items.

1777• If there is no fifth item present, handle the EAT as if tagged with the COSE_Mac0 value.

1778
1779

• If the fifth item is a CBOR Array of COSE_Recipients, handle the EAT as if tagged with the
COSE_Mac value.

1780
1781

• Otherwise, either handle the EAT as if tagged with the COSE_Mac0 value (ignoring the information in
the fourth item), or exit with the code “UNVERIFIED”.

1782
1783
1784
1785
1786

The MAC authentication parameters including the algorithm to be used are determined from the body protected
and unprotected headers. The Claims Set is obtained from the body content. If the MACed EAT contains a
COSE_Mac message, the key distribution parameters including the algorithm to be used are determined fromthe protected and unprotected headers of the COSE_Recipients. Otherwise, the key material to use is
expected to be present and known from context.

1787

If the MACed EAT contains a COSE_Mac message, the MAC authentication key is constructed as follows:

1788

1. Check whether the algorithm used for key distribution is supported, and exit if it is not.

1789

2. Check whether all indicated keys are available, and exit if they are not.

1790
1791

3. Construct the key using the algorithm, keys, and any other relevant parameters in the recipient
protected and unprotected headers.

1792
1793

If there is more than one recipient present, the verifier may choose any one to derive the MAC authentication
key based on which mechanisms it supports.

1794

The MAC is authenticated as follows.

1795
1796

1. Check whether the algorithm used for authentication is supported, and exit with the code
“UNVERIFIED” if it is not.

1797
1798

2. Check whether the key used for authentication is available, and exit with the code “UNVERIFIED” if it
is not.

1799
1800

3. Authenticate the MAC following the process defined in [RFC 8152], and exit with the code “INVALID” if
the authentication is unsuccessful.

1801

4. Exit with the code “VALID”.

1802
1803

This specification imposes no requirements on:• How to process any header parameters unrelated to key distribution or MAC authentication

1804

Configuration documents may choose to impose requirements in this area.

1805

Once authentication of the MACed EAT is complete, the content is interpreted as follows:

1806

1. Check that the CBOR Major Type is Byte String, and exit with an error if it is not.

1807

2. Extract the payload of the byte string as a series of bytes.

1808

3. Interpret the string of bytes according to [RFC 8949], and exit with an error if it is not well formed.

1809

4. Check that the CBOR Major Type is Map, and exit with an error if it is not.

1810

5. Interpret the CBOR Map as a Claims Set.

1811
Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 76 / 91

1812

13 MULTIPLY ENDORSED ENTITY ATTESTATION TOKENS

1813
1814
1815

In certain circumstances, it might be necessary to apply two types of endorsement to an Entity Attestation
Token. For example, a token might need to be signed for authenticity reasons, then encrypted for confidentiality
reasons.

1816

A multiply endorsed Entity Attestation Token is constructed as follows:1817

1. An Entity Attestation Token is constructed using one of the methods defined in section 9.

1818

2. A Claims Set is created that contains a “submods” claim containing the EAT constructed in step 1.

1819
1820

3. An Entity Attestation Token containing the Claims Set created in step 2, using one of the methods
defined in section 9.

1821

This approach can continue with third or higher numbers of endorsements.

1822

A multiply endorsed Entity Attestation Token is parsed as follows:

1823

1. The Entity Attestation Token is parsed using the appropriate method defined above.

1824

2. The content of the “submods” Claim is extracted and interpreted as an Entity Attestation Token.

1825

3. The nested Entity Attestation Token is parsed using the appropriate method defined above.

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 77 / 91

1826

14 TAGGING ENTITY ATTESTATION TOKENS

1827
1828

Unless context makes it certain that an Entity Attestation Token will be recognized for what it is, a defined tag
SHOULD be used to assist in parsing.

1829

Any untagged Entity Attestation Token MAY be tagged.

1830
1831
1832
1833
1834
1835

An Entity Attestation Token that has been created using the process described in the sections above has notags, and contains a COSE_Untagged_Message (specifically, a COSE_Sign, a COSE_Sign1, a
COSE_Encrypt, a COSE_Encrypt0, a COSE_Mac, or a COSE_Mac0 Message). If a COSE tag is added, theEAT contains a COSE_Tagged_Message (specifically a COSE_Sign_Tagged, a COSE_Sign1_Tagged, a
COSE_Encrypt_Tagged, a COSE_Encrypt0_Tagged, a COSE_Mac_Tagged, or a COSE_Mac0_Tagged
Message).

1836
1837
1838
1839

The Entity Attestation Token specification [draft-ietf-rats-eat] defines an EAT as being a CBOR Web Token[RFC 8392]. This specification follows [draft-ietf-rats-eat] in including the value 61 as the tag value. As requiredby [RFC 8392], if the Entity Attestation Token is prefixed by the CWT tag, the CWT tag SHALL be immediately
followed by a COSE tag.

1840

14.1

1841

A Tagged Entity Attestation Token is constructed as follows:

Construction

1842

1. Create an untagged EAT as defined above.

1843
1844

2. Create a COSE tagged EAT by prefixing the untagged EAT built in step 1 with the appropriate COSE
tag as defined in [RFC 8949].

1845
1846

3. If the CWT tag is to be included, create the tagged EAT by prefixing the COSE tagged EAT built instep 2 with the CWT tag.

1847

4. Otherwise, the tagged EAT is just the COSE tagged EAT built in step 2.

1848

14.2

Interpretation

1849

A Tagged Entity Attestation Token is interpreted as follows:

1850
1851

1. If the tag value of the tagged EAT matches the CWT tag, the COSE tagged EAT is the nested CBOR
Data Item as defined in [RFC 8949], otherwise the COSE tagged EAT is just the tagged EAT.

1852
1853

2. Check that the CBOR Major Type of the COSE tagged EAT built in step 1 is Tag, and that the tagvalue matches a defined COSE value, and exit with an error if not.

1854

3. The untagged EAT is the nested CBOR Data Item of the COSE tagged EAT build in step 2.

1855

4. Interpret the untagged EAT as defined above.

1856

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 78 / 91

1857

15 DETACHED EAT BUNDLES

1858
1859
1860
1861
1862
1863

Detached EAT Bundles are defined in [draft-ietf-rats-eat]. These are conceptually similar to Entity Attestation
Tokens, but the use is different. An example where a Detached EAT Bundle might be used is when attestinga large amount of data. The Entity Attestation Token returned by the Attestation Service can include a muchsmaller amount of information in the form of a Detached Submodule Digest inside a Submods claim. This
would typically provide a signed hash of the large amount of data. A Relying Party can then be sent the actual
data by other methods, including the use of a Detached EAT Bundle, although other means can be used.

1864
1865
1866

This means that an Attestation Service can be implemented on a memory-constrained device because it nolonger needs to assemble a complete Entity Attestation Token containing the large amount of data. It merely
needs enough resources to be able to compute and store the hash value.

1867
1868
1869

The Relying Party can still assess the trustworthiness of the data because it can compute the hash of the data
it receives separately, then compare it with the value in the Detached Submodule Digest included in theendorsed Entity Attestation Token. If the data is tampered with in transit, the hash values will not match.

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 79 / 91

1870

16 DEPENDENCIES ON OTHER SPECIFICATIONS

1871

This specification has specific dependencies on a number of other specifications.

1872

16.1

1873
1874
1875

The types and encoding defined in [RFC 8949] are used without modification, although this specification does
not reference JSON, JOSE, or JWT. This specification does not require the use of canonical CBOR, although
it is possible that some applications may impose this requirement.

1876

16.2

1877
1878

Structures defined in [RFC 8152] are used without modification, although this specification does not use thosethat relate to Message Authentication Codes (MACs).

1879

16.3

1880

Parameters defined in [RFC 8230] are used without modification.

1881

16.4

1882
1883

The format defined in [RFC 8392] is used without modification. The Claims included from [RFC 8392] are listed
in section 6.3.

1884

16.5

1885

The format defined in [draft-ietf-rats-eat] is used with the following modifications:

1886

Dependency on [RFC 8949]

Dependency on [RFC 8152]

Dependency on [RFC 8230]

Dependency on [RFC 8392]

Dependency on [draft-ietf-rats-eat]• This specification does not reference JSON, JOSE, or JWT.

1887
1888

The rules for CBOR interoperability defined in [draft-ietf-rats-eat] are used without modification. The Claims
included from [draft-ietf-rats-eat] are listed in section 6.3.

1889

16.6

1890

The tag value defined in [draft-birkholz-rats-uccs] is used without modification.

Dependency on [draft-birkholz-rats-uccs]

1891

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 80 / 91

1892

17 IANA CONSIDERATIONS

1893
1894

17.1

Reuse of Concise Binary Object Representation (CBOR)
Registries

1895

The following IANA registries referenced by [RFC 8949] are reused:

1896• CBOR Simple Values Registry

1897• CBOR Tags Registry

1898
1899

17.2

Reuse of CBOR Object Signing and Encryption (COSE)
Registries

1900

The following IANA registries referenced by [RFC 8152] are reused:

1901• Tag assignments added to the CBOR Tags Registry

1902• COSE Header Parameters Registry

1903• COSE Header Algorithm Parameters Registry

1904• COSE Algorithms Registry

1905• COSE Key Common Parameters Registry

1906• COSE Key Type Parameters Registry

1907• COSE Key Types Registry

1908• COSE Elliptic Curves Registry

1909

17.3

Reuse of RSA Algorithms with COSE Messages Registries

1910

The following IANA registries referenced by [RFC 8230] are reused:

1911• Algorithm assignments added to the COSE Algorithms Registry

1912• Key Type assignments added to the COSE Key Types Registry1913• Key Type Parameter assignments added to the COSE Key Type Parameters Registry

1914

17.4

Reuse of CBOR Web Token (CWT) Registries

1915

The following IANA registries referenced by [RFC 8392] are reused:

1916• CBOR Web Token (CWT) Claims Registry

1917• Tag assignments added to the CBOR Tags Registry

1918

17.5

1919

The following IANA registries referenced by [draft-ietf-rats-eat] are reused:

1920

Reuse of Entity Attestation Token (EAT) Registries• Claim assignments added to the CWT Claims Registry

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 81 / 91

1921

17.6

1922

The following IANA registries referenced by [draft-birkholz-rats-uccs] are reused:

1923

Reuse of Unprotected CWT Claims Set (UCCS) Registries• Values for Tags

1924

17.7

Claims Registered by This Document

1925

This document registers a single claim in the IANA CWT registry:

1926
1927
1928
1929
1930
1931

Claim Name: globalplatform_component
Claim Description: This claim holds an array of CBOR maps in which each array entry holds a map containing
claims about a GlobalPlatform component that is within the boundary of the enclosing Entity Attestation Token.
Claim Key: TBC
Change Controller: IESG
Specification Document: This Document <ADD CROSS REFERENCE>

1932

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 82 / 91

1933

Annex A

CONFIGURATIONS

1934
1935
1936

This document defines Claims and mechanisms for signing and encryption, but imposes no requirements on
support. Configuration documents could be created for specific Attestation use cases that do impose
restrictions. Such configurations could define:1937• Which Claims are mandatory, optional, or not allowed

1938• Which signing algorithm (if any) is to be used1939

• Which encryption algorithm (if any) is to be used1940

• Which MAC algorithm (if any) is to be used1941

• Which Operations are allowed1942

For example, a configuration for a TEE Entity Attestation Parcel could include the following:

1943
1944

Table A-1 places restrictions on Claims for a TEE EAP.

1945

Table A-1: Restrictions on Claims (Example)
Claim

Inclusion

TEE API Version

MandatoryTEE Description

Optional

TEE Device ID

Mandatory

1946
1947
1948
1949
1950

Table A-2 places restrictions on signing algorithms for a TEE EAP. The choice of algorithm isimplementation dependent. A TEE Claims Set SHALL be signed, and the algorithm SHALL be indicated in
the COSE protected header.
Table A-2: Restrictions on Signing Algorithms (Example)
Signing Algorithm

Use

ECDSA with SHA-256

Optional

ECDSA with SHA-384

Optional

ECDSA with SHA-512

Optional

1951
1952
1953
1954
1955

Table A-3 places restrictions on encryption algorithms for a TEE EAP. The choice of algorithm isimplementation dependent. A TEE Claims Set may be encrypted; if it is, the algorithm SHALL be indicatedin the COSE protected header.
Table A-3: Restrictions on Encryption Algorithms (Example)
Encryption Algorithm

Use

AES-GCM with at least 256-bit key

Optional

AES-CCM with at least 256-bit key

Optional

1956

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 83 / 91

1957

Annex B

EXAMPLES

1958

This annex provides examples of:1959• Claims Sets

1960

• Unendorsed Claims Sets

1961

• Entity Attestation Tokens

1962

B.1

1963

In the examples below, all signatures are computed using the NIST P-256 elliptic curve key:

1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983

Example Claims Sets{
1 : 2,
2 : “signatureKey”,-1 : 1,-2 : h’106221229e9205c5387e3be4ab2045a3921e7531bb59055086516d964236aac8’,-3 : h’6698ef082482665dff8b10825397229093e3dd9e70f0f7b290f40eb2ed672193’,-4 : h’bf14d67e2ddc8e6683ef574961ff698f61cdd11e9d9c167272e61df0844f4a77’}
In the examples below, all ciphertext is computed using the 128-bit symmetric key:{
1 : 4,
2 : “encryptionKey”,-1 : h’02d7e8392c53cbc9121e33749e0cf4d5’}
In the examples below, all MACs are computed using the 256-bit symmetric key:{
1 : 4,
2 : “macKey”,-1 : h’ 2923be84e16cd6ae529049f1f1bbe9ebb3a6db3c870c3e99245e0d1c06b747de’
}

1984

B.1.1

1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002

{

Example Flat SE Claims Set/ Security Rating / 1000 : 15,/ SE IIN / 1100 : h'11ee11ee11ee11ee11ee11ee11ee11ee',/ SE CIN / 1101 : h'22dd22dd22dd22dd22dd22dd22dd22dd',/ SE Secure Channel Protocols / 1106 :[{/ SCP Type / 1: 112,
/ SCP Options / 2: h'53ae32'},{/ SCP Type / 1: 3,/ SCP Options / 2: h'91b8a402',/ SCP SCP03 Keys / 3: h'737337177172'},{/ SCP Type / 1: 129,
/ SCP Options / 2: h'a07eba9e8ae3',

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 84 / 91

2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029

/ SCP SCP81 TLS Suites / 4: h'91b8a402',/ SCP SCP81 Max Key Length / 5: 128}}],/ SE Type / 1115 : 10,/ SE Card Lifecycle State / 1121 : 10,/ SE Supplementary Security Domains / 1123 :[{/ Application ID / 1: h'00112233445566778899aabbccddeeff',/ Recognition Data / 2: h'21e4918cda74da12',/ Key Derivation Data / 3: h'a07eba9e8ae3',/ Key Information Data / 4: h'737337177172',/ Default KVN / 5: 3,/ Default KVN Sequence / 6: h'91b8a402'},{/ Application ID / 1: h'112233445566778899aabbccddeeff00',/ Recognition Data / 2: h'737337177172',/ Key Derivation Data / 3: h'a9301412789124',/ Key Information Data / 4: h'02d41e4120db94e1cc24',/ Default KVN / 5: 18,/ Default KVN Sequence / 6: h'bd9124afe881a991'}]

CBOR encoded value:

2030
2031
2032
2033
2034
2035

a71903e80f19044c5011ee11ee11ee11ee11ee11ee11ee11ee19044d5022dd22dd22dd22dd22d
d22dd22dd22dd19045283a2011870024353ae32a30103024491b8a4020346737337177172a401
18810246a07eba9e8ae3044491b8a40205188019045b0a1904610a19046382a60150001122334
45566778899aabbccddeeff024821e4918cda74da120346a07eba9e8ae3044673733717717205
03064491b8a402a60150112233445566778899aabbccddeeff0002467373371771720347a9301
412789124044a02d41e4120db94e1cc2405120648bd9124afe881a991

2036

B.1.2

2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057

{

Example Flat TEE Claims Set/ Security Rating / 1000 : 10,/ TEE Root Security Domains / 1203 :[h'03a29483e29814de9b214b367af4228b'],/ TEE Lifecycle State / 1204 : 1,
/ TEE Implementation Properties / 1216 :{"CryptoLibraryVersion": 293,
"CryptoLibraryName": "AceCryptoLibrary","AliceLoginCredentials":{"loginMethod": 7,"uuid": h'00ff00ff00ff00ff00ff00ff00ff00ff'}},/ TEE Trusted Applications / 1217 :[{/ TA Identifier / 1: h'44bb44bb44bb44bb44bb44bb44bb44bb',

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 85 / 91

2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089

}

/ TA Parent / 2: h'bb44bb44bb44bb44bb44bb44bb44bb44',/ TA Lifecycle State / 3: 2,/ TA Version / 4: "Beta 0.9"},{
/ TA Identifier / 1: h'33cc33cc33cc33cc33cc33cc33cc33cc',/ TA Parent / 2: h'cc33cc33cc33cc33cc33cc33cc33cc33',/ TA Lifecycle State / 3: 0,/ TA Version / 4: "Production 2.5.1"}],/ TEE Security Domains / 1218 :[{/ SD Identifier / 1: h'00112233445566778899aabbccddeeff',/ SD Recognition Data / 2: h'21e4918cda74da12',/ SD Key Derivation Data / 3: h'a07eba9e8ae3',/ SD Key Information Data / 4: h'737337177172',/ SD Default KVN / 5: 3,/ SD Default KVN Sequence / 6: h'91b8a402'},{/ SD Identifier / 1: h'112233445566778899aabbccddeeff00',/ SD Recognition Data / 2: h'737337177172',/ SD Key Derivation Data / 3: h'a9301412789124',/ SD Key Information Data / 4: h'02d41e4120db94e1cc24',/ SD Default KVN / 5: 18,/ SD Default KVN Sequence / 6: h'bd9124afe881a991'}]

CBOR encoded value:

2090
2091
2092
2093
2094
2095
2096
2097
2098
2099

a61903e80a1904b3815003a29483e29814de9b214b367af4228b1904b4011904c0a3744372797
0746f4c69627261727956657273696f6e1901257143727970746f4c6962726172794e616d6570
41636543727970746f4c69627261727975416c6963654c6f67696e43726564656e7469616c73a
26b6c6f67696e4d6574686f640764757569645000ff00ff00ff00ff00ff00ff00ff00ff1904c1
82a4015044bb44bb44bb44bb44bb44bb44bb44bb0250bb44bb44bb44bb44bb44bb44bb44bb440
30204684265746120302e39a4015033cc33cc33cc33cc33cc33cc33cc33cc0250cc33cc33cc33
cc33cc33cc33cc33cc330300047050726f64756374696f6e20322e352e311904c282a60150001
12233445566778899aabbccddeeff024821e4918cda74da120346a07eba9e8ae3044673733717
71720503064491b8a402a60150112233445566778899aabbccddeeff000246737337177172034
7a9301412789124044a02d41e4120db94e1cc2405120648bd9124afe881a991

2100

B.1.3

2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112

{

Example Claims Set with Subclaims/ Security Rating / 1000 : 5,
/ Cert DLoA / 1300 :{1: "MyPlatformLabel",
2: "http://www.dloaregistrar.com"},/ location / 264 :{/ latitude / 1: 34.42874324000000,/ longitude / 2: -109.9832743250000}

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 86 / 91

2113
2114

}
CBOR encoded value:

2115
2116
2117

a31903e805190514a2016f4d79506c6174666f726d4c6162656c02781c687474703a2f2f77777
72e646c6f617265676973747261722e636f6d190108a201fb404136e10ef9172e02fbc05b7eed
f76f37c6

2118

B.1.4

2119

This example uses the following Claims Set for “mySubmodule1”:

2120
2121
2122
2123

{
}

Example Claims Set with Submodules/ issuedat / 6: 1444064944

This example uses the following Claims Set for “mySubmodule2”:

2124
2125
2126
2127
2128
2129

Nested EAT Private Message Key for ECDSA (generated according to [RFC 6979]):2130

f70d0ec2032afad5d0756fde00bb8563aeccee2c43db7e27d0288e296c9aa4e1

2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162

{

}

/ issuer / 1: "ACME Corporation",/ subject/ 2: "CWT Example",/ audience/ 3: "GlobalPlatform"{/ Security Rating / 1000 : 5,
/ Cert DLoA / 1300 :{1: "MyPlatformLabel",
2: "http://www.dloaregistrar.com"},/ submods / 266 :{"mySubmodule1":{/ iat / 6: 1444064944},"mySubmodule2":
61(
18(
[
/ protected / h'a10126',/ unprotected / {4: 'signatureKey'},/ payload /h'a3017041434d4520436f72706f726174696f6e026b435754204578616d706c65036e476
c6f62616c506c6174666f726d',/ signature /h'95d3a110f25581f5ea478997772478481e5dc68600514c1191191a3aded63c43d70bf50
0afcdb105aa264f56e57bf88e28b868983b3935b7c168d9d6b12a5df1'
]
)
)
}
}

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 87 / 91

2163
2164
2165
2166
2167
2168
2169
2170

CBOR encoded value:a31903e805190514a2016f4d79506c6174666f726d4c6162656c02781c687474703a2f2f77777
72e646c6f617265676973747261722e636f6d19010aa26c6d795375626d6f64756c6531a1061a
5612aeb06c6d795375626d6f64756c6532d83dd28443a10126a1044c7369676e61747572654b6
5795830a3017041434d4520436f72706f726174696f6e026b435754204578616d706c65036e47
6c6f62616c506c6174666f726d584095d3a110f25581f5ea478997772478481e5dc68600514c1
191191a3aded63c43d70bf500afcdb105aa264f56e57bf88e28b868983b3935b7c168d9d6b12a
5df1

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 88 / 91

2171

B.2

2172

All examples in this section use the Claims Set shown below.

2173
2174
2175
2176
2177
2178

{

2179

B.2.1

2180
2181
2182
2183
2184
2185
2186

{

2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200

Example Unendorsed Claims Sets

/ Security Rating / 1000 : 5,
/ MUD File URL / 1001 :"https://mudfile.globalplatform.org/download/example.json",/ Debug Status / 263 : 3}

Example Unendorsed Claims Set/ Security Rating / 1000 : 5,
/ MUD File URL / 1001 :"https://mudfile.globalplatform.org/download/example.json",/ Debug Status / 263 : 3}
CBOR encoded value:a31903e8051903e9783868747470733a2f2f6d756466696c652e676c6f62616c706c6174666f7
26d2e6f72672f646f776e6c6f61642f6578616d706c652e6a736f6e19010703

B.2.2

Example Tagged Unendorsed Claims Set

601 ({/ Security Rating / 1000 : 5,
/ MUD File URL / 1001 :"https://mudfile.globalplatform.org/download/example.json",/ Debug Status / 263 : 3})
CBOR encoded value:d90259a31903e8051903e9783868747470733a2f2f6d756466696c652e676c6f62616c706c617
4666f726d2e6f72672f646f776e6c6f61642f6578616d706c652e6a736f6e19010703

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 89 / 91

2201

B.3

Example Entity Attestation Tokens

2202

All examples in this section use the Claims Set shown below.

2203
2204
2205
2206
2207
2208

{

2209

B.3.1

2210

Private Message Key for ECDSA (generated according to [RFC 6979]):/ Security Rating / 1000 : 5,
/ MUD File URL / 1001 :"https://mudfile.globalplatform.org/download/example.json",/ Debug Status / 263 : 3
}

2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226

4a7a49ff901026624d75ba06c72907b9ad38e4acebb50d0b2d535b70655d6c27[/ protected / h'a10126' / {
1: -7
} / ,
/ unprotected / {4: 'signatureKey'},/ payload /h'a31903e8051903e9783868747470733a2f2f6d756466696c652e676c6f62616c706c617
4666f726d2e6f72672f646f776e6c6f61642f6578616d706c652e6a736f6e19010703',/ signature /h'1c8781dfffc71d78429ead67341dbb4be0ba9fb7750324252b242caa0bb2c0d422fd951
363ae04e2ba3c340bee19c91d91644baa79a540eb6d9c71e23a5231a4']
CBOR encoded value:

2227
2228
2229
2230
2231

8443a10126a1044c7369676e61747572654b65795846a31903e8051903e9783868747470733a2
f2f6d756466696c652e676c6f62616c706c6174666f726d2e6f72672f646f776e6c6f61642f65
78616d706c652e6a736f6e1901070358401c8781dfffc71d78429ead67341dbb4be0ba9fb7750
324252b242caa0bb2c0d422fd951363ae04e2ba3c340bee19c91d91644baa79a540eb6d9c71e2
3a5231a4

2232

B.3.2

2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245

[

2246
2247
2248

Example Signed Token

Example Encrypted Token/ protected / h'a1010a' / {
1: 10
} / ,
/ unprotected / {5: h'd49fd4a4597e35cf3222f4cccf'},/ ciphertext /h'087c54463077169fc3166a46e101fead07c2eb07c53cb3ab49da8e8e6d3d0cccbc3cfbd
38abd6c81fadf53a3901919c73df507ff4768cb28ad97a45d0f5022d6192061d4e419504c
9e5fee416aa4']
CBOR encoded value:
8343a1010aa1054dd49fd4a4597e35cf3222f4cccf584e087c54463077169fc3166a46e101fea
d07c2eb07c53cb3ab49da8e8e6d3d0cccbc3cfbd38abd6c81fadf53a3901919c73df507ff4768
cb28ad97a45d0f5022d6192061d4e419504c9e5fee416aa4
Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 90 / 91

2249

B.3.3

2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261

[

Example MACed Token/ protected / h'a10105' / {
1: 5
} / ,
/ unprotected / {},/ payload /h'a31903e8051903e9783868747470733a2f2f6d756466696c652e676c6f62616c706c617
4666f726d2e6f72672f646f776e6c6f61642f6578616d706c652e6a736f6e19010703',/ tag /
h'722172794345d5c890afd2911a0a3d0a973d884a0ddfb512682e91f8e0e9012f']
CBOR encoded value:

2262
2263
2264

8443a10105a05846a31903e8051903e9783868747470733a2f2f6d756466696c652e676c6f626
16c706c6174666f726d2e6f72672f646f776e6c6f61642f6578616d706c652e6a736f6e190107
035820722172794345d5c890afd2911a0a3d0a973d884a0ddfb512682e91f8e0e9012f

2265

B.3.4

2266

Private Message Key for ECDSA (generated according to [RFC 6979]):

2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289

Example Signed Then Encrypted Token

4a7a49ff901026624d75ba06c72907b9ad38e4acebb50d0b2d535b70655d6c27[/ protected / h'a1010a' / {
1: 10
} / ,
/ unprotected / {5: h'd49fd4a4597e35cf3222f4cccf'},/ ciphertext /h'0a7c56a494045b13c85a6756ca34ccc3f0d054f6e2fbdbe18df0a5916b3803c1b825e8c
2a7b767b4921338c757786fb3bae150f65733de23f6d5fb5c1f1a2ecc1a2b56b28f759744
eaec17b3cca2818f86634f050835c174496ff375302d8465837d92c0342a2595beb61b27b
08d8aaf10c69a7f95aef25f6bf467bf23d07c196db9e7de6c6931a061b66f21db5aa817da
83890e185614d1afb7e17ed3578b595179185320a2630e8f56c2516885d29710d24e463ff
c0a73ec']
CBOR encoded value:
8343a1010aa1054dd49fd4a4597e35cf3222f4cccf58b90a7c56a494045b13c85a6756ca34ccc
3f0d054f6e2fbdbe18df0a5916b3803c1b825e8c2a7b767b4921338c757786fb3bae150f65733
de23f6d5fb5c1f1a2ecc1a2b56b28f759744eaec17b3cca2818f86634f050835c174496ff3753
02d8465837d92c0342a2595beb61b27b08d8aaf10c69a7f95aef25f6bf467bf23d07c196db9e7
de6c6931a061b66f21db5aa817da83890e185614d1afb7e17ed3578b595179185320a2630e8f5
6c2516885d29710d24e463ffc0a73ec

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.

Entity Attestation Protocol Specification
Public Review #2 v0.0.0.26
Page 91 / 91

2290

B.3.5

2291
2292

This example is the same as example B.3.2 except that it adds the CBOR Tag that indicates an Entity
Attestation Token, and thus also the CBOR Tag that indicates a COSE_Encrypt0 message.

2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312

Example Tagged Encrypted Token

61(
16(
[

/ protected / h'a1010a' / {
1: 10
} / ,
/ unprotected / {5: h'd49fd4a4597e35cf3222f4cccf'},/ ciphertext /h'087c54463077169fc3166a46e101fead07c2eb07c53cb3ab49da8e8e6d3d0cccbc3cfbd
38abd6c81fadf53a3901919c73df507ff4768cb28ad97a45d0f5022d6192061d4e419504c
9e5fee416aa4']))
CBOR encoded value:
d83dd08343a1010aa1054dd49fd4a4597e35cf3222f4cccf584e087c54463077169fc3166a46e
101fead07c2eb07c53cb3ab49da8e8e6d3d0cccbc3cfbd38abd6c81fadf53a3901919c73df507
ff4768cb28ad97a45d0f5022d6192061d4e419504c9e5fee416aa4

2313

Copyright  2018-2024 GlobalPlatform, Inc. All Rights Reserved.

This document (and the information herein) is subject to updates, revisions, and extensions by GlobalPlatform, and may be disseminated without
restriction. Use of the information herein (whether or not obtained directly from GlobalPlatform) is subject to the terms of the corresponding
GlobalPlatform license agreement on the GlobalPlatform website (the “License”). Any use (including but not limited to sublicensing) inconsistent
with the License is strictly prohibited.