Agent Unification, Runtime, and Operational Responsibility Attestation (AURORA)
draft-khera-aurora-00

Network Working Group                                           A. Khera
Internet-Draft                                               5 June 2026
Intended status: Standards Track                                        
Expires: 7 December 2026

 Agent Unification, Runtime, and Operational Responsibility Attestation
                                (AURORA)
                         draft-khera-aurora-00

Abstract

   This document specifies the Agent Unification, Runtime, and
   Operational Responsibility Attestation (AURORA) protocol, a dual-
   layer security framework for the machine-to-machine (M2M) ecosystem.
   The core architectural mandate of this protocol is that an agent
   should be able to prove its authority, scope, and runtime integrity.

   Existing agent protocols enable communication syntax and identity
   propagation; however, they fail to provide a standardized mechanism
   for proving that a network transaction or payload was generated and
   transmitted by a software agent executing within a verified,
   hardware-attested runtime environment, nor do they map clear
   boundaries of principal attribution.  AURORA solves this by unifying
   hardware-enclave-backed Runtime Integrity Attestation with scoped,
   cryptographically bound Authority Delegation.

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 7 December 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Khera                    Expires 7 December 2026                [Page 1]
Internet-Draft                   AURORA                        June 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.  Conventions Used  . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Problem Statements  . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Problem Statement 1: The Puppet Problem (Runtime Integrity
           Vulnerability)  . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Problem Statement 2: The Rogue Agent Problem (Authority
           Vulnerability)  . . . . . . . . . . . . . . . . . . . . .   4
   3.  The AURORA Solution: Dual-Layer Protocol Specification  . . .   5
     3.1.  Core Handshake Flow Overview  . . . . . . . . . . . . . .   5
     3.2.  Architecture Layer 1: Runtime Integrity Attestation
           (Mitigating Problem 1)  . . . . . . . . . . . . . . . . .   6
     3.3.  Architecture Layer 2: Authority Attestation (Mitigating
           Problem 2)  . . . . . . . . . . . . . . . . . . . . . . .   8
   4.  Interoperability & System Optimization  . . . . . . . . . . .   9
     4.1.  Agent Capability Declaration  . . . . . . . . . . . . . .   9
     4.2.  Gateway Format Switch Signal  . . . . . . . . . . . . . .  10
     4.3.  Fallback Behavior . . . . . . . . . . . . . . . . . . . .  10
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
     5.1.  Network Latency & Clock Drift Mitigation  . . . . . . . .  10
     5.2.  Trusted Computing Base (TCB) Degradation & Enclave
           Recovery  . . . . . . . . . . . . . . . . . . . . . . . .  10
     5.3.  Authority Token Revocation Lifecycle  . . . . . . . . . .  11
     5.4.  Replay Attack Vectors on Multi-Gateway Environs . . . . .  11
     5.5.  Cognitive Puppeteering Vulnerabilities (Prompt
           Injection)  . . . . . . . . . . . . . . . . . . . . . . .  11
     5.6.  Cryptographic Cross-Layer Token Binding . . . . . . . . .  12
   6.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  12
     6.1.  Principal Identity Exposure . . . . . . . . . . . . . . .  12
     6.2.  Enclave Attestation Report Linkability  . . . . . . . . .  12
     6.3.  Financial Metadata Minimization . . . . . . . . . . . . .  12
   7.  Implementation Status . . . . . . . . . . . . . . . . . . . .  12
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  14
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  14

Khera                    Expires 7 December 2026                [Page 2]
Internet-Draft                   AURORA                        June 2026

1.  Introduction

   As autonomous AI agents migrate from isolated testing environments to
   the public open web, network infrastructure must pivot to support
   workloads natively optimized for machine execution.  While emerging
   standards address data semantic translation (e.g., Model Context
   Protocol), they rely entirely on legacy authentication frameworks
   such as static API keys or human-centric OAuth tokens.

   AURORA introduces a standardized architecture to secure agentic
   interactions by requiring parallel proofs of computational provenance
   and explicit operational mandate.

1.1.  Conventions Used

   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.

