



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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [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, <https://www.rfc-editor.org/info/rfc9334>.

   [RFC9711]  Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
              Wallace, "The Entity Attestation Token (EAT)", RFC 9711,
              DOI 10.17487/RFC9711, April 2025,
              <https://www.rfc-editor.org/info/rfc9711>.

Author's Address

   David Lu
   Futurewei
   Email: dlu@futurewei.com


















Lu                      Expires 22 November 2026               [Page 13]
