Network Working Group D. Lu Internet-Draft Futurewei Intended status: Standards Track May 2026 Expires: 22 November 2026 Cross-Platform Mobile Attestation Normalization draft-lu-rats-cross-platform-attestation-00 Abstract This document defines a set of requirements and a normalized Entity Attestation Token (EAT) profile for representing attestation evidence produced by attestation services across heterogeneous mobile platforms, including platform-specific mechanisms such as Google Play Integrity, Apple App Attest, Apple DeviceCheck, and other OEM- specific or third-party attestation services. The goal is to enable interoperable processing of attestation evidence by verifiers and relying parties without requiring changes to the underlying attestation providers. This document specifies a canonical mapping of platform-specific attestation claims into EAT claims and defines normalization rules intended to improve consistency across mobile ecosystems. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 2 November 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Lu Expires 22 November 2026 [Page 1] Internet-Draft Cross-Platform Attestation May 2026 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 1.2. Objectives . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Normalized EAT Profile . . . . . . . . . . . . . . . . . . . 4 4.1. General Requirements . . . . . . . . . . . . . . . . . . 5 4.2. Claims . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2.1. Required Claims Summary . . . . . . . . . . . . . . . 5 4.2.2. Device Attestation Extension Claims Summary . . . . . 6 4.2.3. Application Attestation Extension Claims Summary . . 6 4.2.4. Optional Claims Summary . . . . . . . . . . . . . . . 6 4.2.5. entity-type . . . . . . . . . . . . . . . . . . . . . 7 4.2.6. issuer . . . . . . . . . . . . . . . . . . . . . . . 7 4.2.7. ueid . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2.8. entity-name . . . . . . . . . . . . . . . . . . . . . 8 4.2.8.1. Google Play Integrity Mapping . . . . . . . . . . 8 4.2.9. iat . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2.10. eat_nonce . . . . . . . . . . . . . . . . . . . . . . 8 4.2.10.1. Google Play Integrity Mapping . . . . . . . . . 8 4.2.11. origination . . . . . . . . . . . . . . . . . . . . . 8 4.2.12. trust-level . . . . . . . . . . . . . . . . . . . . . 8 4.2.13. dbgstat . . . . . . . . . . . . . . . . . . . . . . . 9 4.2.14. oemid . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2.15. hwmodel . . . . . . . . . . . . . . . . . . . . . . . 9 4.2.16. hwversion . . . . . . . . . . . . . . . . . . . . . . 10 4.2.17. oemboot . . . . . . . . . . . . . . . . . . . . . . . 10 4.2.18. swname . . . . . . . . . . . . . . . . . . . . . . . 10 4.2.19. swversion . . . . . . . . . . . . . . . . . . . . . . 10 4.2.20. location . . . . . . . . . . . . . . . . . . . . . . 11 4.2.21. uptime . . . . . . . . . . . . . . . . . . . . . . . 11 4.2.22. dloas . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2.23. submods . . . . . . . . . . . . . . . . . . . . . . . 11 5. Trust Normalization . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 Lu Expires 22 November 2026 [Page 2] Internet-Draft Cross-Platform Attestation May 2026 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. Normative References . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction 1.1. Problem Statement Attestation is required by many mobile applications to evaluate how trustworthy the device on which they run is, and how trustworthy the applications and devices with which they interact are. An entity that cannot be attested to be in a trustworthy state can be given reduced permissions or degraded service. This document assumes familiarity with the attestation architecture, definitions, and models described in the Remote ATtestation procedureS (RATS) Architecture [RFC9334] and the Entity Attestation Token (EAT) [RFC9711]. Mobile platform attestation mechanisms are fragmented across ecosystems, including: * Google Play Integrity * Apple App Attest and Apple DeviceCheck * Third-party and OEM-specific attestation services Each system uses distinct formats, encodes claims differently, and applies different trust semantics. This fragmentation creates problems for cross-platform attestation mechanisms, including divergent verification logic, no unified enforcement of trust, and lack of portability of trust evaluations. 1.2. Objectives This document defines: * A normalization layer based on the architecture described in [RFC9334] * A mapping of platform-specific attestation outputs into EAT claims as defined in [RFC9711] * Semantic rules to align common attestation signals This document does not: Lu Expires 22 November 2026 [Page 3] Internet-Draft Cross-Platform Attestation May 2026 * Define a new attestation protocol * Define trust scoring or policy engines * Modify root-of-trust mechanisms 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document uses terminology from [RFC9334] and [RFC9711]. Platform Attestation Provider A system that produces attestation evidence, such as Google Play Integrity or Apple App Attest. Normalized Evidence An EAT-compliant representation of attestation data derived from a platform-specific format. 3. Architecture 3.1. Roles This document assumes the same roles as those defined in [RFC9334] and [RFC9711]. +------------+ +------------+ +----------------+ +---------------+ | Attester | --> | Verifier | --> | Normalization | --> | Relying Party | | | | | | Layer | | | +------------+ +------------+ +----------------+ +---------------+ Figure 1: Data Flow 1. The Attester generates evidence for attestation. 2. The Verifier evaluates evidence and generates attestation results, which can be in a provider-specific format. 3. The normalization layer maps the attestation result and associated evidence into Normalized EAT. 4. The Relying Party applies policy to the Normalized EAT. 4. Normalized EAT Profile Lu Expires 22 November 2026 [Page 4] Internet-Draft Cross-Platform Attestation May 2026 4.1. General Requirements A normalized EAT profile: * MUST be encoded as a signed token, either in CWT or JWT format. * MUST preserve the integrity of the original attestation evidence. * MUST include provenance information for the original attestation provider. * SHOULD use deterministic normalization rules for claim mapping. 4.2. Claims 4.2.1. Required Claims Summary The following claims MUST be present in the normalized EAT profile. +=============+===========+====================================+ | Claim | Type | Description | +=============+===========+====================================+ | entity-type | enum | Type of attested entity: DEVICE or | | | | APPLICATION. | +-------------+-----------+------------------------------------+ | issuer | text | Attestation provider identifier. | +-------------+-----------+------------------------------------+ | ueid | bytes | Globally unique identifier for the | | | | entity. | +-------------+-----------+------------------------------------+ | entity-name | text | Device or application instance | | | | identifier. | +-------------+-----------+------------------------------------+ | iat | timestamp | Time of issuance. | +-------------+-----------+------------------------------------+ | eat_nonce | text or | Challenge binding. | | | array | | +-------------+-----------+------------------------------------+ | origination | text | Source platform. | +-------------+-----------+------------------------------------+ | trust-level | enum | Abstracted entity integrity level: | | | | UNTRUSTED, LOW, MEDIUM, or HIGH. | +-------------+-----------+------------------------------------+ | dbgstat | enum | Debug state. | +-------------+-----------+------------------------------------+ Table 1: Required Claims Summary Lu Expires 22 November 2026 [Page 5] Internet-Draft Cross-Platform Attestation May 2026 4.2.2. Device Attestation Extension Claims Summary The following claims MUST be present when entity-type is DEVICE. +===========+======+====================================+ | Claim | Type | Description | +===========+======+====================================+ | oemid | text | Identifier of the Original | | | | Equipment Manufacturer. | +-----------+------+------------------------------------+ | hwmodel | text | Identifier set by the manufacturer | | | | and associated with the oemid. | +-----------+------+------------------------------------+ | hwversion | text | Identifier distinguishing versions | | | | of the hwmodel. | +-----------+------+------------------------------------+ | oemboot | enum | Bootloader status: TRUE or FALSE. | +-----------+------+------------------------------------+ Table 2: Device Attestation Extension Claims Summary 4.2.3. Application Attestation Extension Claims Summary The following claims MUST be present when entity-type is APPLICATION. +===========+======+===============================================+ | Claim | Type | Description | +===========+======+===============================================+ | swname | text | Identifier of the software being attested. | +-----------+------+-----------------------------------------------+ | swversion | text | Identifier distinguishing versions of swname. | +-----------+------+-----------------------------------------------+ Table 3: Application Attestation Extension Claims Summary 4.2.4. Optional Claims Summary The following claims MAY be present when supported by the originating attestation provider and when permitted by relying-party policy. Lu Expires 22 November 2026 [Page 6] Internet-Draft Cross-Platform Attestation May 2026 +==========+=========+===========================================+ | Claim | Type | Description | +==========+=========+===========================================+ | location | text | Geographic position of the entity. | +----------+---------+-------------------------------------------+ | uptime | integer | Time since the entity was last booted. | +----------+---------+-------------------------------------------+ | dloas | array | Verifier Digital Letters of Approval. | +----------+---------+-------------------------------------------+ | submods | map | Representation of subsystem architecture. | +----------+---------+-------------------------------------------+ Table 4: Optional Claims Summary 4.2.5. entity-type The entity-type claim is an enum field that identifies the type of entity from which the Attester collects claims. This entity is the Target Environment in RATS terminology. APPLICATION Indicates that the Target Environment of the attestation is a software application. DEVICE Indicates that the Target Environment of the attestation is a device. A device in this context includes physical hardware and virtual machines. 4.2.6. issuer The issuer claim is a text field identifying the attestation service that originally issued the claim, such as Google Play Integrity. 4.2.7. ueid The ueid claim is a unique identifying value generated according to the rules for creating UEIDs in Section 4.2.1.1 of [RFC9711] and consumed according to the rules for consuming UEIDs in Section 4.2.1.2 of [RFC9711]. UEIDs are treated as globally unique opaque byte strings. A consumer MUST NOT rely on externally visible structure in a UEID unless such structure is explicitly specified by the issuer and permitted by policy. Lu Expires 22 November 2026 [Page 7] Internet-Draft Cross-Platform Attestation May 2026 4.2.8. entity-name The entity-name claim is a text string naming the entity for which the attestation is issued. Unlike ueid, entity-name does not have uniqueness requirements and MUST NOT be used as the sole basis for strict entity identification. 4.2.8.1. Google Play Integrity Mapping For Google Play Integrity, this claim SHOULD be populated with the requestDetails.requestPackageName attribute when it is available. 4.2.9. iat The iat claim represents the time at which the originating attestation provider issued the attestation result. It uses the EAT and JWT NumericDate representation unless the selected serialization profile specifies otherwise. 4.2.10. eat_nonce The eat_nonce claim is a text string or array of text strings conforming to the eat_nonce claim definition in Section 4.1 of [RFC9711]. 4.2.10.1. Google Play Integrity Mapping For Google Play Integrity standard API requests, this claim SHOULD be populated with the requestDetails.requestHash attribute. For classic API requests, this claim SHOULD be populated with the requestDetails.nonce attribute. 4.2.11. origination The origination claim is a text field identifying the platform that originally issued the attestation. Integrity service providers do not necessarily identify themselves explicitly in verdict payloads, so this document does not define a mandatory syntax for this claim. The primary use of this claim is as an informational annotation to support provenance tracking for an attestation verdict. 4.2.12. trust-level The trust-level claim is an enum indicating an abstraction of the device or application integrity level issued by the Verifier. The possible values are UNTRUSTED, LOW, MEDIUM, and HIGH. Lu Expires 22 November 2026 [Page 8] Internet-Draft Cross-Platform Attestation May 2026 These values are derived from proprietary claims made by device and application integrity services. The derivation of these trust values is specified in Section 5. The derivation MUST be transparent and SHOULD be as consistent as possible with existing usage of proprietary claims. The intended use of this claim is to provide a portable replacement for proprietary trust-level claims from integrity services. 4.2.13. dbgstat The dbgstat claim is an enum indicating the entity-wide status of debug facilities. This applies to both device and application entities. The characterization of this claim SHOULD conform to the dbgstat claim defined in Section 4.2.9 of [RFC9711]. 4.2.14. oemid The oemid claim is a text field identifying the Original Equipment Manufacturer of the entity being attested. This claim MUST be populated when entity-type is DEVICE. The format and contents of this claim MUST conform to the oemid claim defined in Section 4.2.3 of [RFC9711]. When entity-type is not DEVICE, this claim is OPTIONAL and MAY be absent. The hwmodel and oemboot claims can depend on this claim. 4.2.15. hwmodel The hwmodel claim is a text field identifying specific hardware models, products, and variants of the entity. It is used to distinguish entities that otherwise might have the same name. This claim MUST be populated when entity-type is DEVICE. The format and contents of this claim MUST conform to the hwmodel claim defined in Section 4.2.4 of [RFC9711]. When entity-type is not DEVICE, this claim is OPTIONAL and MAY be absent. Lu Expires 22 November 2026 [Page 9] Internet-Draft Cross-Platform Attestation May 2026 4.2.16. hwversion The hwversion claim is a text field identifying specific versions of the hardware identified by hwmodel. It is used to distinguish different versions of the same hardware model. This claim MUST be populated when entity-type is DEVICE. The format and contents of this claim MUST conform to the hwversion claim defined in Section 4.2.5 of [RFC9711]. When entity-type is not DEVICE, this claim is OPTIONAL and MAY be absent. 4.2.17. oemboot The oemboot claim represents the bootloader status or comparable OEM- controlled boot state of the device. When supported by the originating attestation provider, this claim MUST indicate whether the attested device is in an OEM-approved boot state. This claim MUST be populated when entity-type is DEVICE and the originating attestation evidence contains sufficient information to derive it. If the originating evidence does not contain sufficient information, the claim MUST be absent rather than inferred. 4.2.18. swname The swname claim is a text field identifying the name used by the attested software entity. It is a free-form value with no predefined structure and provides no guarantee of uniqueness or precision. This claim MUST be populated when entity-type is APPLICATION. The format and contents of this claim MUST conform to the swname claim defined in Section 4.2.6 of [RFC9711]. When entity-type is not APPLICATION, this claim is OPTIONAL and MAY be absent. 4.2.19. swversion The swversion claim is a text field identifying specific versions of the software identified by swname. It is used to distinguish different versions of the same software. This claim MUST be populated when entity-type is APPLICATION. Lu Expires 22 November 2026 [Page 10] Internet-Draft Cross-Platform Attestation May 2026 The format and contents of this claim MUST conform to the swversion claim defined in Section 4.2.7 of [RFC9711]. When entity-type is not APPLICATION, this claim is OPTIONAL and MAY be absent. 4.2.20. location The location claim is an OPTIONAL text field describing the geographic position of the entity when such information is supplied by the originating attestation provider and permitted by policy. Because location information can be privacy-sensitive, implementations SHOULD omit this claim unless it is necessary for a specific relying-party decision. 4.2.21. uptime The uptime claim is an OPTIONAL integer field representing the time since the entity was last booted. The unit and source of this value MUST be documented by the normalization layer. 4.2.22. dloas The dloas claim is an OPTIONAL array containing Verifier Digital Letters of Approval when such information is provided by the verification process and is relevant to relying-party policy. 4.2.23. submods The submods claim is an OPTIONAL map representing subsystem architecture. When present, the structure and semantics of submodules SHOULD follow the submodule conventions defined for EAT. 5. Trust Normalization This section describes a policy for producing the trust-level claim in the Normalized EAT. It is a declarative policy rather than an imperative implementation algorithm. All proprietary trust signals that are normalized by this profile MUST map into one of the following levels: * UNTRUSTED * LOW * MEDIUM Lu Expires 22 November 2026 [Page 11] Internet-Draft Cross-Platform Attestation May 2026 * HIGH Abstraction methods used to produce this normalization MUST be deterministic, documented, and consistent within the same Verifier. Consistency means that if a particular proprietary trust signal results in a particular appraisal by a Relying Party, the normalized trust signal resulting from that same proprietary signal SHOULD result in the same appraisal by the same Relying Party. For example, if a banking application would grant a device permission to view account balances in a proprietary attestation architecture, the same device ought to receive the same permission after normalization, assuming the Relying Party policy is otherwise unchanged. 6. Security Considerations A normalization layer introduces semantic translation risk. Implementations MUST ensure that normalization does not weaken the security properties of the originating attestation provider or convert provider-specific uncertainty into unwarranted confidence. Relying Parties SHOULD retain access to the original attestation evidence, or to a cryptographically protected reference to that evidence, when feasible. This supports auditability, dispute resolution, and forensic analysis. Normalization logic MUST be protected against substitution attacks in which a claim from one platform or provider is represented as if it originated from another platform or provider. The issuer and origination claims are therefore security-relevant and MUST be integrity-protected by the signed token. 7. Privacy Considerations Attestation evidence can contain persistent device identifiers, application identifiers, platform metadata, and location-related information. These values can enable correlation across services. Implementations SHOULD minimize retention and disclosure of persistent identifiers and SHOULD avoid adding cross-platform correlation vectors during normalization. Optional claims such as location SHOULD be omitted unless needed for a specific relying-party policy decision and permitted by applicable privacy requirements. Lu Expires 22 November 2026 [Page 12] Internet-Draft Cross-Platform Attestation May 2026 8. IANA Considerations This document has no IANA actions at this time. If future versions of this document request registration of new EAT claims, those registrations will be specified in this section. 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, . [RFC9711] Lundblade, L., Mandyam, G., O'Donoghue, J., and C. Wallace, "The Entity Attestation Token (EAT)", RFC 9711, DOI 10.17487/RFC9711, April 2025, . Author's Address David Lu Futurewei Email: dlu@futurewei.com Lu Expires 22 November 2026 [Page 13]