1.2.  Terminology

   This document uses the following terms:

   Agent (or Connecting Agent)  An autonomous AI software runtime that
      initiates network connections and executes transactions on behalf
      of a human principal without real-time human intervention.

   Principal  The human individual or corporate legal entity that
      authorizes an agent's actions and is cryptographically attributed
      as the authorizing party for each transaction.  Note: AURORA
      establishes attribution, not legal liability.  Determination of
      legal liability from this attribution record is the domain of
      applicable law and courts, not the protocol.

   Target Gateway  The network endpoint or host server that receives and
      validates AURORA protocol handshake payloads before granting
      access to resources or executing transactions.

   Enclave (or Hardware Security Enclave)  A physically isolated,
      tamper-resistant execution environment provided by hardware (e.g.,
      Intel TDX, AMD SEV-SNP, ARM TrustZone) that generates
      cryptographically verifiable attestation reports.

   Delegated Authority Token (DAT)  An immutable, cryptographically
      signed token issued by a human principal that encodes the agent's
      operational scope, financial limits, and expiry.

Khera                    Expires 7 December 2026                [Page 3]
Internet-Draft                   AURORA                        June 2026

   Hardware-Anchored Proof Challenge for Autonomous Hosts (HAPCHA)  The
      Layer 1 mechanism by which a gateway verifies that a response was
      generated by a software agent executing within a hardware-attested
      enclave, within a defined timing ceiling consistent with
      uninterrupted machine execution.

   Attested Execution Duration (AED)  The silicon-measured processing
      delta between nonce ingestion and payload generation, co-signed by
      the enclave chip into the attestation report.

   Puppeteering  An attack where a human adversary injects manual steps
      or latency into a machine-to-machine interaction to manipulate the
      output of an agent while mimicking autonomous execution.

   Trusted Computing Base (TCB)  The set of hardware, firmware, and
      software components critical to the security of an enclave.  A TCB
      downgrade indicates a known vulnerability in one of these layers.

2.  Problem Statements

   The current internet fabric lacks native defenses against two
   critical structural vulnerabilities introduced by autonomous machine
   agents: The Puppet Problem and The Rogue Agent Problem.

2.1.  Problem Statement 1: The Puppet Problem (Runtime Integrity
      Vulnerability)

   Current network endpoints cannot differentiate between a software
   agent executing within a verified hardware enclave and a human
   adversary utilizing automated scripts to mimic machine-originated
   traffic ("puppeteering").

   Without a mechanism to attest the runtime environment of an endpoint,
   systems are exposed to Sybil attacks, data interception, and man-in-
   the-loop payload manipulation.  Legacy CAPTCHAs stop uncoordinated
   bots from mimicking humans, but the internet lacks a standardized
   mechanism to attest that a payload originated from a specific,
   verified software stack --- rather than from a human operator
   proxying requests through automation scripts.

2.2.  Problem Statement 2: The Rogue Agent Problem (Authority
      Vulnerability)

   AI agents operate as dynamic code runtimes capable of planning,
   invoking tools, and committing financial or computational assets.
   When a machine endpoint initiates a binding contract, a target server
   cannot verify under whose authorization the machine is acting, nor
   attribute the transaction to a specific human principal.

Khera                    Expires 7 December 2026                [Page 4]
Internet-Draft                   AURORA                        June 2026

   If an agent suffers a logical loop or context injection and executes
   an unauthorized asset transfer, the receiving server cannot attribute
   the transaction to a specific authorizing human principal.  The
   internet has no standardized, cryptographically attenuated
   authorization token designed for software-mediated delegation ---
   analogous to a scoped "Power of Attorney" --- that would allow post-
   incident attribution.

3.  The AURORA Solution: Dual-Layer Protocol Specification

   AURORA addresses both problem vectors simultaneously using a unified,
   two-key cryptographic handshake.  A request is explicitly rejected
   unless both the Runtime Integrity Layer (Layer 1) and the Mandate
   Layer (Layer 2) are verified concurrently.

3.1.  Core Handshake Flow Overview

   The AURORA protocol execution sequence flows as follows:

Khera                    Expires 7 December 2026                [Page 5]
Internet-Draft                   AURORA                        June 2026

   Connecting Agent             Target Gateway             Enclave Chip
         |                             |                         |
         |--- 1. Initiate Session ---->|                         |
         |     + DAT attached          |                         |
         |     + aurora-accept:        |                         |
         |       [protobuf, json-rpc,  |                         |
         |        json]  (Sec. 4.1)    |                         |
         |                             |                         |
         |<-- 2. Time-Bound Nonce -----|                         |
         |                                                       |
         |--- 3. Ingest Nonce & Generate Output ---------------->|
         |                                                       |
         |<-- 4. Sign Payload + Attestation Report --------------|
         |                                                       |
         |--- 5. Return: Signed Output + Enclave Report + DAT -->|
         |                             |                         |
         |                             |-- [6a. LAYER 1 CHECK]   |
         |                             |   Runtime Integrity     |
         |                             |   - AED: timing verify  |
         |                             |   - Enclave key verify  |
         |                             |   - Nonce binding check |
         |                             |   - RTT ceiling check   |
         |                             |                         |
         |                             |-- [6b. LAYER 2 CHECK]   |
         |                             |   Authority Attestation |
         |                             |   - DAT signature valid |
         |                             |   - Principal identity  |
         |                             |   - Scope & spend limit |
         |                             |   - Chronological ceil. |
         |                             |   - Enclave key binding |
         |                             |                         |
         |                   [Both layers PASS?]                 |
         |                        /          \                   |
         |<-- 7a. ACCEPT ---------            ------> 7b. REJECT |
         |    + aurora-content-type:               Layer fault   |
         |      negotiated format      (Sec. 4.2)  + reason code |
         |    (or fallback: json)      (Sec. 4.3)               |
         |                             |                         |

3.2.  Architecture Layer 1: Runtime Integrity Attestation (Mitigating
      Problem 1)

   To provide cryptographically verifiable evidence that a payload
   originated from a software agent executing within a hardware-attested
   runtime environment, the protocol MUST enforce a rigorous
   computational speed challenge designated the Hardware-Anchored Proof
   Challenge for Autonomous Hosts (HAPCHA).  HAPCHA does not claim to
   prove machine consciousness or intent; it attests that the responding

Khera                    Expires 7 December 2026                [Page 6]
Internet-Draft                   AURORA                        June 2026

   endpoint executed within a measurable timing envelope consistent with
   uninterrupted software execution inside a verified enclave.  HAPCHA
   accounts natively for global network variances and is composed of
   three interlocking mechanisms:

   *  *Attested Execution Duration (AED)*: Upon ingesting the gateway's
      time-bound cryptographic Nonce, the agent's Trusted Execution
      Environment (TEE) MUST use its internal, hardware-isolated secure
      clock to record the exact millisecond of nonce ingestion (T_start)
      and the exact millisecond of payload generation completion
      (T_end).

      The enclave MUST calculate the silicon processing delta:

      Delta_T_exec = T_end - T_start

      The enclave MUST co-sign this processing delta directly into the
      hardware attestation report alongside the output payload.

      The Target Gateway MUST enforce an operator-configured AED ceiling
      (AED_max) and MUST reject any connection where:

      Delta_T_exec > AED_max

      The AED_max value is deployment-specific and MUST be configured by
      the gateway operator based on the agent's declared context window
      size and the measured baseline throughput of the target enclave
      hardware.  As a non-normative reference point, a 4K-token
      inference task on current-generation TEE hardware typically
      completes within 15-50ms under unloaded conditions.  Gateways MUST
      NOT apply a single universal ceiling across all agent types; doing
      so would generate false positives for agents processing large
      context windows (e.g., 128K tokens) or operating on resource-
      constrained silicon.

   *  *Dynamic Round-Trip Time (RTT) Profiling*: To prevent relay
      puppeteering attacks (where a remote human solves challenges and
      proxies them back to a local enclave), the gateway MUST measure
      the connection's actual propagation baseline (RTT_base) during the
      cryptographic handshake.  The Target Gateway MUST set the per-
      connection network deadline as:

      RTT_allowed = RTT_base + Delta_T_exec + epsilon

      where epsilon is a configurable jitter tolerance buffer
      (RECOMMENDED default: 10ms) that accounts for sub-millisecond
      clock drift between the agent's TEE hardware clock and the
      gateway's NTP-synchronized clock [RFC5905], as well as transient

Khera                    Expires 7 December 2026                [Page 7]
Internet-Draft                   AURORA                        June 2026

      network queuing variance.  Operators MAY increase epsilon for
      high-jitter network paths (e.g., satellite links) but SHOULD NOT
      exceed 50ms to preserve the anti-puppeteering guarantee.

      This formula natively accommodates geographic propagation
      variances, high-latency satellite links (e.g., Starlink), and
      regional fiber congestion without sacrificing security.

   *  *Hardware Enclave Co-Signing*: The agent's runtime environment
      MUST execute within a physically isolated hardware security
      enclave (e.g., Intel TDX, AMD SEV-SNP, or ARM TrustZone).  The
      enclave chip MUST sign the output payload and attestation report
      using a key that is generated and stored exclusively within the
      enclave boundary, anchoring the data directly to the enclave
      hardware.  This signature provides evidence that the payload was
      generated by the declared software stack within the attested
      enclave boundary.  Gateways MUST verify the enclave signature
      against the platform's attestation service before accepting any
      payload.  Note: enclave attestation proves the integrity of the
      runtime environment, not the intent or autonomy of the executing
      agent.

3.3.  Architecture Layer 2: Authority Attestation (Mitigating Problem 2)

   Once runtime integrity is attested by Layer 1, the agent MUST present
   its Delegated Authority Token (DAT) to cryptographically attribute
   the session to an authorizing human principal and bind explicit
   operational scope.  The DAT establishes who authorized this agent to
   act and within what boundaries --- providing an attribution record
   from which legal accountability may subsequently be determined by the
   appropriate authority.  Gateways MUST reject any connection that
   passes Layer 1 but omits a valid DAT.

   *  *The Delegated Authority Token (DAT)*: The agent MUST transmit an
      immutable, cryptographically signed token originated directly by
      its human principal or corporate entity.  The DAT MUST be signed
      using the principal's private key and MUST be bound to the agent's
      Enclave Public Key hash to prevent cross-machine token reuse (see
      Section 5.6).  The DAT cryptographically attributes the session to
      the signing principal; it does not constitute legal proof of
      liability, which is determined by applicable law.

   *  *Scope Attenuation Claims*: The DAT payload MUST enforce rigid
      operational boundaries that the gateway acts upon to restrict
      usage:

Khera                    Expires 7 December 2026                [Page 8]
Internet-Draft                   AURORA                        June 2026

      -  *Principal Identifier*: The verifiable identity of the entity
         cryptographically attributed as the authorizing party for this
         transaction, expressed as one of: an X.509 Distinguished Name
         (DN) bound to a TLS client certificate [RFC8446], a corporate
         public key registered with a recognized Certificate Authority
         (CA), or a decentralized identifier (DID) for deployments
         operating within blockchain-native infrastructure.

      -  *Financial Allocation Limit*: The maximum capital allocation
         (e.g., expressed in micro-denominations of currency or gas
         units) the machine is authorized to spend per transaction or
         session window.  Gateways MUST reject transactions that would
         cause cumulative spend to exceed this limit within the session
         window.

      -  *Functional Permitted Contexts*: An immutable array restricting
         allowed API calls or tool pathways (e.g., Read_Data,
         Execute_Trade).  Gateways MUST reject any request invoking a
         pathway not present in this array.

      -  *Chronological Ceiling*: A hard expiry timestamp after which
         the DAT MUST be considered invalid.  Gateways MUST reject
         expired tokens and MUST NOT accept token re-use across separate
         session windows.  A new DAT MUST be issued by the human
         principal upon expiration.

4.  Interoperability & System Optimization

   Upon successful dual-layer verification, gateways SHOULD switch the
   active session to a machine-optimized serialization format to
   eliminate unnecessary presentation-layer overhead (e.g., CSS
   rendering hints, HTML template wrappers, and visual tracking
   payloads).  This section defines the protocol mechanism by which this
   capability is negotiated.

4.1.  Agent Capability Declaration

   During session initiation (Step 1 of the handshake defined in
   Section 3.1), the connecting agent MUST include an "aurora-accept"
   header field declaring its supported machine-optimized serialization
   formats in descending order of preference:

aurora-accept: application/x-protobuf, application/json-rpc, application/json

   Gateways MUST parse this field before initiating the HAPCHA
   challenge.  If the field is absent, the gateway MUST assume the
   client requires standard HTTP/HTML responses and MUST NOT attempt a
   format switch.

Khera                    Expires 7 December 2026                [Page 9]
Internet-Draft                   AURORA                        June 2026

4.2.  Gateway Format Switch Signal

   Upon completing successful dual-layer verification (Steps 6a and 6b),
   the gateway MUST include an "aurora-content-type" header in the
   ACCEPT response (Step 7a) to signal the negotiated format for all
   subsequent communication within the session:

   aurora-content-type: application/x-protobuf

   The gateway MUST select the highest-preference format from the
   agent's declared "aurora-accept" list that the gateway itself
   supports.  If no mutually supported format exists, the gateway MUST
   fall back to standard JSON (application/json) and MUST NOT terminate
   the session.

4.3.  Fallback Behavior

   Gateways that do not implement machine-optimized format switching
   MUST continue to serve standard HTTP responses and MUST NOT penalize
   or reject agents that include the "aurora-accept" header.  Format
   optimization is OPTIONAL for gateway implementors; dual-layer
   security verification (Sections 3.2 and 3.3) remains REQUIRED
   regardless of whether format negotiation is supported.

5.  Security Considerations

5.1.  Network Latency & Clock Drift Mitigation

   The Hardware-Anchored Proof Challenge for Autonomous Hosts (HAPCHA)
   relies heavily on sub-millisecond precision.  On global networks,
   legitimate connections may fail due to Network Time Protocol (NTP)
   asymmetry or geographic routing paths.  Gateways MUST implement
   dynamic round-trip time (RTT) profiling as specified in Section 3.2
   to prevent false-positive fault generation across satellite, mobile,
   and inter-continental network segments.

5.2.  Trusted Computing Base (TCB) Degradation & Enclave Recovery

   Hardware-level vulnerabilities discovered in legacy architectural
   enclaves (e.g., side-channel speculation leaks) could compromise
   local keys.  AURORA enforces a strict validation requirement matching
   the TCB security level against real-time hardware status providers.
   Outdated or unpatched silicon firmware layers MUST trigger an
   immediate, graceful connection step-down.

Khera                    Expires 7 December 2026               [Page 10]
Internet-Draft                   AURORA                        June 2026

5.3.  Authority Token Revocation Lifecycle

   A human principal MUST retain out-of-band revocation capabilities to
   invalidate a Delegated Authority Token (DAT) at any time.  Concrete
   revocation triggers include:

   *  *Unauthorized Scope Breach*: The agent invokes an API call or tool
      pathway not listed in the DAT's Functional Permitted Contexts
      field.

   *  *Financial Threshold Violation*: Cumulative transaction spend
      within a session window approaches or exceeds the DAT's Financial
      Allocation Limit, triggering a mandatory principal re-
      authorization.

   *  *Enclave Integrity Failure*: The hardware enclave reports a
      Trusted Computing Base (TCB) status downgrade or attestation key
      compromise during an active session.

   *  *Principal-Initiated Signal*: The human principal transmits an
      explicit revocation command via an authenticated out-of-band
      channel (e.g., a signed revocation payload referencing the DAT's
      unique identifier).

   Gateways MUST cross-check the DAT identifier against a centralized,
   high-availability revocation index (e.g., a Bloom filter or
   distributed revocation list) before every transaction execution, not
   only at session initiation.

5.4.  Replay Attack Vectors on Multi-Gateway Environs

   A compromised network observer could intercept a valid Layer 1 co-
   signed payload and attempt a parallel execution replay against an
   alternative gateway within the expiration window.  To mathematically
   block this, all gateway session nonces MUST bind cryptographically to
   the host gateway's domain identifier.

5.5.  Cognitive Puppeteering Vulnerabilities (Prompt Injection)

   Even if an agent executes securely within hardware enclaves, it
   remains vulnerable to prompt injection or model alignment jailbreaks
   that override its reasoning system.  In this scenario, the hardware
   enclave faithfully signs malicious output logic.  To mitigate this
   cross-layer threat, Layer 1 MUST implement Semantic Attestation,
   requiring the enclave to cryptographically measure and append the
   agent's immutable base system prompt and system parameter hashes
   directly alongside the payload execution trace.

Khera                    Expires 7 December 2026               [Page 11]
Internet-Draft                   AURORA                        June 2026

5.6.  Cryptographic Cross-Layer Token Binding

   If a Delegated Authority Token (DAT) is decoupled from its original
   machine context, an attacker could extract it from memory and pass it
   to an un-attested machine.  AURORA fully neutralizes this attack
   vector by forcing Layer 2 to cryptographically bind to Layer 1: the
   human principal signs the DAT explicitly locking it to the SHA-256
   hash of the unique Enclave Public Key generated inside the physical
   chip.  The DAT cannot be validated on any other piece of physical
   silicon.

6.  Privacy Considerations

   The AURORA protocol processes and transmits identity-linked data that
   carries significant privacy implications.  Implementors MUST account
   for the following:

6.1.  Principal Identity Exposure

   The Delegated Authority Token (DAT) contains a Principal Identifier
   (e.g., an X.509 Distinguished Name or corporate public key) that is
   transmitted to the Target Gateway on every session initiation.
   Gateways MUST NOT log or retain raw DAT payloads beyond the minimum
   duration required for transaction verification and audit trail
   purposes.

6.2.  Enclave Attestation Report Linkability

   Hardware attestation reports contain platform-specific identifiers
   (e.g., enclave measurement values) that could be used to fingerprint
   a specific physical device across sessions.  Implementations SHOULD
   rotate enclave signing keys at defined intervals to limit long-term
   cross-session correlation of a single agent's hardware identity.

6.3.  Financial Metadata Minimization

   The DAT's Financial Allocation Limit field exposes agent spending
   capacity to the Target Gateway.  Gateways MUST treat this field as
   confidential commercial data and MUST NOT disclose it to third
   parties outside the scope of the verified transaction.

7.  Implementation Status

   This section records the implementation status of the AURORA protocol
   in accordance with [RFC7942].

Khera                    Expires 7 December 2026               [Page 12]
Internet-Draft                   AURORA                        June 2026

   As of the date of this Internet-Draft, no production implementations
   of the full AURORA dual-layer handshake exist.  The following
   components are under active development:

   *  *Reference Gateway Validator*: A prototype Target Gateway
      validator implementing Layer 1 (HAPCHA/AED timing checks) and
      Layer 2 (DAT signature and scope verification) is planned as an
      open-source reference implementation.  Status: Pre-Alpha.

   *  *DAT Issuance Library*: A library for human principals to
      generate, sign, and revoke Delegated Authority Tokens is under
      design.  Status: Specification phase.

   *  *TEE Integration Layer*: Adapter libraries for Intel TDX and AMD
      SEV-SNP to produce AURORA-compatible attestation reports are
      planned.  Status: Research phase.

   Contributions and early implementations are welcomed via the project
   repository at: https://github.com/mastermindankur/aurora-protocol

8.  IANA Considerations

   This document does not currently request any registry actions from
   IANA.  Future revisions defining specific JSON Web Token (JWT) claim
   registrations for the Delegated Authority Token (DAT) will utilize
   the parameters established in [RFC7519].

9.  References

9.1.  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>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
              <https://www.rfc-editor.org/info/rfc7519>.

Khera                    Expires 7 December 2026               [Page 13]
Internet-Draft                   AURORA                        June 2026

9.2.  Informative References

   [RFC5905]  Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
              "Network Time Protocol Version 4: Protocol and Algorithms
              Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
              <https://www.rfc-editor.org/info/rfc5905>.

   [RFC7942]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
              Code: The Implementation Status Section", BCP 205,
              RFC 7942, DOI 10.17487/RFC7942, July 2016,
              <https://www.rfc-editor.org/info/rfc7942>.

Author's Address

   Ankur Khera
   Email: ankurkhera@iitdalumni.com

Khera                    Expires 7 December 2026               [Page 14]