# drafts

name: draft-ietf-drip-auth
rev: 49
title: DRIP Entity Tag Authentication Formats & Protocols for Broadcast Remote ID
time: 2024-06-26T18:53:10Z
group_uri: /api/v1/group/group/2266/
expires: 2024-08-24T22:38:49Z
ad: /api/v1/person/person/105099/
shepherd: /api/v1/person/email/mohamed.boucadair@orange.com/
categories: ["Agent identity/auth", "Data formats/interop", "Policy/governance"]
tags: []
fetched_at: 2026-03-08T13:09:22.574664+00:00
source: ietf
abstract:
  The Drone Remote Identification Protocol (DRIP), plus trust policies
     and periodic access to registries, augments Unmanned Aircraft System
     (UAS) Remote Identification (RID), enabling local real time
     assessment of trustworthiness of received RID messages and observed
     UAS, even by Observers lacking Internet access.  This document
     defines DRIP message types and formats to be sent in Broadcast RID
     Authentication Messages to verify that attached and recent detached
     messages were signed by the registered owner of the DRIP Entity Tag
     (DET) claimed.

states:
  ["/api/v1/doc/state/3/", "/api/v1/doc/state/108/", "/api/v1/doc/state/112/", "/api/v1/doc/state/7/", "/api/v1/doc/state/44/"]


name: draft-ietf-rats-corim
rev: 10
title: Concise Reference Integrity Manifest
time: 2026-03-02T17:26:59Z
group_uri: /api/v1/group/group/2231/
expires: 2026-09-03T17:26:59Z
shepherd: /api/v1/person/email/mcr+ietf@sandelman.ca/
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/", "/api/v1/doc/state/41/"]
categories: ["Agent identity/auth", "Data formats/interop"]
tags: []
fetched_at: 2026-03-08T13:09:22.577893+00:00
source: ietf
abstract:
  Remote Attestation Procedures (RATS) enable Relying Parties to assess
     the trustworthiness of a remote Attester and therefore to decide
     whether or not to engage in secure interactions with it.  Evidence
     about trustworthiness can be rather complex and it is deemed
     unrealistic that every Relying Party is capable of the appraisal of
     Evidence.  Therefore that burden is typically offloaded to a
     Verifier.  In order to conduct Evidence appraisal, a Verifier
     requires not only fresh Evidence from an Attester, but also trusted
     Endorsements and Reference Values from Endorsers and Reference Value
     Providers, such as manufacturers, distributors, or device owners.
     This document specifies the information elements for representing
     Endorsements and Reference Values in CBOR format.


name: draft-wu-savnet-inter-domain-architecture
rev: 12
title: Inter-domain Source Address Validation (SAVNET) Architecture
time: 2024-11-03T09:50:49Z
group_uri: /api/v1/group/group/2317/
expires: 2025-05-07T09:50:49Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/", "/api/v1/doc/state/134/"]
categories: ["Policy/governance", "Autonomous netops"]
tags: []
fetched_at: 2026-03-08T13:09:22.580994+00:00
source: ietf
abstract:
  This document introduces an inter-domain SAVNET architecture for
     performing AS-level SAV and provides a comprehensive framework for
     guiding the design of inter-domain SAV mechanisms.  The proposed
     architecture empowers ASes to generate SAV rules by sharing SAV-
     specific information between themselves, which can be used to
     generate more accurate and trustworthy SAV rules in a timely manner
     compared to the general information.  During the incremental or
     partial deployment of SAV-specific information, it can utilize
     general information to generate SAV rules, if an AS's SAV-specific
     information is unavailable.  Rather than delving into protocol
     extensions or implementations, this document primarily concentrates
     on proposing SAV-specific and general information and guiding how to
     utilize them to generate SAV rules.  To this end, it also defines
     some architectural components and their relations.


name: draft-lin-opsec-trustroute-problem-statement
rev: 04
title: Problem Statement and Use Cases of Trustworthiness-based Routing
time: 2024-07-26T07:05:07Z
group_uri: /api/v1/group/group/1027/
expires: 2024-07-27T06:07:09Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: ["Policy/governance", "Autonomous netops"]
tags: []
fetched_at: 2026-03-08T13:09:22.584008+00:00
source: ietf
abstract:
  Currently, network operators are trying to provide fine-granularity
     Service Level Agreement (SLA) guarantee to achieve better Quality of
     Experience (QoE) for end users and engage customers, such as ultra-
     low latency and high reliability service.  However, with increasing
     security threats, differentiated QoE services are insufficient, the
     demands for more differentiated security service are emerging.

     This document explores the requirements for differentiated security
     services and identifies the scenarios for network operators.  To
     provide differentiated security services, possible trustworthiness-
     based routing solution is discussed.


name: draft-wiethuechter-drip-det-moc
rev: 02
title: Registration & Usage of DRIP Entity Tags for Trustworthy Air Domain Awareness
time: 2025-07-07T23:45:10Z
group_uri: /api/v1/group/group/1027/
expires: 2026-01-08T23:45:10Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "Agent discovery/reg", "Autonomous netops"]
tags: []
fetched_at: 2026-03-08T13:09:22.587129+00:00
source: ietf
abstract:
  This document standardizes usage of Drone Remote Identification
     Protocol (DRIP) Entity Tags (DETs) as identifiers to enable
     trustworthy Air Domain Awareness (ADA) for Unmanned Aircraft Systems
     (UAS) in Remote Identification (RID), UAS Traffic Management (UTM)
     and Advanced Air Mobility (AAM).  DETs can serve as Session IDs for
     privacy, Authentication Key IDs for accountability, and encryption
     key IDs for confidentiality.

full_text:
  drip Working Group                                       A. Wiethuechter
  Internet-Draft                                        AX Enterprize, LLC
  Intended status: Standards Track                             7 July 2025
  Expires: 8 January 2026


    Registration & Usage of DRIP Entity Tags for Trustworthy Air Domain
                                 Awareness
                     draft-wiethuechter-drip-det-moc-02

  Abstract

     This document standardizes usage of Drone Remote Identification
     Protocol (DRIP) Entity Tags (DETs) as identifiers to enable
     trustworthy Air Domain Awareness (ADA) for Unmanned Aircraft Systems
     (UAS) in Remote Identification (RID), UAS Traffic Management (UTM)
     and Advanced Air Mobility (AAM).  DETs can serve as Session IDs for
     privacy, Authentication Key IDs for accountability, and encryption
     key IDs for confidentiality.

  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 8 January 2026.

  Copyright Notice

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










  Wiethuechter             Expires 8 January 2026                 [Page 1]


  Internet-Draft                   det-moc                       July 2025


     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  . . . . . . . . . . . . . . . . . . . . . . . .   2
       1.1.  Purpose . . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.2.  Background  . . . . . . . . . . . . . . . . . . . . . . .   3
       1.3.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
       2.1.  Additional Definitions  . . . . . . . . . . . . . . . . .   4
     3.  Interactions & Responsibilities . . . . . . . . . . . . . . .   5
       3.1.  UAS Observers . . . . . . . . . . . . . . . . . . . . . .   5
       3.2.  Registrants . . . . . . . . . . . . . . . . . . . . . . .   5
       3.3.  UAS Manufacturers . . . . . . . . . . . . . . . . . . . .   6
       3.4.  HDA Operators . . . . . . . . . . . . . . . . . . . . . .   6
       3.5.  RAA Operators . . . . . . . . . . . . . . . . . . . . . .   7
     4.  Requirements for DIME Operation . . . . . . . . . . . . . . .   8
       4.1.  Query . . . . . . . . . . . . . . . . . . . . . . . . . .   8
         4.1.1.  Public Information Registries . . . . . . . . . . . .   8
         4.1.2.  Private Information Registries  . . . . . . . . . . .   8
       4.2.  Registration  . . . . . . . . . . . . . . . . . . . . . .   9
     5.  Compliance Testing  . . . . . . . . . . . . . . . . . . . . .   9
       5.1.  Registration Interface  . . . . . . . . . . . . . . . . .  10
       5.2.  Public Query Interface  . . . . . . . . . . . . . . . . .  10
       5.3.  Private Query Interface . . . . . . . . . . . . . . . . .  10
     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
     8.  Privacy & Transparency Considerations . . . . . . . . . . . .  11
       8.1.  DETs as Session ID and Authentication Key ID  . . . . . .  11
       8.2.  Selective Encryption  . . . . . . . . . . . . . . . . . .  12
     9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
       9.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
       9.2.  Informative References  . . . . . . . . . . . . . . . . .  14
     Appendix A.  HID Abbreviation . . . . . . . . . . . . . . . . . .  15
     Appendix B.  Compliance Submission Forms  . . . . . . . . . . . .  16
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  16

  1.  Introduction






  Wiethuechter             Expires 8 January 2026                 [Page 2]


  Internet-Draft                   det-moc                       July 2025


  1.1.  Purpose

     This document provides to stakeholders in a National Airspace System
     (NAS), such as a Civil Aviation Authority (CAA) and its consituients,
     a point of entry into a set of relevant standards.  These standards
     provide guidance to enable trustworthy Air Domain Awareness (ADA)
     primarily via cooperative techologies.  Such technologies can
     include, but are not limited to, Unmanned Aircraft Systems (UAS)
     Remote Identification (RID), UAS Traffic Management (UTM) and
     Advanced Air Mobility (AAM).  This document specifies an interopable
     manner of achieving the stated objectives in an international
     context.

     A CAA MAY override any technical specification in this document but
     MUST, if claiming compliance with this document, provide the reason
     and an alternative specification satisfying the same objective.

  1.2.  Background

     [RFC9153] provides comprehensive background on the UAS RID use-case
     and the UTM/AAM context.

     Trustworthiness revolves around identification and authentication.
     [RFC9374] defines the Drone Remote Identification Protocol (DRIP)
     Entity Tag (DET), a trustable identifier backed by asymmetic
     cryptography.  [RFC9575] standardizes authentication of DETs and
     associated information using strong cryptography suited for
     constrained mobile wireless links (typical of Broadcast RID).
     Broadcast and Network RID are defined by ASTM [F3411] which
     designates the International Civil Aviation Organization (ICAO) to
     maintain codepoints for Specific Session ID Types and Specific
     Authentication Methods (SAMs) [RID-NUMBER-REGISTRATION].  ICAO
     includes DETs as a Specific Session ID Type and lists the four DRIP
     SAMs.

     [DET-REGISTRATION] defines a method for a registrant (typically a UAS
     Operator or UAS) to propose their inclusion into the identifier
     heirarchy.  The registry system, made up of DRIP Identity Management
     Entities (DIMEs), ensures uniqueness within the heirarchy, endorses
     inclusion through X.509 certificates, and provides access to public
     and private information associated with a DET registration.  Public
     information is served using the Domain Name System (DNS) and is
     specified in [DET-DNS].  Private information is served using the
     Registration Data Access Protocol (RDAP, TODO: ref) and protected
     through policy based differentiated access [DET-DIFF-ACCESS].






  Wiethuechter             Expires 8 January 2026                 [Page 3]


  Internet-Draft                   det-moc                       July 2025


     This document specifies the fundamental registration processes and
     interactions surrounding the Private Information Registry function
     defined in the DRIP Architecture ([RFC9434]).

  1.3.  Scope

     This document assumes that participanting entities are in compliance
     with relevant existing UAS standards such as ASTM [F3411], [F3548]
     and TODO-REF: ICAO-TFP.

     This document governs use of a DET in the following cases:

     *  An entity that uses a Session ID (some participating entities,
        e.g. HDAs, may not need Session IDs), MUST use a DET for that
        Session ID.

     *  An entity that participates in DRIP protocol interactions (even if
        not needing a Session ID), MUST use a DET for the DRIP public key
        ID in those interactions.

     *  An entity that requires a strongly cryptographically verifiable IP
        compatible identifier, MAY use a DET for any other legal purpose.

     *  An entity SHOULD NOT use a DET as a locator in physical or logical
        space (e.g. as a globally routable IPv6 address outside of an
        overlay network), as deconflation is intended, see [RFC9063].

     The archetypal case is a UAS for which the DET serves as both the UAS
     ID (first case above) and the Authentication Key ID (second case).

  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.

  2.1.  Additional Definitions

     This document makes use of terms (PII, USS, etc.) defined in
     [RFC9153], [RFC9434] and [RFC9374].  For convenience of the reader,
     some of the major definitions are restated here.

     DRIP Identity Management Entity (DIME):  Originally defined in
        [RFC9434] and expanded technically in [DET-DNS].  An entity
        providing registrar and registry services specifically for DETs.




  Wiethuechter             Expires 8 January 2026                 [Page 4]


  Internet-Draft                   det-moc                       July 2025


  3.  Interactions & Responsibilities

     This section outlines the various players in the ecosystem.  For
     each, it outlines relevant motivations for using DRIP, as well as the
     interactions and responsibilities they have in doing so.

  3.1.  UAS Observers

     An Observer has many motivations for detecting Broadcast RID.
     Regardless of their motivation the authenticity of the data presented
     is important for them to make decisions on their next actions.  This
     is accomplished by the use of Authentication of the Broadcast RID,
     something DRIP provides.  Observers also may need additional
     information, beyond what is sent over Broadcast RID.  While the use
     of a Session ID provides a level of privacy, the use of DRIP allows
     this privacy while also enabling authorized queries for additional
     data.

     An Observer device is expected to be able to process Broadcast RID
     messages per [F3411] in accordance with CAA regulations (such as
     [F3586]) as follows:

     In order to satisfy CAA regulatory requirements as per corresponding
     Means of Compliance (e.g. [F3586] for the US) something something
     MUST comply with applicable portions of [F3411] and process as per
     [RFC9575] the following messages:

     1.  The UAS ID SHOULD be displayed either in the style of an IPv6
         address per [RFC5952] or as described in Appendix A for the
         following ASTM [F3411] Message Types:

         *  Basic ID Message (Message Type 0x0), UAS ID Type 0x4 (Specific
            Session ID), Specific Session ID Type 0x01 (DRIP Entity Tag).

     2.  Appendix A of [RFC9575] is RECOMMENDED for visualization of the
         trustworthiness assessment.  Observer devices MUST follow the
         requirements of Section 6.4.2 of [RFC9575] for the following ASTM
         [F3411] Message Types:

         *  Authentication Messages (Message Type 0x2), Authentication
            Type 0x5 (Specific Authentication Method (SAM)), SAM Types
            0x01 (DRIP Link), 0x02 (DRIP Wrapper), 0x03 (DRIP Manifest)
            and optionally 0x04 (DRIP Frame).

  3.2.  Registrants

     Typically UAS Operators.




  Wiethuechter             Expires 8 January 2026                 [Page 5]


  Internet-Draft                   det-moc                       July 2025


     UAS Operators may want to protect the privacy of their details (such
     as Operator Location) and their reputation.  Reputation can be gained
     or lost with observation and reports of behavior backed by
     Authentication.  They MAY decide for which identification purposes
     they will use DETs.  This choice may be constrained by the
     jurisdiction's RID regulations.

        Author: move to Definitions: whether to use DRIP for an
        Authentication Key ID only, Single Use Session ID only, or both.
        The last of these is the natural approach providing the greatest
        benefits and thus the primary focus of this document.

  3.3.  UAS Manufacturers

     Manufacturers typically wish to maintain good reputation of their
     brands and are often driven by market forces.  Such forces include
     requirements and preferences of both UAS Observers and Operators.

     To satisfy CAA requirements, a UA MUST transmit whatever [F3411]
     messages are needed to carry at least the minimal elements of
     information required by the regulator.  In the US, under the current
     FAA RID rule, these are Basic ID, Location/Vector, and System as
     specified in [F3586].  If the content of these messages is to be
     trusted, the UA MUST also sign those messages, using the DRIP Wrapper
     and/or DRIP Manifest methods, as described in [RFC9575].

        Author: add reference to US RID rule

     The UAS MUST provide mechanisms and interfaces to enable DET support
     for UAS Operator selected purposes.  For DRIP this requires at
     minimum the UAS Operator to be able to select DRIP options and start
     the process of generating and registering a DET with a selected HDA.

  3.4.  HDA Operators

     A registry function including Hierarchical Host Identity Tag (HHIT)
     Domain Authority (HDA) is required to support Session IDs that can be
     used by CAAs and other lawfully authorized parties to look up
     essential safety and security information associated with UAS and
     their Operators.

     In the UTM context, it is expected that the HDA function will be
     provided by each UAS Service Supplier (USS).  This can be in-house or
     out-sourced to a service bureau more specialized in cryptographically
     verifiable identifiers usable to access data and systems on networks.
     Outside the UTM context, each Operator must still obtain this
     function from some provider.




  Wiethuechter             Expires 8 January 2026                 [Page 6]


  Internet-Draft                   det-moc                       July 2025


     The HDA function also can support other services related to Session
     IDs.  The DRIP Entity Tag (DET) can act as a Session ID and/or
     Authentication Key ID, thus HDA functionality in this document
     assumes both are being provided to registrants (see Section 8.1 for
     more details).  The use of Authentication is mandated in some (e.g.
     Japan) but not all regions.

     Each DET is tied to a longer term identifier by its HDA.  Typically
     this identifier is expected to be the UAS Serial Number, however a
     CAA MAY choose another long term identifier of significance to them.
     The binding between these two identifiers is typically considered
     private.

     An HDA Operator must fullfil the requirements of their jurisdiction.
     They must also satisfy the desires of UAS Operators.

     The HDA MUST provide, upon successful registration of a DET, the four
     Broadcast Endorsement objects for use in [RFC9575] as defined by
     [DKI].  These are:

     *  Broadcast Endorsement: RAA:A on RAA:A

     *  Broadcast Endorsement: RAA:A on HDA:A

     *  Broadcast Endorsement: HDA:A on HDA:I

     *  Broadcast Endorsement: HDA:I on Registrant

     The HDA must also place certain essential information into the
     Internet Domain Name System (DNS) and maintain that information as
     operations are activated, completed, etc.  All the information to be
     placed into the DNS is public as it is either needed to make the DET
     based systems work or because it is a high-availability replica of
     information transmitted in clear-text via Broadcast RID.  The DNS
     records also MUST point to the private registry in which additional
     information, required by the HDA/USS itself or the CAA, must be
     placed and maintained, for query by authorized parties only.

  3.5.  RAA Operators

     RAAs in this document are scoped to be operated by a State.  Each
     State is allocated four RAAs, and may decide on their usage.

     Each RAA MUST register HDAs within its scope.  Each RAA MUST provide
     both widely supported "long form" X.509 certificates and DRIP-
     specific "short form" endorsements of its HDAs.





  Wiethuechter             Expires 8 January 2026                 [Page 7]


  Internet-Draft                   det-moc                       July 2025


     The RAA MAY provide services to HDAs for verification of data
     pertaining to UAS Operators.  For example an HDA registering a UAS
     Session ID may query the RAA to verify a previously RAA-registered
     UAS Serial Number.

     The RAA Operator MUST obtain valid DNS delegation.  See Section 6 for
     more details.

  4.  Requirements for DIME Operation

     The requirements below apply to both RAA and HDA Operators with a
     focus on how HDA Operators provide registration and related services
     for their clients (i.e. UAS Operators and their UAS).

  4.1.  Query

     A DIME has two query interfaces it MUST support.  One interface is
     used for public information query and another (identified and using
     data found via public queries) is for private information.

  4.1.1.  Public Information Registries

     The information found in these registries has been designated as
     (explicitly or implicitly) public by cognizant authority and/or the
     information owner.  Such information includes public cryptographic
     keys needed for authentication in [RFC9575], static Broadcast RID
     data and trustworthy pointers to additional information.

     These registries are Authoritative Name Servers of DNS.  See
     [DET-DNS] for operational requirements, query mechanism and response
     models.

  4.1.2.  Private Information Registries

     The information found in these registries is considered Personally
     Identifiable Information (PII) and/or is stored for potential future
     audit of registration.

     Private information queries MUST follow [DET-DIFF-ACCESS].  This
     specifies the use of Registration Data Access Protocol (RDAP) data
     models and query formats as the primary query mechanisms.  The
     specific access control policies are to be defined by the CAA.  A CAA
     MAY require additional query mechanisms for their jurisdiction.

     The eXtensible Access Control Markup Language (XACML) MUST be used.
     The policies to be enforced by XACML MUST be provided by the CAA and
     are out of scope for this document.




  Wiethuechter             Expires 8 January 2026                 [Page 8]


  Internet-Draft                   det-moc                       July 2025


  4.2.  Registration

     There are several registration functions essential to achieving the
     purposes to which this document is directed.  Likewise there are
     several viable technical approaches to performing these functions.
     The only approaches fully specified in [DET-REGISTRATION] are the
     Constrained Application Protocol (CoAP) [RFC7252] and/or Concise
     Binary Object Representation (CBOR) Web Tokens (CWT) [RFC8392].

     DRIP does NOT provide protection against incorrect (e.g. fraudulent)
     data entered during registration or asserted subsequently.  DRIP does
     protect against alteration (intentional or unintentional) of data
     subsequent to its assertion by the cryptographic signer.  The signer
     might be the proximate sender (e.g. UA transmitting Broadcast RID) or
     might be an attestor far away and long ago (e.g. root Certificate
     Authority).  It is the duty of the operator of each DIME, or the
     party on whose behalf the DIME is being operated, to validate the
     registration data.  The RAA (e.g. CAA) SHOULD provide services to
     obtain this goal.  The APIs and access controls for such services are
     a matter of national policy and are out of scope for this document.

  5.  Compliance Testing

     It is the responsability of each node in the tree that a child node
     passes functional interop testing prior to issuing a certificate for
     the child node.

        Author: This section is a work in progress.

     All interfaces MUST be tested on valid and invalid data (such as
     being malformed).  When policy is required on an interface all
     defined permutations of the policy MUST be tested.  The policy engine
     MUST be evoked to validate proper decisions and actions are being
     made.  All data returned from an interface MUST be tested to check
     that it conforms with specifications.

     There is a range in the RAA space allocated for experimentation and
     testing purposes.  These can be delegated to parties, for a limited
     period of time at the behest of the RAA Designated Expert, to test
     DIME interoperability (e.g. HDA to RAA interactions) in any of the
     below subsections.  The IANA Considerations section of [DET-DNS]
     contains more information on how these delegations are to be handled.

     Appendix B provides a set of forms to be filled out and submitted as
     part of a CAA compliance process for using DRIP.






  Wiethuechter             Expires 8 January 2026                 [Page 9]


  Internet-Draft                   det-moc                       July 2025


     +-----+           +-----+
     |     |           |     |
     |     o----(1)--->o     |
     |  A  |           |  B  |
     |     o<---(2)----o     |
     |     |           |     |
     +-----+           +-----+

                    Figure 1: System Interface Test Diagram

  5.1.  Registration Interface

     A, B pairs: (registrant, HDA), (HDA, RAA)

     1: Ensure that CoAP endpoints on B can be accessed according to B's
     policy by A.  Ensure that the endpoints conform to the normative
     requirements of [DET-REGISTRATION] Test that B interface properly
     handles valid and malformed data.  Test that B securely generates
     proper artifacts and stores them.

     2: Ensure that the CoAP interactions for (1) properly returns data to
     A from B.  This data MUST include the Broadcast Endorsements, X.509s
     and any other data elements required.

  5.2.  Public Query Interface

     A, B pairs: (UAS Observer, HDA), (UAS Observer, RAA), (HDA, RAA),
     (RAA, HDA), (HDA, HDA'), (RAA, RAA')

     1: Ensure that B has a properly configured and publicly accessible
     Authoritative Name Server for its delegated ip6.arpa domain.

     2: Ensure that B returns the valid RRTypes defined in [DET-DNS] to A
     based on an ip6.arpa query via standard DNS methods (i.e. using UDP
     on port 53).  Ensure that the HHIT RRType contains the correct
     Certificate with an URI.

  5.3.  Private Query Interface

     A, B pairs: (UAS Observer, HDA), (UAS Observer, RAA), (HDA, RAA),
     (RAA, HDA), (HDA, HDA'), (RAA, RAA')

     1: Ensure that the provide URI from the public query interface points
     to a valid URI.  Ensure that the endpoint on B has proper AAA
     mechanisms as defined in this document and enforces the proper policy
     options.





  Wiethuechter             Expires 8 January 2026                [Page 10]


  Internet-Draft                   det-moc                       July 2025


     2: Ensure that the B endpoint securely returns the data expected
     according to policy (matrix of authorized, valid request,
     unauthorized and invalid request) to A.

  6.  IANA Considerations

     This document requires no new or modified actions by IANA.  It does
     depend on actions IANA has already undertaken to perform in support
     of DRIP [DET-DNS].  It also informs other parties of interactions
     they must have with IANA to achieve the intended purposes of this
     document; e.g. Nation states MUST request IANA delegation of the DNS
     zone under ip6.arpa. corresponding to their allocated RAA values.

  7.  Security Considerations

     The considerations discussed in [RFC9153], [RFC9434], [RFC9374],
     [RFC9575] and [DET-DNS] apply.

     DIMEs use and provide various methods to protect data as described
     below under seven categories: Attestation, Authentication,
     Authorization, Access Control, Attribution, Accounting and Audit.
     DRIP refers to these categories collectively as AAA.  All data,
     handled under DRIP, MUST be protected by AAA.  All private data MUST
     also be protected by strong encryption where permitted by law.  These
     requirements apply to data at rest and in transit in all phases of
     the process, i.e. registration and query.

     Attestation may be mandated by CAAs for devices (such as UA).  Remote
     ATtestation ProcedureS (RATS) [RFC9334] is recommended for DRIP.  The
     specific attestation mechanisms in a given jurisdiction are out of
     scope for this document.

  8.  Privacy & Transparency Considerations

     The considerations discussed in [RFC9153] apply.

  8.1.  DETs as Session ID and Authentication Key ID

     The properties of a DET allow it to be used as a Session ID and/or an
     Authentication Key ID.  There may be scenarios in which Session IDs
     are desired for privacy but Authentication is not; although this may
     reduce transparency and security, a DET MAY be used exclusively as a
     Session ID in such.  There are scenarios in which Authentication is
     desired but Session IDs are not (e.g. where a CAA does not allow
     Session IDs); a DET MAY be used exclusively as an Authentication Key
     ID in such.  In the scenario expected to be most common, both Session
     IDs and Authentication are desired; the same DET SHOULD be used as
     both the Session ID and Authentication Key ID in such.  Consequences



  Wiethuechter             Expires 8 January 2026                [Page 11]


  Internet-Draft                   det-moc                       July 2025


     and operational impact of using different DETs for the Session ID and
     Authentication Key ID are unknown and not covered in this document.

  8.2.  Selective Encryption

     Selective encryption may be allowed in some circumstances.  An HHIT
     may be used in a private lookup to access decryption key material or
     obtain decryption as a service.

     Selective encryption of UAS RID using DRIP is only allowed when the
     DET to be used as the Session ID is issued by an HDA associated with
     a USS and that DET is associated with the corresponding Operational
     Intent in UTM.  This enables the encryption of selected data elements
     in Broadcast RID to provide a layer of privacy for operators (e.g.
     their position) without compromising transparency to entities (e.g.
     public safety / law enforcement personnel) that need to know.

     Selective encryption typically requires network connectivity of the
     Observer to perform the private query to obtain the decryption
     service or key material.  CAAs should consider the expected Observer
     environment and prohibit encryption wherever and whenever Observers
     cannot reasonably be expected to have connectivity.  For example
     selective encryption, per CAA regulations, MAY be allowed in dense
     wireless IP connectivity areas (e.g. urban) but prohibited in poor
     wirelessly covered areas (e.g. rural).

     The issue of Observer network connectivity MAY be mitigated with the
     use of a shared decryption key used by multiple Session IDs under a
     given USS/HDA over a period of time, that is preloaded onto the
     Observer device before connectivity is lost.  For example Observers
     MAY query USS/HDAs for flight volumes in which they are interested to
     preload their decryption key(s) for the Operational Intents/Session
     IDs that day.

  9.  References

  9.1.  Normative References

     [DET-DIFF-ACCESS]
                Wiethuechter, A., "DRIP Entity Tag (DET) Differentiated
                Access using RDAP", Work in Progress, Internet-Draft,
                draft-wiethuechter-drip-det-diff-access-rdap-00, 27
                September 2024, <https://datatracker.ietf.org/doc/html/
                draft-wiethuechter-drip-det-diff-access-rdap-00>.







  Wiethuechter             Expires 8 January 2026                [Page 12]


  Internet-Draft                   det-moc                       July 2025


     [DET-DNS]  Wiethuechter, A. and J. Reid, "DRIP Entity Tags in the
                Domain Name System", Work in Progress, Internet-Draft,
                draft-ietf-drip-registries-31, 27 June 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-drip-
                registries-31>.

     [DET-REGISTRATION]
                Wiethuechter, A., "DRIP Entity Tag (DET) Registration
                using CoAP & CWTs", Work in Progress, Internet-Draft,
                draft-wiethuechter-drip-det-registration-coap-cwt-00, 27
                September 2024, <https://datatracker.ietf.org/doc/html/
                draft-wiethuechter-drip-det-registration-coap-cwt-00>.

     [DKI]      Moskowitz, R. and S. W. Card, "The DRIP DET public Key
                Infrastructure", Work in Progress, Internet-Draft, draft-
                ietf-drip-dki-08, 22 April 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-drip-
                dki-08>.

     [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/rfc/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/rfc/rfc8174>.

     [RFC9153]  Card, S., Ed., Wiethuechter, A., Moskowitz, R., and A.
                Gurtov, "Drone Remote Identification Protocol (DRIP)
                Requirements and Terminology", RFC 9153,
                DOI 10.17487/RFC9153, February 2022,
                <https://www.rfc-editor.org/rfc/rfc9153>.

     [RFC9374]  Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov,
                "DRIP Entity Tag (DET) for Unmanned Aircraft System Remote
                ID (UAS RID)", RFC 9374, DOI 10.17487/RFC9374, March 2023,
                <https://www.rfc-editor.org/rfc/rfc9374>.

     [RFC9434]  Card, S., Wiethuechter, A., Moskowitz, R., Zhao, S., Ed.,
                and A. Gurtov, "Drone Remote Identification Protocol
                (DRIP) Architecture", RFC 9434, DOI 10.17487/RFC9434, July
                2023, <https://www.rfc-editor.org/rfc/rfc9434>.








  Wiethuechter             Expires 8 January 2026                [Page 13]


  Internet-Draft                   det-moc                       July 2025


     [RFC9575]  Wiethuechter, A., Ed., Card, S., and R. Moskowitz, "DRIP
                Entity Tag (DET) Authentication Formats and Protocols for
                Broadcast Remote Identification (RID)", RFC 9575,
                DOI 10.17487/RFC9575, June 2024,
                <https://www.rfc-editor.org/rfc/rfc9575>.

  9.2.  Informative References

     [F3411]    ASTM International, "Standard Specification for Remote ID
                and Tracking", ASTM F3411-22A, DOI 10.1520/F3411-22A, July
                2022, <https://www.astm.org/f3411-22a.html>.

     [F3548]    ASTM International, "Standard Specification for UAS
                Traffic Management (UTM) UAS Service Supplier (USS)
                Interoperability", ASTM F3548-21, July 2025,
                <https://www.astm.org/f3548-21.html>.

     [F3586]    ASTM International, "Standard Practice for Remote ID Means
                of Compliance to Federal Aviation Administration
                Regulation 14 CFR Part 89", ASTM F3586-22,
                DOI 10.1520/F3586-22, July 2022,
                <https://www.astm.org/f3411-22a.html>.

     [RFC5952]  Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
                Address Text Representation", RFC 5952,
                DOI 10.17487/RFC5952, August 2010,
                <https://www.rfc-editor.org/rfc/rfc5952>.

     [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
                Application Protocol (CoAP)", RFC 7252,
                DOI 10.17487/RFC7252, June 2014,
                <https://www.rfc-editor.org/rfc/rfc7252>.

     [RFC8392]  Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
                "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
                May 2018, <https://www.rfc-editor.org/rfc/rfc8392>.

     [RFC9063]  Moskowitz, R., Ed. and M. Komu, "Host Identity Protocol
                Architecture", RFC 9063, DOI 10.17487/RFC9063, July 2021,
                <https://www.rfc-editor.org/rfc/rfc9063>.

     [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/rfc/rfc9334>.






  Wiethuechter             Expires 8 January 2026                [Page 14]


  Internet-Draft                   det-moc                       July 2025


     [RID-NUMBER-REGISTRATION]
                International Civil Aviation Organization, "ICAO Remote ID
                Number Registry", July 2025,
                <https://www.icao.int/airnavigation/IATF/Pages/ASTM-
                Remote-ID.aspx>.

  Appendix A.  HID Abbreviation

     The DET MAY be abbreviated.  This is useful for display application
     with limited screen real-estate as the display of the entire 128-bit
     (32-character in hexadecimal) IPv6 address can be costly.
     Abbreviations SHOULD follow the following format rules.

     Hierarchy Level:  Each hierarchy level (RAA/HDA) is represented by a
        maximum of four alphanumeric characters.  This abbreviation SHOULD
        NOT be a single character in length, for obvious reasons of not
        being very useful.  The decimal representation does fit into the 4
        character restriction but is NOT RECOMMENDED.  The RECOMMENDED
        abbreviation for the RAA level is to use the ISO3166-1 Alpha 2
        code for nations.  This abbreviation MAY be found in DNS under a
        HHIT RRType of the entity or its parents.  If there is no
        abbreviation hint display devices SHOULD use a fixed size four
        character hexadecimal representation of the value.  It is
        RECOMMENDED that display applications specify a default RAA value,
        and only display the RAA abbreviation explicitly when it does not
        match the default.

     Entity Hash:  The entity is represented by a fixed size four
        character hexadecimal string using the last four characters of the
        DET.  If a collision (within the same HID space) on display
        occurs, the four characters SHOULD shift to the left by one
        hexadecimal character until the collision is resolved.  This
        window MUST stay within the last sixteen hexadecimal characters of
        the DET.  The : character found in an IPv6 address string is
        ignored.

     Delimiter:  Each section is delimited by a single character.  This
        can be any whitespace character (except newline and tab) or any
        non-alphanumeric character (period, comma, semicolon, etc.).  It
        is RECOMMENDED that the delimiter is consistent between
        components.  The RECOMMENDED delimiter is the space character.

     For example a DET with the values of RAA 16383 and HDA 1 without any
     abbreviation hint from DNS is represented by the string 3FFF 0001
     xxxx with xxxx representing a entity hash.  If an abbreviation for
     the RAA (such as DRIP01) and HDA (such as TEST) are found in DNS then
     the DET can be represented with the string of DRIP01 TEST xxxx.




  Wiethuechter             Expires 8 January 2026                [Page 15]


  Internet-Draft                   det-moc                       July 2025


     For an example of the entity hash, let's assume there are two DETs
     with the following hashes in the same HID: 0000:1111:2222:3333 and
     0000:2222:1111:3333.  At first both DETs are represented with the
     same abbreviation: RAA HDA 3333.  One of these DETs is selected by
     the display application to shift the display hash one character to
     avoid the collision resulting in the following two abbreviations: RAA
     HDA 3333 and RAA HDA 1333.

  Appendix B.  Compliance Submission Forms

     TODO

  Author's Address

     Adam Wiethuechter
     AX Enterprize, LLC
     4947 Commercial Drive
     Yorkville, NY 13495
     United States of America
     Email: adam.wiethuechter@axenterprize.com































  Wiethuechter             Expires 8 January 2026                [Page 16]


name: draft-smith-rats-evidence-trans
rev: 01
title: Evidence Transformations
time: 2025-04-04T21:57:22Z
group_uri: /api/v1/group/group/2231/
expires: 2025-09-01T22:51:46Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/", "/api/v1/doc/state/36/"]
categories: ["Data formats/interop", "Agent identity/auth"]
tags: []
fetched_at: 2026-03-08T13:09:22.590257+00:00
source: ietf
abstract:
  Remote Attestation Procedures (RATS) enable Relying Parties to assess
     the trustworthiness of a remote Attester to decide if continued
     interaction is warrented.  Evidence structures can vary making
     appraisals challenging for Verifiers.  Verifiers need to understand
     Evidence encoding formats and some of the Evidence semantics to
     appraise it.  Consequently, Evidence may require format
     transformation to an internal representation that preserves original
     semantics.  This document specifies Evidence transformation methods
     for DiceTcbInfo, concise evidence, and SPDM measurements block
     structures.  These Evidence structures are converted to the CoRIM
     internal representation and follow CoRIM defined appraisal
     procedures.


name: draft-deshpande-rats-multi-verifier
rev: 04
title: Remote Attestation with Multiple Verifiers
time: 2026-02-07T10:26:40Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-11T10:26:40Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "Policy/governance"]
tags: []
fetched_at: 2026-03-08T13:09:22.593084+00:00
source: ietf
abstract:
  IETF RATS Architecture, defines the key role of a Verifier.  In a
     complex system, this role needs to be performed by multiple Verfiers
     coordinating together to assess the full trustworthiness of an
     Attester.  This document focuses on various topological patterns for
     a multiple Verifier system.  It only covers the architectural aspects
     introduced by the Multi Verifier concept, which is neutral with
     regard to specific wire formats, encoding, transport mechanisms, or
     processing details.


name: draft-fv-rats-ear
rev: 05
title: EAT Attestation Results
time: 2025-04-04T19:41:50Z
group_uri: /api/v1/group/group/2231/
expires: 2025-08-10T15:23:44Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/", "/api/v1/doc/state/36/"]
categories: ["Data formats/interop", "Agent identity/auth", "Policy/governance"]
tags: []
fetched_at: 2026-03-08T13:09:22.596610+00:00
source: ietf
abstract:
  This document defines the EAT Attestation Result (EAR) message
     format.

     EAR is used by a verifier to encode the result of the appraisal over
     an attester's evidence.  It embeds an AR4SI's "trustworthiness
     vector" to present a normalized view of the evaluation results, thus
     easing the task of defining and computing authorization policies by
     relying parties.  Alongside the trustworthiness vector, EAR provides
     contextual information bound to the appraisal process.  This allows a
     relying party (or an auditor) to reconstruct the frame of reference
     in which the trustworthiness vector was originally computed.  EAR
     supports simple devices with one attester as well as composite
     devices that are made of multiple attesters, allowing the state of
     each attester to be separately examined.  EAR can also accommodate
     registered and unregistered extensions.  It can be serialized and
     protected using either CWT or JWT.


name: draft-howard-rats-coserv
rev: 04
title: Concise Selector for Endorsements and Reference Values
time: 2025-08-12T13:06:04Z
group_uri: /api/v1/group/group/1027/
expires: 2026-01-21T11:35:52Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/"]
categories: ["Data formats/interop", "Agent discovery/reg", "Agent identity/auth"]
tags: []
fetched_at: 2026-03-08T13:09:22.599702+00:00
source: ietf
abstract:
  In the Remote Attestation Procedures (RATS) architecture, Verifiers
     require Endorsements and Reference Values to assess the
     trustworthiness of Attesters.  This document specifies the Concise
     Selector for Endorsements and Reference Values (CoSERV), a structured
     query/result format designed to facilitate the discovery and
     retrieval of these artifacts from various providers.  CoSERV defines
     a query language and corresponding result structure using CDDL, which
     can be serialized in CBOR format, enabling efficient interoperability
     across diverse systems.


name: draft-zzn-dvs
rev: 00
title: Domain-Verified Skills (DVS) Protocol
time: 2026-03-02T22:59:29Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-03T22:59:29Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent discovery/reg", "Agent identity/auth", "A2A protocols"]
tags: []
fetched_at: 2026-03-08T13:09:22.602984+00:00
source: ietf
abstract:
  This document defines the Domain-Verified Skills (DVS) protocol, a
     lightweight mechanism for AI Agents to discover, verify, and execute
     skill definitions served over HTTPS.  A skill is a directory
     containing a SKILL.md entry point and optional bundled resources that
     instructs an AI Agent to perform a specific task or adopt a specific
     behavior.

     The central design principle of DVS is that a skill's identity and
     trustworthiness are derived entirely from the HTTPS URL at which it
     is served -- no centralized registry or third-party certification is
     required.  The operator of the URL's origin is the authoritative
     endorser of the skill.

     This trust is formalized through the concept of a Trust Root: an
     HTTPS URL prefix declared by the skill publisher that scopes the
     trust boundary for their skills.  A skill is considered verified if
     and only if its URL begins with the declared Trust Root.  For brands
     with first-party domains, the Trust Root is the domain origin.  For
     brands publishing on user-generated content platforms where the
     platform operator does not vouch for individual publishers, the Trust
     Root MUST be path-scoped to content the brand controls, ensuring that
     trust does not extend to the entire platform.

     The protocol leverages the existing trust infrastructure of the
     Domain Name System (DNS) and Transport Layer Security (TLS) and is
     backward compatible with skills already served over HTTPS, including
     those hosted on GitHub or other platforms.

full_text:
  Network Working Group                                         Z. V. Zhou
  Internet-Draft                                                    Namefi
  Intended status: Informational                              2 March 2026
  Expires: 3 September 2026


                   Domain-Verified Skills (DVS) Protocol
                              draft-zzn-dvs-00

  Abstract

     This document defines the Domain-Verified Skills (DVS) protocol, a
     lightweight mechanism for AI Agents to discover, verify, and execute
     skill definitions served over HTTPS.  A skill is a directory
     containing a SKILL.md entry point and optional bundled resources that
     instructs an AI Agent to perform a specific task or adopt a specific
     behavior.

     The central design principle of DVS is that a skill's identity and
     trustworthiness are derived entirely from the HTTPS URL at which it
     is served -- no centralized registry or third-party certification is
     required.  The operator of the URL's origin is the authoritative
     endorser of the skill.

     This trust is formalized through the concept of a Trust Root: an
     HTTPS URL prefix declared by the skill publisher that scopes the
     trust boundary for their skills.  A skill is considered verified if
     and only if its URL begins with the declared Trust Root.  For brands
     with first-party domains, the Trust Root is the domain origin.  For
     brands publishing on user-generated content platforms where the
     platform operator does not vouch for individual publishers, the Trust
     Root MUST be path-scoped to content the brand controls, ensuring that
     trust does not extend to the entire platform.

     The protocol leverages the existing trust infrastructure of the
     Domain Name System (DNS) and Transport Layer Security (TLS) and is
     backward compatible with skills already served over HTTPS, including
     those hosted on GitHub or other platforms.

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



  Zhou                    Expires 3 September 2026                [Page 1]


  Internet-Draft                     DVS                        March 2026


     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 3 September 2026.

  Copyright Notice

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

     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.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
     3.  Core Protocol . . . . . . . . . . . . . . . . . . . . . . . .   4
       3.1.  Identity and Trust  . . . . . . . . . . . . . . . . . . .   4
       3.2.  Discovery . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.  Skill Specification . . . . . . . . . . . . . . . . . . . . .   5
       4.1.  Directory Structure . . . . . . . . . . . . . . . . . . .   6
       4.2.  SKILL.md Entry Point  . . . . . . . . . . . . . . . . . .   6
       4.3.  Metadata (Frontmatter)  . . . . . . . . . . . . . . . . .   6
       4.4.  Instructions (Body) . . . . . . . . . . . . . . . . . . .   7
       4.5.  Bundled Resources . . . . . . . . . . . . . . . . . . . .   7
         4.5.1.  Additional Instructions . . . . . . . . . . . . . . .   7
         4.5.2.  Executable Scripts  . . . . . . . . . . . . . . . . .   7
         4.5.3.  Data and Reference Materials  . . . . . . . . . . . .   8
       4.6.  Progressive Loading . . . . . . . . . . . . . . . . . . .   8
     5.  Security and Permissions  . . . . . . . . . . . . . . . . . .   8
       5.1.  Same-Origin Isolation . . . . . . . . . . . . . . . . . .   9
       5.2.  Explicit Consent  . . . . . . . . . . . . . . . . . . . .   9
       5.3.  DNSSEC  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     6.  Composition . . . . . . . . . . . . . . . . . . . . . . . . .   9
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
     9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
       9.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
       9.2.  Informative References  . . . . . . . . . . . . . . . . .  11
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  12
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  12




  Zhou                    Expires 3 September 2026                [Page 2]


  Internet-Draft                     DVS                        March 2026


  1.  Introduction

     Current AI Agent skills (such as those in the Claude Agent Skills
     protocol [CLAUDE-SKILLS]) are primarily distributed via centralized
     code repositories or platform-specific upload mechanisms.  This
     creates several friction points:

     *  Identity Ambiguity: Users cannot easily verify if a skill hosted
        on a third-party platform genuinely belongs to a brand.

     *  Hosting Friction: Brands must manage external accounts and
        synchronization instead of using their existing web
        infrastructure.

     *  Security Risks: Malicious skills can spoof brand names on open
        platforms to exfiltrate data.

     The Domain-Verified Skills (DVS) protocol returns to the fundamental
     logic of the Web: the URL is the Identity.  By serving skills
     directly from a brand-controlled URL prefix, we leverage the existing
     global trust of the DNS and HTTPS infrastructure.

     For brands with first-party domains, the Trust Root is the domain
     itself (e.g., https://microsoft.com/).  For brands that publish on
     user-generated content platforms such as GitHub or Hugging Face, the
     Trust Root is scoped to the brand's path on that platform (e.g.,
     https://github.com/microsoft/).  This allows DVS to provide brand-
     verified skill identity across all hosting configurations, without
     requiring brands to self-host infrastructure.

     This protocol is designed to be compatible with existing skill
     formats and distributions.  A skill already hosted on GitHub (e.g.,
     https://github.com/microsoft/repo/blob/main/.../SKILL.md) is
     immediately usable under DVS by registering https://github.com/
     microsoft/ as the Trust Root, with no changes to the skill files
     themselves.  In particular, a skill directory conforming to DVS can
     be directly consumed by any agent that understands the SKILL.md
     convention, while also gaining the identity and trust properties
     conferred by domain-verified hosting.

  2.  Conventions and Definitions

     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.




  Zhou                    Expires 3 September 2026                [Page 3]


  Internet-Draft                     DVS                        March 2026


     The following terms are used in this document:

     Skill:  A directory containing a SKILL.md entry point and optional
        bundled resources (scripts, templates, data files, additional
        instructions) that directs an AI Agent to perform a specific task
        or adopt a specific behavior.

     SKILL.md:  The mandatory Markdown entry-point file within a skill
        directory.  It contains YAML frontmatter metadata and human-
        readable instructions for the Agent.

     Agent:  An AI system capable of fetching, interpreting, and executing
        Skill instructions.

     Skill URL:  The HTTPS URL of the skill directory (or its SKILL.md
        entry point).  This URL serves as the globally unique identifier
        of the Skill.

     Trust Root:  An HTTPS URL prefix that defines the trust boundary for
        a skill or set of skills.  A skill is considered verified under a
        Trust Root if and only if its Skill URL begins with the Trust Root
        prefix.  For first-party brand domains, the Trust Root is
        typically the domain origin (e.g., https://microsoft.com/).  For
        user-generated content platforms, the Trust Root MUST be scoped to
        a path controlled by the brand (e.g., https://github.com/
        microsoft/).

     Hosting Domain:  The domain component of the Trust Root URL,
        considered the network-level endorser of the Skill via DNS and
        TLS.

     Bundled Resource:  Any file within the skill directory other than
        SKILL.md, including additional instruction files, executable
        scripts, templates, schemas, and data files.

  3.  Core Protocol

     The identity of a skill is defined strictly by its HTTPS URL.

  3.1.  Identity and Trust

     Skills MUST be served via HTTPS [RFC9110].  Agents MUST NOT fetch or
     execute skills served over plain HTTP.

     The identity and trust of a skill is defined by its Trust Root.  A
     skill's URL MUST begin with its declared Trust Root prefix for the
     skill to be considered verified under that root.




  Zhou                    Expires 3 September 2026                [Page 4]


  Internet-Draft                     DVS                        March 2026


     For first-party brand hosting, the Trust Root is the domain origin:

     Trust Root: https://example.com/
     Skill URL:  https://example.com/.well-known/
                 skills/support/SKILL.md

     For user-generated content platforms, the Trust Root MUST be scoped
     to a path controlled by the brand.  Agents MUST NOT accept a bare UGC
     platform domain (e.g., https://github.com/) as a Trust Root, as this
     would confer trust to all content on the platform:

     Trust Root: https://github.com/example-org/
     Skill URL:  https://github.com/example-org/
                 repo/blob/main/skills/SKILL.md

     A skill URL that does not begin with its declared Trust Root prefix
     MUST be rejected by the Agent.

  3.2.  Discovery

     Skills MAY be hosted at any valid URL path on a domain (e.g.,
     https://example.com/skills/my-assistant/SKILL.md).

     Official brand skills SHOULD be served from the well-known path
     prefix:

     /.well-known/skills/{skill-name}/SKILL.md

     This follows the conventions established by [RFC8615] for well-known
     URIs.

     Skills MAY be indexed in the domain's sitemap.xml [SITEMAP] to enable
     automated agent discovery.  Agents supporting discovery SHOULD check
     for skill entries in the sitemap when exploring a domain's available
     skills.

     A domain MAY serve a skill index document at:

     /.well-known/skills/index.json

     The index document, if present, SHOULD contain an array of objects,
     each with name, description, and path fields pointing to available
     skills on the domain.

  4.  Skill Specification






  Zhou                    Expires 3 September 2026                [Page 5]


  Internet-Draft                     DVS                        March 2026


  4.1.  Directory Structure

     A Domain-Verified Skill is a directory containing at minimum a
     SKILL.md file.  The directory MAY contain additional files organized
     by purpose:

     my-skill/
     +-- SKILL.md              (entry point - REQUIRED)
     +-- ADVANCED.md           (additional instructions - OPTIONAL)
     +-- REFERENCE.md          (detailed reference docs - OPTIONAL)
     +-- scripts/
     |   +-- process.py        (executable script - OPTIONAL)
     |   +-- validate.sh       (executable script - OPTIONAL)
     +-- templates/
     |   +-- report.html       (template file - OPTIONAL)
     +-- data/
         +-- schema.json       (data/reference file - OPTIONAL)

     When served over HTTPS, the directory structure is represented by URL
     paths relative to the skill's base URL.  For example, a skill at
     https://example.com/.well-known/skills/my-skill/ would have its entry
     point at:

     https://example.com/.well-known/skills/my-skill/SKILL.md

     And a bundled script at:

     https://example.com/.well-known/skills/my-skill/scripts/process.py

  4.2.  SKILL.md Entry Point

     Every skill directory MUST contain a file named SKILL.md.  This file
     MUST be encoded in UTF-8 and served with the media type text/markdown
     [RFC7763].

     The file consists of two parts:

     1.  YAML frontmatter (metadata) - REQUIRED

     2.  Markdown body (instructions) - REQUIRED

  4.3.  Metadata (Frontmatter)

     SKILL.md files MUST begin with a YAML frontmatter block delimited by
     --- lines.  The frontmatter MUST contain the following fields:

     name:  A short, human-readable name for the skill.  MUST NOT exceed




  Zhou                    Expires 3 September 2026                [Page 6]


  Internet-Draft                     DVS                        March 2026


        64 characters.  MUST contain only lowercase letters, numbers, and
        hyphens.

     description:  A brief description of the skill's purpose and
        capabilities, including guidance on when an Agent should trigger
        the skill.  MUST NOT be empty.  MUST NOT exceed 1024 characters.

     Example:

     name: customer-support
     description: Handles common customer support inquiries for
       Acme Corp products. Use when the user asks about product
       returns, warranty claims, or order status.

  4.4.  Instructions (Body)

     The body of SKILL.md, following the frontmatter, MUST contain human-
     readable instructions for the Agent.  These instructions define the
     behavior, constraints, and capabilities of the skill.

     Instructions SHOULD be written as clear, step-by-step procedural
     guidance.  They MAY reference bundled resources using relative URLs
     (e.g., [see advanced guide](ADVANCED.md) or run the script at
     scripts/process.py).

  4.5.  Bundled Resources

     Skills MAY include additional files alongside SKILL.md.  These
     bundled resources fall into three categories:

  4.5.1.  Additional Instructions

     Additional Markdown files (e.g., ADVANCED.md, REFERENCE.md, FORMS.md)
     provide specialized guidance, detailed API references, or extended
     workflows.  These files:

     *  SHOULD use the .md extension and text/markdown media type.

     *  Are loaded by the Agent only when referenced from SKILL.md or when
        the task context requires them.

  4.5.2.  Executable Scripts

     Scripts (e.g., Python, Shell, JavaScript) provide deterministic
     operations that the Agent can execute.  These files:

     *  MUST reside within the same skill directory (same-origin).




  Zhou                    Expires 3 September 2026                [Page 7]


  Internet-Draft                     DVS                        March 2026


     *  Are executed by the Agent via its runtime environment; only the
        script's output enters the Agent's context, not the script source
        code itself.

     *  MUST be subject to the Explicit Consent requirement defined in
        Section 5.2 before execution.

  4.5.3.  Data and Reference Materials

     Data files (e.g., JSON schemas, CSV datasets, configuration
     templates, API documentation) provide factual lookup material.  These
     files:

     *  MUST reside within the same skill directory (same-origin).

     *  Are read by the Agent on demand when the task requires specific
        reference information.

     *  Impose no context cost until actually accessed.

  4.6.  Progressive Loading

     Agents implementing DVS SHOULD employ a progressive loading strategy
     to manage context efficiently:

     Level 1 - Metadata (always loaded):  The YAML frontmatter (name and
        description) is loaded at agent startup or skill registration
        time.  This enables skill discovery with minimal token cost
        (approximately 100 tokens per skill).

     Level 2 - Instructions (loaded on trigger):  The body of SKILL.md is
        fetched and loaded into the agent's context only when the skill is
        triggered by a matching user request.

     Level 3 - Resources (loaded as needed):  Bundled resources
        (additional markdown files, scripts, data files) are accessed only
        when referenced during execution.  Scripts are executed and only
        their output is loaded into context.

     This three-level approach ensures that a domain can publish many
     skills without imposing context overhead on agents, as only the
     metadata of registered skills is persistently loaded.

  5.  Security and Permissions







  Zhou                    Expires 3 September 2026                [Page 8]


  Internet-Draft                     DVS                        March 2026


  5.1.  Same-Origin Isolation

     Agents MUST restrict a skill's automated access to resources within
     its Trust Root prefix.  A skill with Trust Root https://github.com/
     example-org/ MUST NOT be permitted to automatically access resources
     outside that prefix (including other GitHub users or repos) without
     explicit user consent.

     Bundled resources (scripts, data files, templates) referenced by a
     skill MUST reside within the same Trust Root prefix as the SKILL.md
     file.  Agents MUST reject references to resources outside the skill's
     Trust Root unless the user explicitly approves the access.

     This prevents a compromised or malicious skill from leveraging its
     trusted context to exfiltrate data from, or perform actions on,
     unrelated origins or paths.

  5.2.  Explicit Consent

     Agents MUST display the source domain to the user and request
     explicit confirmation before executing any non-textual instructions
     contained in a skill (e.g., shell commands, API calls, file system
     operations, running bundled scripts).

     The consent prompt SHOULD clearly indicate:

     *  The Trust Root of the skill.

     *  A description of the action to be performed.

     *  Any resources that will be accessed or modified.

     Textual instructions (Markdown content) MAY be loaded without
     additional consent beyond the initial skill activation.  Executable
     content (scripts, commands) MUST always require explicit consent.

  5.3.  DNSSEC

     Domain operators SHOULD deploy DNSSEC [RFC4033] to prevent DNS
     spoofing attacks that could redirect agents to malicious skill files
     hosted on attacker-controlled infrastructure.

  6.  Composition

     A skill MAY reference other skills via their full HTTPS URLs.  When
     an Agent encounters a referenced skill URL during execution, it
     SHOULD dynamically fetch and load the referenced skill if the current
     context requires the extended capabilities it provides.



  Zhou                    Expires 3 September 2026                [Page 9]


  Internet-Draft                     DVS                        March 2026


     Each referenced skill is subject to its own Trust Root's trust and
     security policies.  Agents MUST apply the Same-Origin Isolation
     policy (Section 5.1) independently to each loaded skill based on its
     own Trust Root.

     When composing skills across domains, agents SHOULD clearly
     communicate to the user that the trust context is being extended to
     additional domains.

  7.  Security Considerations

     The primary security property of this protocol is that trust is
     anchored to domain ownership.  This inherits both the strengths and
     weaknesses of the existing Web PKI and DNS infrastructure.

     Skill spoofing is mitigated by the HTTPS requirement, which ensures
     that only the legitimate operator of a domain can serve skills from
     that domain.  DNSSEC (Section 5.3) provides an additional layer of
     protection against DNS-level attacks.

     Agents implementing this protocol should be aware of the following
     risks:

     *  Domain compromise: If a domain is compromised, all skills served
        from it should be considered compromised.

     *  Subdomain delegation: Skills on subdomains should be treated as
        distinct trust contexts from the parent domain.

     *  UGC platform Trust Roots: On user-generated content platforms,
        agents MUST enforce path-scoped Trust Roots.  Accepting a bare
        platform domain (e.g., https://github.com/) as a Trust Root would
        allow any user on that platform to publish skills that appear
        equally trusted as a legitimate brand's skills.

     *  Transitive trust in composition: When skills reference other
        skills (Section 6), the trust chain extends across domains.
        Agents should clearly communicate this to users.

     *  Script execution: Bundled scripts execute with the permissions of
        the agent's runtime environment.  Malicious scripts could perform
        unauthorized file access, network calls, or data exfiltration.
        The Explicit Consent requirement (Section 5.2) mitigates this
        risk, but agents SHOULD also sandbox script execution where
        possible.






  Zhou                    Expires 3 September 2026               [Page 10]


  Internet-Draft                     DVS                        March 2026


     *  External resource fetching: Skills that instruct agents to fetch
        data from external URLs pose particular risk, as fetched content
        may contain malicious instructions.  Agents SHOULD treat
        externally-fetched content as untrusted.

  8.  IANA Considerations

     This document requests registration of the well-known URI suffix
     skills in the "Well-Known URIs" registry established by [RFC8615].

     URI suffix:  skills

     Change controller:  Namefi

     Specification document:  This document (Section 3.2)

  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/rfc/rfc2119>.

     [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
                Rose, "DNS Security Introduction and Requirements",
                RFC 4033, DOI 10.17487/RFC4033, March 2005,
                <https://www.rfc-editor.org/rfc/rfc4033>.

     [RFC7763]  Leonard, S., "The text/markdown Media Type", RFC 7763,
                DOI 10.17487/RFC7763, March 2016,
                <https://www.rfc-editor.org/rfc/rfc7763>.

     [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/rfc/rfc8174>.

     [RFC8615]  Nottingham, M., "Well-Known Uniform Resource Identifiers
                (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
                <https://www.rfc-editor.org/rfc/rfc8615>.

     [RFC9110]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
                Ed., "HTTP Semantics", STD 97, RFC 9110,
                DOI 10.17487/RFC9110, June 2022,
                <https://www.rfc-editor.org/rfc/rfc9110>.

  9.2.  Informative References



  Zhou                    Expires 3 September 2026               [Page 11]


  Internet-Draft                     DVS                        March 2026


     [CLAUDE-SKILLS]
                Anthropic, "Agent Skills Overview", n.d.,
                <https://platform.claude.com/docs/en/agents-and-tools/
                agent-skills/overview>.

     [SITEMAP]  sitemaps.org contributors, "Sitemaps XML Format", n.d.,
                <https://www.sitemaps.org/protocol.html>.

  Acknowledgments

     The authors would like to thank the broader AI agent community for
     discussions that informed this protocol design.

  Author's Address

     Zainan Victor Zhou
     Namefi
     Email: zzn@namefi.io

































  Zhou                    Expires 3 September 2026               [Page 12]


name: draft-ietf-rats-ar4si
rev: 09
title: Attestation Results for Secure Interactions
time: 2026-02-17T07:09:01Z
group_uri: /api/v1/group/group/2231/
expires: 2026-02-16T14:20:06Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/", "/api/v1/doc/state/38/"]
categories: ["Data formats/interop", "Agent identity/auth", "Policy/governance"]
tags: []
fetched_at: 2026-03-08T13:09:22.606063+00:00
source: ietf
abstract:
  This document defines reusable Attestation Result information
     elements.  When these elements are offered to Relying Parties as
     Evidence, different aspects of Attester trustworthiness can be
     evaluated.  Additionally, where the Relying Party is interfacing with
     a heterogeneous mix of Attesting Environment and Verifier types,
     consistent policies can be applied to subsequent information exchange
     between each Attester and the Relying Party.

     This document also defines two serialisations of the proposed
     information model, utilising CBOR and JSON.


name: draft-wiethuechter-drip-det-tada
rev: 01
title: Registration & Usage of DRIP Entity Tags for Trustworthy Air Domain Awareness
time: 2025-10-02T17:42:04Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-05T17:42:04Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "Policy/governance"]
tags: []
fetched_at: 2026-03-08T13:09:22.612141+00:00
source: ietf
abstract:
  This document standardizes usage of Drone Remote Identification
     Protocol (DRIP) Entity Tags (DETs) as identifiers to enable
     trustworthy Air Domain Awareness (ADA) for Unmanned Aircraft Systems
     (UAS) in Remote Identification (RID), UAS Traffic Management (UTM)
     and Advanced Air Mobility (AAM).  DETs can serve as Session IDs for
     privacy, Authentication Key IDs for accountability, and encryption
     key IDs for confidentiality.

full_text:
  drip Working Group                                       A. Wiethuechter
  Internet-Draft                                        AX Enterprize, LLC
  Intended status: Standards Track                            R. Moskowitz
  Expires: 5 April 2026                                     HTT Consulting
                                                            2 October 2025


    Registration & Usage of DRIP Entity Tags for Trustworthy Air Domain
                                 Awareness
                    draft-wiethuechter-drip-det-tada-01

  Abstract

     This document standardizes usage of Drone Remote Identification
     Protocol (DRIP) Entity Tags (DETs) as identifiers to enable
     trustworthy Air Domain Awareness (ADA) for Unmanned Aircraft Systems
     (UAS) in Remote Identification (RID), UAS Traffic Management (UTM)
     and Advanced Air Mobility (AAM).  DETs can serve as Session IDs for
     privacy, Authentication Key IDs for accountability, and encryption
     key IDs for confidentiality.

  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 5 April 2026.

  Copyright Notice

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

     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



  Wiethuechter & Moskowitz  Expires 5 April 2026                  [Page 1]


  Internet-Draft                  det-tada                    October 2025


     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.  Purpose . . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.2.  Background  . . . . . . . . . . . . . . . . . . . . . . .   4
       1.3.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
       2.1.  Additional Definitions  . . . . . . . . . . . . . . . . .   5
     3.  Interactions & Responsibilities . . . . . . . . . . . . . . .   6
       3.1.  UAS Observers . . . . . . . . . . . . . . . . . . . . . .   6
       3.2.  UAS Operators . . . . . . . . . . . . . . . . . . . . . .   7
       3.3.  UAS Manufacturers . . . . . . . . . . . . . . . . . . . .   8
       3.4.  HDA Operators . . . . . . . . . . . . . . . . . . . . . .   9
       3.5.  RAA Operators . . . . . . . . . . . . . . . . . . . . . .  10
       3.6.  Apex Operators  . . . . . . . . . . . . . . . . . . . . .  11
     4.  Requirements for DIME Operation . . . . . . . . . . . . . . .  11
       4.1.  Common UAS RID Data Model . . . . . . . . . . . . . . . .  11
       4.2.  Registration  . . . . . . . . . . . . . . . . . . . . . .  13
         4.2.1.  Disclaimer  . . . . . . . . . . . . . . . . . . . . .  13
         4.2.2.  Interaction Model . . . . . . . . . . . . . . . . . .  13
         4.2.3.  Interface & Encoding  . . . . . . . . . . . . . . . .  15
         4.2.4.  Registration Model  . . . . . . . . . . . . . . . . .  17
         4.2.5.  Response Model  . . . . . . . . . . . . . . . . . . .  19
       4.3.  Query . . . . . . . . . . . . . . . . . . . . . . . . . .  20
         4.3.1.  Public Information Registries . . . . . . . . . . . .  21
         4.3.2.  Private Information Registries  . . . . . . . . . . .  21
     5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  23
       5.1.  RAA Delegation for CAAs . . . . . . . . . . . . . . . . .  23
       5.2.  Well-Known URIs . . . . . . . . . . . . . . . . . . . . .  23
       5.3.  RDAP Extensions Registry  . . . . . . . . . . . . . . . .  23
       5.4.  Media Types . . . . . . . . . . . . . . . . . . . . . . .  24
         5.4.1.  application/drip+cwt Registration . . . . . . . . . .  24
         5.4.2.  application/drip+jwt Registration . . . . . . . . . .  25
       5.5.  DRIP CBOR/JSON Keys . . . . . . . . . . . . . . . . . . .  25
         5.5.1.  Review Criteria . . . . . . . . . . . . . . . . . . .  26
         5.5.2.  CBOR/JSON Key Fields  . . . . . . . . . . . . . . . .  27
         5.5.3.  Registration Form . . . . . . . . . . . . . . . . . .  27
         5.5.4.  Initial Values  . . . . . . . . . . . . . . . . . . .  27
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .  30
       6.1.  Cryptographic Materials . . . . . . . . . . . . . . . . .  30
     7.  Privacy & Transparency Considerations . . . . . . . . . . . .  30
       7.1.  DETs as Session ID and Authentication Key ID  . . . . . .  31
       7.2.  Selective Encryption  . . . . . . . . . . . . . . . . . .  31
     8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  32



  Wiethuechter & Moskowitz  Expires 5 April 2026                  [Page 2]


  Internet-Draft                  det-tada                    October 2025


       8.1.  Normative References  . . . . . . . . . . . . . . . . . .  32
       8.2.  Informative References  . . . . . . . . . . . . . . . . .  33
     Appendix A.  DRIP CDDL Prelude  . . . . . . . . . . . . . . . . .  36
     Appendix B.  HID Abbreviation . . . . . . . . . . . . . . . . . .  37
     Appendix C.  Compliance Testing . . . . . . . . . . . . . . . . .  39
       C.1.  Registration Interface  . . . . . . . . . . . . . . . . .  39
       C.2.  Public Query Interface  . . . . . . . . . . . . . . . . .  40
       C.3.  Private Query Interface . . . . . . . . . . . . . . . . .  40
       C.4.  Compliance Submission Forms . . . . . . . . . . . . . . .  40
     Appendix D.  DRIP Key Infrastructure X.509 (DKIX) . . . . . . . .  40
       D.1.  Signing Request . . . . . . . . . . . . . . . . . . . . .  41
       D.2.  Lite Profile  . . . . . . . . . . . . . . . . . . . . . .  42
       D.3.  Full Profile  . . . . . . . . . . . . . . . . . . . . . .  44
       D.4.  Certificate Fields  . . . . . . . . . . . . . . . . . . .  46
         D.4.1.  Serial Number . . . . . . . . . . . . . . . . . . . .  46
         D.4.2.  Subject . . . . . . . . . . . . . . . . . . . . . . .  46
         D.4.3.  Issuer  . . . . . . . . . . . . . . . . . . . . . . .  47
         D.4.4.  Subject Alternative Name IP6  . . . . . . . . . . . .  47
         D.4.5.  Subject Alternative Name URI  . . . . . . . . . . . .  47
         D.4.6.  Subject Key Identifier  . . . . . . . . . . . . . . .  48
         D.4.7.  Authority Key Identifier  . . . . . . . . . . . . . .  48
         D.4.8.  CA Policy OIDs  . . . . . . . . . . . . . . . . . . .  48
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  51

  1.  Introduction

  1.1.  Purpose

     This document provides to stakeholders in a National Airspace System
     (NAS), such as a Civil Aviation Authority (CAA) and its constituents,
     a point of entry into a set of relevant standards.  These standards
     provide guidance to enable trustworthy Air Domain Awareness (ADA)
     primarily via cooperative technologies.  Such technologies can
     include, but are not limited to, Unmanned Aircraft (UA) Systems (UAS)
     Remote Identification (RID), UAS Traffic Management (UTM) and
     Advanced Air Mobility (AAM).

     This document specifies an interoperable manner of achieving the
     stated objectives in an international context to be used by CAAs in a
     relevant Means of Compliance (MOC).  One such MOC is ASTM [F3586] for
     UAS RID to comply with the United States (US) CAA regulations.

     A CAA MAY override any technical specification in this document but
     MUST, if claiming compliance with this document, provide the reason
     and an alternative specification satisfying the same objective.






  Wiethuechter & Moskowitz  Expires 5 April 2026                  [Page 3]


  Internet-Draft                  det-tada                    October 2025


  1.2.  Background

     [RFC9153] provides comprehensive background on the UAS RID use-case
     and the UTM/AAM context.

     Trustworthiness revolves around identification and authentication.
     [RFC9374] defines the Drone Remote Identification Protocol (DRIP)
     Entity Tag (DET), a trustable identifier backed by asymmetric
     cryptography.  [RFC9575] standardizes authentication of DETs and
     associated information using strong cryptography suited for
     constrained mobile wireless links (typical of Broadcast RID).
     Broadcast and Network RID are defined by ASTM [F3411] which
     designates the International Civil Aviation Organization (ICAO) to
     maintain code-points for Specific Session ID Types and Specific
     Authentication Methods (SAMs) [ICAO-NUMBERS].  ICAO includes DETs as
     a Specific Session ID Type and lists the four DRIP SAMs.

     DETs generated by registrants (typically a UAS Operator or UAS) are
     merely proposed until they are registered within the hierarchy
     consisting of at least two levels above the leaf DET: Registered
     Assigning Authority (RAA) and Hierarchial Host Identity Tag (HHIT)
     Domain Authority (HDA).  The registry system, made up of DRIP
     Identity Management Entities (DIMEs) acting as either RAAs or HDAs,
     ensures uniqueness within the hierarchy, endorses inclusion through
     X.509 certificates, and provides access to public and private
     information associated with a DET registration.  Public information
     is served using the Domain Name System (DNS) and is specified in
     [DET-DNS].  Private information, such as Personally Identifiable
     Information (PII), is served using the Registration Data Access
     Protocol (RDAP, [STD95]) and protected through policy based
     differentiated access.

     This document specifies fundamental registration processes and
     interactions surrounding the Private Information Registry function
     defined in the DRIP Architecture ([RFC9434]).

  1.3.  Scope

     Participating entities are assumed in this document to be in
     compliance with relevant existing UAS standards such as ASTM [F3411],
     [F3548] and [ICAO-ACCP].

     This document governs use of a DET in the following cases:

     1.  An entity that uses a Session ID (some participating entities,
         e.g. HDAs, may not need Session IDs), MUST use a DET for that
         Session ID.




  Wiethuechter & Moskowitz  Expires 5 April 2026                  [Page 4]


  Internet-Draft                  det-tada                    October 2025


     2.  An entity that participates in DRIP interactions (even if not
         needing a Session ID), MUST use a DET for the DRIP public
         authentication key ID in those interactions.

     3.  An entity that requires a strongly cryptographically verifiable
         IP compatible identifier, MAY use a DET for any other legal
         purpose.

     4.  An entity SHOULD NOT use a DET as a locator in physical or
         logical space (e.g. as a globally routable IPv6 address outside
         of an overlay network), as deconflation is intended, see
         [RFC9063].

     The archetypal case is a UAS for which the DET serves as both the UAS
     ID (first case above) and the Authentication Key ID (second case).

        Author Note: narrow context for at least first bullet above.

  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.

  2.1.  Additional Definitions

     This document makes use of terms (PII, USS, etc.) defined in
     [RFC9153], [RFC9434] and [RFC9374].  For convenience of the reader,
     some of the major definitions are restated here.

     DRIP Identity Management Entity (DIME):  Originally defined in
        [RFC9434] and expanded technically in [DET-DNS].  An entity
        providing registrar and registry services specifically for DETs.
        They can act as either an Registered Assigning Authority (RAA) or
        Hierarchial Host Identity Tag (HHIT) Domain Authority (HDA).

     Web Token:  In the context of this specification; a Web Token can be
        either a Concise Binary Object Representation (CBOR, [STD94]) Web
        Token (CWT, [RFC8392]) or JavaScript Object Notation (JSON,
        [STD90]) Web Token (JWT, [RFC7519]).









  Wiethuechter & Moskowitz  Expires 5 April 2026                  [Page 5]


  Internet-Draft                  det-tada                    October 2025


  3.  Interactions & Responsibilities

     This section outlines the various entity roles in the ecosystem.  For
     each, it summarizes motivations for participating in that DRIP role,
     as well as the interactions and responsibilities they have in doing
     so.  All entity roles, except as otherwise noted, MUST register a DET
     with a parent entity in the corresponding parental role (e.g. an HDA
     must register with an RAA), as per Section 4.2, and MUST use it
     subsequently in all DRIP interactions requiring an entity ID.

  3.1.  UAS Observers

     An Observer is typically an individual who has a device capable of
     wirelessly receiving Broadcast RID whether it be an opportunistic
     passerby with a local-only (i.e. non-Internet connected) smartphone
     application or a widely deployed sensing system with various IP-based
     back-hauls.  Each has their own motivations for detecting a UAS in
     their area and querying for additional information.  Typically in
     DRIP, Observers are expected to use DNS (when able) to obtain at
     least the public keys of unknown DETs and use it to validate
     signatures found in ASTM [F3411] Authentication Messages.  Some
     Observers may be granted, by cognizant authorities, authorization to
     perform more detailed queries of further information, that is
     considered private (as not explicitly classified as public, placed in
     DNS, and/or transmitted in cleartext in Broadcast RID).

        Author Note: Broadcast RID here can be dropped or substituted for
        some phrase comparing Observers to a sensor head, but distinct
        from a Display-only Observer.  If that makes sense and if it is a
        good distinction to have?  One could say Display Applications are
        in a way Observers (albeit very far removed from the field in most
        cases where the term is used).  Unless we make them their own
        class of users that could use DETs (and for what?)

     All Observers supporting DRIP:

     *  MUST adhere to relevant details of Section 6.4.2 of [RFC9575] with
        regards to receive processing of DRIP SAMs.

        -  Processing of SAMs MAY be deferred or outsourced to a dedicated
           system.

     *  RECOMMEND display all DETs following [RFC5952] or as described in
        Appendix B.







  Wiethuechter & Moskowitz  Expires 5 April 2026                  [Page 6]


  Internet-Draft                  det-tada                    October 2025


        Author Note: as justification for "processing MAY be deferred":
        Intention here was to allow for Observers not needing to fully
        process data if desired and push said processing to SDSPs.  An
        example is a slim Finder concept that does no parsing of RID data,
        just extraction out of transport framing.

     Observers authorized by cognizant authorities to access any private
     (in addition to all public) information recorded as part of the
     registration process also:

     *  MUST support RDAP authentication/authorization mechanisms allowed
        by the cognizant authority.

        -  Those RECOMMENDED for global harmonization are identified in
           Section 4.3.2.4.

     *  MUST register to authentication systems as required by the
        cognizant authority.

        -  A DIME MAY be used as part of an authentication system.

  3.2.  UAS Operators

     UAS Operators is used herein as a catch-all term for several more
     specific UAS related roles: Remote Pilot, Pilot In Command (PIC),
     party (typically an organization) to whom or which the UAS is
     registered with the cognizant CAA, etc.  DRIP does not attempt to
     clarify the definition of Operator to match any specific CAA, instead
     using the ambiguity to group these roles based on their similar DRIP
     interactions.

     A UAS Operator's desire to use DETs can be any number of the
     following operational factors:

     *  Confidentiality of flights through Session IDs.

     *  Privacy of Remote Pilots by encrypting their Ground Control
        Station (GCS) position.

        -  This option may be constrained by their jurisdiction's RID
           regulations.

     *  Reputation of their UAS based on observation and reports of
        behavior supported by Authentication.

     To participate a UAS Operator SHOULD use a DET, registered either
     with an RAA or HDA, as part of any interactions in DRIP, such as
     registering a UAS Session ID for their UA.  A UAS Operator MAY use



  Wiethuechter & Moskowitz  Expires 5 April 2026                  [Page 7]


  Internet-Draft                  det-tada                    October 2025


     another cryptographic scheme for interactions but it MUST be
     asymmetric with their public key accessible to all domain
     participants via a standardized method for the cryptographic purpose
     of signature verification.

  3.3.  UAS Manufacturers

     While UAS Manufactures do not have a direct requirement for DRIP,
     they typically wish to maintain good reputation of their brands and
     are often driven by market forces.  Such forces include requirements
     and preferences of both UAS Observers and Operators.

     This document assumes a UAS Manufacturer is already in compliance
     with ASTM [F3411].  Thus those that wish to support DRIP also:

     *  MUST provide a mechanism, typically through a GCS, to generate and
        register a DET for use as either a Session ID, Authentication Key
        ID or both.

        -  MUST bind DET to both UAS Serial Number and Operator.  Binding
           MAY be indirect if system can verify Serial Number already
           registered to Operator.

        -  SHOULD be issued in a manner that keeps private key ONLY ever
           on UA, does not expose it to GCS etc., but MAY be done in
           manner that exposes it to GCS or Operator if necessary.

        -  SHOULD allow user selection of a parent DIME (typically HDA)
           using a URI, Hierarchy ID (HID) value, or both

        -  MAY support registering multiple DETs in a batch transaction

     *  SHOULD provide a mechanism to enable, during registration,
        subsequent encryption of selected fields (e.g. pilot/GCS
        location), only if the CAA allows it.

     *  MUST follow Section 6 of [RFC9575] as it relates to transmission
        of SAMs, when using DET as an Authentication Key ID

     *  MUST, in the [F3411] Basic ID Message, set the UAS ID Type to
        Specific Session ID, Specific Session ID Type to DRIP Entity ID,
        and encode the DET in network byte order, when using DET as a UAS
        Session ID

     *  MAY use a DET, following Section 4.2 of [RFC9374], as a UAS Serial
        Number





  Wiethuechter & Moskowitz  Expires 5 April 2026                  [Page 8]


  Internet-Draft                  det-tada                    October 2025


        -  It is expected that the UAS Manufacturer runs their own HDA,
           under which these DETs are registered

  3.4.  HDA Operators

     In the UTM context, it is expected that the HDA function will be
     provided by a UAS Service Supplier (USS) to its clients (e.g. UAS
     Operators).  This can be in-house or out-sourced to a service bureau
     more specialized in cryptographically verifiable identifiers usable
     to access data and systems on networks.  Outside the UTM context, an
     HDA can be a stand-alone provider to any registrant desiring a DET,
     or more generally HHIT.

     Being associated with a USS has some operational benefits:

     *  Ease for UAS Operators to use both Session IDs and UTM together

     *  Binding between the DET and Operational Intent

        -  Enables safer use of encryption

        -  Ability to keep DET private until just before an operation goes
           active

     An HDA Operator:

     *  MUST register, with its parent RAA, one or more DETs, and use it
        or them in DRIP interactions

     *  MUST implement interfaces and functions described in Section 4

     *  MUST maintain DET registrations with relevant PII as required by
        their jurisdiction

     *  MUST fulfill the requirements of their jurisdiction

     *  SHOULD NOT provide to clients the ability to enable encryption of
        data elements considered PII, especially in Broadcast RID

     As part of a USS an HDA Operator also:

     *  MAY provide encryption ID services, if allowed by jurisdiction

     *  MAY have its registration interfaces (Section 4.2) be integrated
        into relevant USS interfaces and functions

     *  SHOULD defer the publishing of a client DET in DNS when it is
        bound with an Operational Intent until it is "active"



  Wiethuechter & Moskowitz  Expires 5 April 2026                  [Page 9]


  Internet-Draft                  det-tada                    October 2025


        -  Methods to sync an Operational Intent in a USS state and DET
           state in HDA are out of scope for this document

  3.5.  RAA Operators

     In the context of this document, RAA Operators are typically CAAs or
     other cognizant authorities of a Nation State.  Each Nation State is
     allocated four RAA values that are used at their discretion.  To
     obtain these allocations, a Nation State contacts the Apex operator
     for the UAS or other applicable hierarchy, currently IANA on behalf
     of ICAO, requesting their provisioning providing any details required
     by the Apex Operator to configure domain delegations.

     Each RAA has the responsibility to delegate HDAs under them.
     Allocation methods of HDA values are at the discretion of the RAA
     Operator and their policies.  Any requirements to operate under an
     RAA, beyond those as defined in this document to operate as an HDA,
     are out of scope for this document.

     An RAA Operator:

     *  MUST obtain an RAA value(s) from the Apex Operator and provide
        content for NS RRType(s), see Section 5

     *  MUST register, with its parent (if any), one or more DETs, and use
        it or them in DRIP interactions

     *  MUST implement interfaces and functions described in Section 4

     *  MUST maintain DET registrations with relevant PII as required by
        their jurisdiction

     *  MUST provide requirements for prospective HDA Operators, and
        SHOULD do so publicly via an easily located web site

     *  MUST ensure HDA Operator compliance with this specification

        Author Note: subsection or appendix on a potential RAA scheme for
        CAA? i.e. 1x MIL, 1x GOV, 1x COMMERCIAL, 1x SPARE with some
        example guidance on HDA allocation?











  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 10]


  Internet-Draft                  det-tada                    October 2025


  3.6.  Apex Operators

     The Apex role is the administration root and the domain apex for a
     specific IPv6 prefix which are typically associated with an industry
     sector (i.e. DETs being for aviation).  This translates to the
     technical tasking of delegating RAA values and maintaining the
     reverse DNS zone associated with the allocated IPv6 prefix which
     contain the DNS delegations to RAAs.  An Apex in its capacity as the
     administration root MAY endorse the required RAA delegation in the
     hierarchy.

     Currently IANA performs the functions of RAA delegation (with no
     endorsement) and DNS zone maintenance for the DET prefix.  This is
     largely a custodial task as critical portions of the RAA range, with
     regards to aviation, are already reserved or allocated with the rest
     of the range unassigned.

     In the context of aviation pre-allocated RAAs to CAAs are currently
     expected to mutually cross-certify as specified in [ICAO-ACCP].

  4.  Requirements for DIME Operation

     The requirements below apply to both RAA and HDA Operators with a
     focus on how HDA Operators provide registration and related services
     for their clients (i.e. UAS Operators and their UAS).  All data
     models are represented in this document using the Concise Data
     Definition Language (CDDL, [RFC8610]) using the prelude defined in
     Appendix E of [RFC8610] as well as an additional DRIP-specific
     prelude defined in Appendix A.

  4.1.  Common UAS RID Data Model

     A common data model is specified by DRIP for various UAS RID elements
     typically transmitted over ASTM [F3411].

     The field names and their general typing of Figure 1 are borrowed
     from the ASTM [F3411] data dictionary (Table 1 and Table 2).  See
     that document for additional context and background information on
     aviation application-specific interpretation of the field semantics.
     The contents of this model are considered opaque to DRIP.

     The model is an expansion upon the BRID RRType model, which only
     contained static data, defined in Section 5.2 of [DET-DNS].








  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 11]


  Internet-Draft                  det-tada                    October 2025


     uas-datum = {
       ? timestamp => utc,
       ? uas_type => 0..15,
       ? uas_ids => [
         + [
           id_type: 0..15,
           uas_id: uas-id
         ]
       ],
       ? ua_status => 0..15,
       ? ua_position => [
         lla: position,
         barometric_altitude: number / null
       ],
       ? ua_bearing => uint,
       ? ua_speed => [
         vertical: number / null,
         horizontal: number / null
       ],
       ? ua_height => [
         agl: bool,
         height: number
       ],
       ? accuracy => [
         vertical: 0..15,
         horizontal: 0..15,
         altitude: 0..15,
         barometric: 0..15,
         timestamp: 0..15
       ],
       ? auth => [
         + [
           auth_type: 0..15,
           data: auth-data
         ]
       ],
       ? self_id => [
         desc_type: 0..255,
         desc: tstr .size 23
       ],
       ? operator_position => position,
       ? classification => [
         region: 0..8,
         category: 0..15,
         class: 0..15
       ],
       ? area => [
         count: 1..255,



  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 12]


  Internet-Draft                  det-tada                    October 2025


         radius: number,
         floor: number,
         ceiling: number
       ],
       ? operator_id => [
         operator_type: 0..255,
         operator_id: tstr .size 20
       ],
       ? compliance => [+ uint]
     }

                         Figure 1: Common UAS RID CDDL

     The mapping between JSON keys (as strings) and CBOR keys (as unsigned
     integers) for Figure 1 are defined in Section 5.5.

        Author Note: do we specify the enumeration for compliance in this
        document?  Is it an IANA registry?

  4.2.  Registration

     This section defines the interaction model, data models and methods
     for registration of a DET into a DIME for global interoperability.
     Standardization of additional methods and data models to register to
     a DIME (DETs or otherwise) is out of scope for this document.

  4.2.1.  Disclaimer

     DRIP does NOT provide protection against incorrect (e.g. fraudulent)
     data entered during registration or asserted subsequently.  DRIP does
     protect against alteration (intentional or unintentional) of data
     subsequent to its assertion by the cryptographic signer.  The signer
     might be the proximate sender (e.g. UA transmitting Broadcast RID) or
     might be an attestor far away and long ago (e.g. root Certificate
     Authority).  It is the duty of the operator of each DIME, or the
     party on whose behalf the DIME is being operated, to validate the
     registration data.  The RAA (e.g. CAA) SHOULD provide services to
     obtain this goal, see Section 4.2.4.1.

  4.2.2.  Interaction Model

     Registration of DETs uses the interaction model shown in Figure 2.









  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 13]


  Internet-Draft                  det-tada                    October 2025


                       registrant             dime
                           |                   |
           (0) GEN_DET/HI  |                   |
           (1) GEN_CSR     |                   |
                           |----(2) INPUT----->|
                           |                   | (3) VALID_INPUT?
                           |<-------FAIL-------|
                           |                   | (4) DUPE_HI?
                           |<-------FAIL-------|
                           |                   | (5) DUPE_DET?
                           |<-------FAIL-------|
                           |                   | (6) GEN_CERTS
                           |                   | (7) UPDATE_DATABASE
                           |                   | (8) UPDATE_NS
                           |<----(9) OUTPUT----|

                Figure 2: Simplified DET Registration Z-Diagram

     (0) GEN_DET/HI:  The registrant that plans to use the identity and
        its cryptographic properties SHOULD generate the asymmetric key-
        pair of their choosing and MUST protect the private key with Best
        Current Practices.  The registrant MAY derive the corresponding
        DET.  How the registrant obtains the desired HID for DET
        generation is out of scope for this document.

     (1) GEN_CSR:  The registrant MUST generate a Certificate Signing
        Request (CSR) for their HI/DET.  See Appendix D.1 for more
        details.

     (2) INPUT:  The registrant MUST format and send the required
        information for a given service registration as specified by the
        DIME using Section 4.2.3.

     (3) VALID_INPUT?:  The DIME, upon receipt of service registration
        inputs, MUST validate the input data.  This may be simply
        performing syntax checks to ensure the data is properly formatted
        all the way to full semantic validation (see Section 4.2.4.1).
        Signed data MUST have their signatures verified before further
        processing.  Failure of input validation SHOULD returns errors to
        the registrant.

     (4) DUPE_HI?:  The DIME MUST check that the proposed HI is not a
        already in use within the specified HID scope.  The registrant
        SHOULD be notified with an error if duplication is detected.

     (5) DUPE_DET?:  The DIME MUST check that the proposed DET, derived





  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 14]


  Internet-Draft                  det-tada                    October 2025


        from the HI, is not a already in use within the specified HID
        scope.  If the registrant proposed a DET with HID outside that of
        the DIME, it MUST be rejected.  If the registrant only provided
        the HI, the DIME MUST generate the DET using the HID for which
        that DIME is authoritative.  The registrant SHOULD be notified
        with an error if duplication is detected.

     (6) GEN_CERTS:  The DIME, after all the above validation, MUST
        generate a Broadcast Endorsement using the provided HI and DET
        from the registrant as the evidence.  This Endorsement is used in
        [RFC9575].  The DIME MUST also generate a corresponding X.509
        certificate as per Section 4.2.5.1, confirming that the DIME has
        accepted the registrant's DET/HI pair for registration.  Other
        Certificates MAY be generated during registration but are out of
        scope for this document.

     (7) UPDATE_DATABASE:  The DIME MUST update the Private Information
        Registry with all registration data required by the jurisdiction
        or the DIME's own policy, typically including PII, all of which
        must be protected by AAA as per applicable regulation and policy.
        It MAY include additional metadata or public information.  How the
        Private Information Registry is updated is out of scope for this
        document.

     (8) UPDATE_NS:  The DIME MUST update the Authoritative Name Server
        with any public information that was part of the registration.
        This information MUST be stored as described in [DET-DNS].

     (9) OUTPUT:  The DIME, upon successful updates of the Private
        Information Registry and Authoritative Name Server, responds
        according to Section 4.2.3.

  4.2.3.  Interface & Encoding

     Registration request and response data MUST be encapsulated in a Web
     Token (either CWT [RFC8392] or JWT [RFC7519]).  For Session IDs and
     Authentication Key IDs the registrant usually is the Operator (or a
     proxy for the Operator such as the GCS) but MAY be the UA directly if
     the UA has a long term cryptographic identity.

     The method for a registrant to find a DIME is out of scope for this
     document.  DIMEs MUST use [RFC8615] to provide DRIP-related
     interfaces and perform redirects to the relevant URIs.  DIME
     registration endpoints MUST use POST expecting a Web Token from
     registrants.  During a request a registrant MUST encrypt the Web
     Token in accordance with PRIV-2 of Section 4.3.1 of [RFC9153] as
     during a request it typically includes PII.  An example is shown in
     Figure 3.



  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 15]


  Internet-Draft                  det-tada                    October 2025


        Author Note: /.well-known/ could be a single URI like register-
        hhit or more specific ones like uas-operator and uas-session.  Do
        we have a preference?

     POST /.well-known/register-hhit HTTP/1.1
     Host: uss.example.com
     Accept: application/drip+cwt, application/drip+jwt
     Content-Type: application/drip+cwt
     Content-Length: <CWT length>

     [ CWT from registrant ]

               Figure 3: Example REST Registration API (request)

     The DIME responds, upon successful registration, with their own Web
     Token contain the data model defined in Section 4.2.5.  The Web Token
     SHOULD be encrypted, if containing any PII.  An example is shown in
     Figure 4.

     HTTP/1.1 200 OK
     Accept: application/drip+cwt, application/drip+jwt
     Content-Type: application/drip+cwt

     [ CWT from DIME ]

               Figure 4: Example REST Registration API (response)

     This document allocates application/drip+cwt, application/drip+jwt
     and application/drip to the Media Types registry.  It also allocates
     register-hhit to the /.well-known/ registry.

  4.2.3.1.  Using CoAP for Registration

     Support of the Constrained Application Protocol (CoAP, [RFC7252]) is
     OPTIONAL.

     When using CoAP, DTLS SHOULD be used when possible and MUST send the
     data models (Section 4.2.4 and Section 4.2.5) encoded as CBOR.  When
     DTLS is not possible, and CoAP is instead used with UDP, model data
     MUST be encapsulated, signed and encrypted in a CWT as above.

  4.2.3.2.  Guidance on Registration Errors

     The following registration failure conditions and response are
     informative:

     *  Upon invalid input from the registrant, the DIME SHOULD respond
        with either 400 (Bad Request) or 403 (Forbidden) as appropriate.



  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 16]


  Internet-Draft                  det-tada                    October 2025


     *  Upon a duplicate HI or DET, the DIME SHOULD respond with 409
        (Conflict).

     *  Any other processing failure of registration by a DIME SHOULD be
        responded with an appropriate Server Error status code.

     Care should be given when responding with 403 (Forbidden) to not
     expose any information that could be used to socially engineer a fake
     request.  For example, when following Section 4.2.4.1, it would be
     unwise for the HDA to detail an exact reason for the rejection.  A
     malicious registrant could spam the endpoint, farming information on
     what UAS Serial Numbers, Operator IDs and their potential bindings
     exist to exploit.

     It should be noted that the above would be avoided with properly
     configured systems since signature validation and denial of service
     mitigations would be before the HDA even attempts to ascertain
     validation from the RAA.

  4.2.4.  Registration Model

     The data sent to the DIME for a given registration is policy driven.
     For example a Session ID registration SHOULD include a CAA specific
     identifier of the Operator to enable the private binding of the
     Session ID to both the Serial Number (found in the CSR, Appendix D.1)
     but also the Operator themselves.

     registration-content = {
       csr_list: [
         + csr: [
           idx: hash,
           entity_type: uint,
           csr: x509,
           vnb: utc / null,
           vna: utc / 1..15638400 / null,
           meta: { metadata }
         ]
       ],
       metadata
     }

                       Figure 5: Registration Model CDDL









  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 17]


  Internet-Draft                  det-tada                    October 2025


     The data model defined in Figure 5 is what is minimally required for
     a DIME to be functional.  Additional fields SHOULD be registered to
     IANA under Section 5.5 for global harmonization.  RAAs and HDAs MAY
     use their respective keys and their associated maps to define
     additional keys to be included in a registration.  A dedicated
     Private Use space is provided for RAAs and HDAs to define keys and
     their uses.

     The uas map item uses the data model found in Section 4.1 to carry
     any static information expected to also be found over Broadcast RID.
     It MUST NOT include in the uas_ids key the UAS Serial Number when a
     Session ID is being registered.  It also MUST NOT contain the
     operator_location key, as this information is usually considered PII
     and typically is dynamic or unknown at time of registration.  The
     DIME MUST fill in the auth key with any SAMs related to a
     registration and place the data model into DNS with Section 5.2 of
     [DET-DNS] when the registrant entity is required to use Broadcast RID
     and expecting to use [RFC9575].

     The registrant can select from a number of options to encode the
     values of valid not before (vnb) and valid not after (vna) for time
     of applicability of an individual CSR (csr-data).  The use of the
     time or tdate types allow for absolute time references.  The use of
     the uint type for vna specifies a positive offset in seconds from an
     absolute time.  When null is used the registrant is informing the
     DIME that for vnb the DIME MUST use the current time as vnb during
     registration and for vna the DIME MUST set vna to a time such that
     the default DIME policy for maximum delta between vnb and vna is not
     exceeded.

        Implementation Note: due to not differentiating between integers
        and floats in its number type, implementations using JSON as the
        encoded format MUST check the value of vna to determine if its
        being used as an offset or absolute time.

     As an example of the use of vnb and vna, a registrant may set
     vnb=null and vna=3600.  The DIME in this instance would use the
     current absolute time at receipt of the registration request for vnb
     and then apply the offset specified by vna to obtain an absolute time
     for vna that is 3600 seconds after vnb.  These absolute times of vnb
     and vna are then used in the certificate being created by the DIME to
     endorse the registration Section 4.2.5.1.









  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 18]


  Internet-Draft                  det-tada                    October 2025


  4.2.4.1.  Validating Fields

     In certain circumstances field contents may only be properly
     validated by other entities outside of DRIP.  For example the binding
     between UAS Serial Number and Operator ID should already be known by
     the CAA, as typically this information is required out of band of
     DRIP directly to the CAA in some form.  The CAA should provide or
     itself have access to an "oracle" that can validate these claimed
     bindings for registration to proceed.  If such an "oracle" is not
     consulted there is a risk that information being registered is
     fraudulent and DRIP has no method or authority to confirm the claims.
     If such information is accepted, future information queries by
     authorities can result in bogus data being returned, with no binding
     to an actual UAS or Operator.

     The CAA SHOULD, as part of its capacity as an RAA onboarding an HDA,
     provide data models, communication framework and any authentication
     mechanisms to query the oracle directly if the CAA allows HDAs to
     perform the queries themselves.  Otherwise the RAA MUST provide an
     HTTPS POST interface that consumes a Web Token generated by the HDA
     containing the registrant Web Token.  If the RAA is not configured or
     does not wish to handle such requests it MUST respond with 501 (Not
     Implemented), HDAs should proceed without validation as if validation
     was successful.

     If the RAA is configured to validate registration requests, it sends
     the data to the "oracle", via a mechanism out of scope for this
     document.  When the "oracle" marks data as invalid the RAA MUST
     signal to the HDA that the registration is to be denied.  Otherwise
     the RAA returns a Web Token to the HDA containing an X.509
     Certificate with the Subject set to the same contents as the
     registrant CSR.

  4.2.5.  Response Model

     response-content = [
       + [
         idx: hash,
         entity_type: uint,
         certs: {
           canonical_cert: x509,
           ? be_chain: [+ be: endorsement],
           * &(tstr , int) => any
         }
       ]
     ]

                         Figure 6: Response Model CDDL



  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 19]


  Internet-Draft                  det-tada                    October 2025


     The canonical_cert key MUST be the certificate defined in
     Section 4.2.5.1.  The be_chain contains the Broadcast Endorsement
     structures defined in Section 4.1 of [RFC9575] and MAY not be sent by
     the DIME if the registrant is not expected to use Broadcast RID.

     Additional items MAY be sent back to the registrant by the DIME.
     Their keys SHOULD be registered under IANA as part of Section 5.5 to
     support global harmonization.

  4.2.5.1.  Canonical Registration Certificate

     Appendix D provides profiles for X.509 certificates adhering to the
     [ICAO-ACCP], developed by the Trust Framework Panel.  At least one of
     the DRIP profiles MUST be used.

     At least one certificate in the chain from an apex node to a leaf
     node MUST contain a URI, as part of the Subject Alternative Name
     Extension [RFC5280], which points to the relevant Private Information
     Registry containing associated PII registered.  This certificate MUST
     be contained in the HHIT RRType defined in Section 5.1 of [DET-DNS].
     The certificate MAY be anywhere on the path and SHOULD be as close to
     the apex in the path as possible for efficiency.

     At the time of publication, the current best practice is for the HDA
     Issue certificate to contain the base URI to be used for all Private
     Information Registry requests under the HDA.  When an HDA supports
     multiple Private Information Registry providers, it SHOULD set the
     appropriate URI in the Operational certificate.  The HDA MAY either
     set all different URIs together in its HDA Issue certificate at cost
     of the querent being then required to perform queries at each
     provided URI until it receives a response or use different Issuer
     DETs for each different Private Information Registry provider.

     When registering a DET to be used as a Session ID, the CSR
     Appendix D.1 MUST contain the UAS Serial Number as the Subject, and
     the certificate placed in the private registry also MUST contain the
     UAS Serial Number as the Subject, but the certificate placed in the
     public registry and used as the basis of the Broadcast Endorsement
     (or otherwise exposed publicly) MUST NOT contain the UAS Serial
     Number.

  4.3.  Query

     A DIME has two query interfaces it MUST support.  One interface is
     used for public information and the other (discoverable from public
     information) is for private information.





  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 20]


  Internet-Draft                  det-tada                    October 2025


  4.3.1.  Public Information Registries

     The information found in these registries has been designated
     (explicitly or implicitly) as public by cognizant authority and/or
     the information owner.  Such information includes asymmetric
     cryptographic public keys needed for authentication in [RFC9575],
     static Broadcast RID data and trustworthy pointers to additional
     information.

     These registries are Authoritative Name Servers in the DNS.  See
     [DET-DNS] for operational requirements, query mechanism and response
     models.

  4.3.2.  Private Information Registries

     The information found in these registries is considered Personally
     Identifiable Information (PII) and/or is stored for potential future
     audit of registration.  Access to Private Information Registries MUST
     be performed using RDAP [STD95].  This section defines RDAP behavior
     for DRIP.

  4.3.2.1.  URI Path Segment

     The URIs to Private Information resources MUST use the specification
     defined in Section 3.1.1 of [RFC9082].  Use of Section 3.1.3 of
     [RFC9082] is OPTIONAL.

  4.3.2.2.  Conformance Literal

     The string literal drip_version_0 MUST be used in the rdapConformance
     section of the RDAP response to signal conformance with this
     specification.

  4.3.2.3.  Extension Model

     Queries of DETs in RDAP SHOULD respond with the appropriate Object
     Class as defined in RFC9083 and MUST include the additional data
     element specified in Figure 7.













  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 21]


  Internet-Draft                  det-tada                    October 2025


     dime = {
       csr: x509,
       canonical_cert: x509,
       hhit: [
         entity_type: uint,
         ipv6: ip6
       ],
       be_chain: [+ be: endorsement]
       registrant: tstr,
       ? raa_approval: x509,
       metadata
     }

                          Figure 7: RDAP Response CDDL

     Additional keys SHOULD be registered to IANA under Section 5.5 for
     global harmonization.  Specification of their usage and syntax in a
     NAS is provided by CAAs using a MOC that references this
     specification.

  4.3.2.4.  Differential Access

     Per REG-2 and REG-4 of Section 4.4.1 of [RFC9153], RDAP queries to
     DRIP Private Information Registries MUST be protected using fine-
     grained AAA policies in a both human- & machine-readable form for
     automated enforcement.  RDAP supports only HTTP based mechanisms for
     authentication as defined in Section 3.2 of [RFC7481].  A federated
     authentication mechanism, such as the examples in Section 3.2.1 of
     [RFC7481], is RECOMMENDED.

     For international and/or global harmonization, DRIP standardizes the
     following RDAP behavior for authentication of clients and servers:

     *  MUST support HTTP Digest Authentication Scheme ([RFC7616]) *AND*

     *  SHOULD NOT support HTTP Basic Authentication Scheme ([RFC7617])
        but MAY accept Basic if peer offers that and nothing stronger
        *AND*

     *  MUST support Mutual TLS Section 7.4.6 of [RFC5246] for global and/
        or international queries *AND*

     *  SHOULD use Mutual TLS Section 7.4.6 of [RFC5246] but MAY do any
        other RDAP compatible AAA for domestic queries

     A DIME when supporting Mutual TLS MUST accept valid DKIX certificates
     (Appendix D) and MAY accept other certificates.




  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 22]


  Internet-Draft                  det-tada                    October 2025


        Author Note: the selection of Mutual TLS is an initial down
        selection from OpenID Connect for RDAP ([RFC9560]), or Mutual TLS
        (Section 7.4.6 of [RFC5246]) or eXtensible Access Control Markup
        Language (XACML) with Security Assertion Markup Language (SAML).
        This is still a discussion point.

  5.  IANA Considerations

  5.1.  RAA Delegation for CAAs

     As part of [DET-DNS] IANA already has the pre-allocated mapping of
     RAA values for CAAs.  Nations are to follow the guidance in
     Section 6.2.1.4 of [DET-DNS] to request delegation of their DNS zone
     under 3.0.0.1.0.0.2.ip6.arpa..

  5.2.  Well-Known URIs

     IANA is requested to add the following entries in the "Well-Known
     URIs" registry [WELL-KNOWN].

     +===============+============+===========+===========+=============+
     | URI Suffix    | Change     | Reference | Status    | Related     |
     |               | Controller |           |           | Information |
     +===============+============+===========+===========+=============+
     | register-hhit | IETF       | This RFC  | permanent | N/A         |
     +---------------+------------+-----------+-----------+-------------+

                Table 1: Additions to Well-Known URIs Registry

  5.3.  RDAP Extensions Registry

     IANA is request to register the following value in the "RDAP
     Extensions" registry [RDAP-EXT].

     Extension Identifier:
       drip_version_0
     Registry Operator:
       Any
     Specification:
       This specification
     Contact:
       IETF <iesg@ietf.org>
     Intended Usage:
       This extension is used to convey private information
       under an HHIT registration.






  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 23]


  Internet-Draft                  det-tada                    October 2025


  5.4.  Media Types

     IANA is requested to add the following entries in the "Media Types"
     registry [MEDIA-TYPES].

              +==========+======================+===============+
              | Name     | Template             | Reference     |
              +==========+======================+===============+
              | DRIP CWT | application/drip+cwt | Section 5.4.1 |
              +----------+----------------------+---------------+
              | DRIP JWT | application/drip+jwt | Section 5.4.2 |
              +----------+----------------------+---------------+

                   Table 2: Additions to Media Types Registry

  5.4.1.  application/drip+cwt Registration

     Type name:  application

     Subtype name:  drip+cwt

     Required parameters:  N/A

     Optional parameters:  N/A

     Encoding considerations:  binary

     Security considerations:  TODO

     Interoperability considerations:  N/A

     Published specification:  This RFC

     Applications that use this media type:  Applications that access
        DIMEs requesting HHIT registration, as well as DIMEs responding to
        registration requests.

     Fragment identifier considerations:  N/A

     Person & email address to contact for further information:  DRIP WG
        mailing list (drip@ietf.org)

     Intended usage:  COMMON

     Restrictions on usage:  none

     Author/Change controller:  IETF




  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 24]


  Internet-Draft                  det-tada                    October 2025


     Provisional registration:  no

  5.4.2.  application/drip+jwt Registration

     Type name:  application

     Subtype name:  drip+jwt

     Required parameters:  N/A

     Optional parameters:  N/A

     Encoding considerations:  binary, JWT values are encoded as a series
        of base64url-encoded values (with trailing '=' characters
        removed), some of which may be the empty string, separated by
        period ('.') characters.

     Security considerations:  TODO

     Interoperability considerations:  N/A

     Published specification:  This RFC

     Applications that use this media type:  Applications that access
        DIMEs requesting HHIT registration, as well as DIMEs responding to
        registration requests.

     Fragment identifier considerations:  N/A

     Person & email address to contact for further information:  DRIP WG
        mailing list (drip@ietf.org)

     Intended usage:  COMMON

     Restrictions on usage:  none

     Author/Change controller:  IETF

     Provisional registration:  no

  5.5.  DRIP CBOR/JSON Keys

     This specification establishes a new sub-registry called "DRIP CBOR/
     JSON Keys" within the "Drone Remote ID Protocol" registry.  This
     registry is to maintain a globally harmonized list of JSON keys (i.e.
     "Names") and CBOR map integer keys (i.e. "Labels") for use in DRIP.
     The following ranges are defined based on the CBOR Label values:




  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 25]


  Internet-Draft                  det-tada                    October 2025


       +========+===============+===============+=====================+
       | Range  | Registration  | Range Use     | Comments            |
       |        | Policy        |               |                     |
       +========+===============+===============+=====================+
       | from   | Private Use   | HID Private   | Private use for     |
       | -2^64  | (Section 4.1  | Keys          | RAAs and HDAs       |
       | to -25 | of [RFC8126]) |               |                     |
       +--------+---------------+---------------+---------------------+
       | from   | TODO: TBD     | ASTM UAS Keys | Keys found in ASTM  |
       | -24 to |               |               | UAS Standards such  |
       | 23     |               |               | as [F3411]          |
       +--------+---------------+---------------+---------------------+
       | from   | Specification | Global        | Reserved for future |
       | 24 to  | Required      | Harmonization | registrations to    |
       | 2^64-1 | (Section 4.6  |               | maintain global     |
       |        | of [RFC8126]) |               | harmonization       |
       +--------+---------------+---------------+---------------------+

                Table 3: DRIP CBOR/JSON Key Registry Policies

     Keys in the Private Use and Experimental ranges are RECOMMENDED to
     prepend a _ to the Name to avoid namespace collisions with registered
     Names.

     The HID Private Keys range in this registry provide code-points (used
     in Section 4.2.4 and Section 4.3.2.3 as part of metadata) for each
     RAA and HDA to define their own subset of elements in both
     registration and RDAP responses.  The spec value of this registry
     SHOULD be used to enable the DIME or client to provide a "hint" for
     the data elements included.  Specification of the spec string
     semantics are left to individual RAAs and HDAs to define as they see
     fit.  RAA and HDA Operators SHOULD provide specification for any
     Private Use or Experimental Use values, but this may not be public
     due to policy.

  5.5.1.  Review Criteria

     For registrations, review should note if the Name field matches an
     existing entry, the request should be denied.  A request should also
     be denied if the specification duplicates an existing entry both in
     syntax and semantics.  For example, if an existing key called whee
     already exists with the specification of [+ uint] and a new request
     comes along to register whee_but_mine with specification [+ uint],
     then the latter should be rejected on the grounds of being able to
     use whee instead.  This denial can be overruled if shown that the new
     registration has clear justification, as part of the specification
     citing technical reasoning, to exist.




  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 26]


  Internet-Draft                  det-tada                    October 2025


  5.5.2.  CBOR/JSON Key Fields

     Name (JSON Key Value):  A string value, to be used as a key in the
        key: value pair of a JSON object.  No specific rules apply for
        syntax beyond being a valid JSON string for a object key, but it
        is recommended to use all lower-case and snake-case with
        underscores.  Care should be given to the length of a Name to
        reduce wire size of JSON encodings for constrained environments.

     Label (CBOR Integer Key Value):  A integer value, ranging from -2^64
        to 2^64 - 1, to be used as a key in a CBOR map.  Different ranges
        of values use different registration policies, see Table 3.

     Description:  A short description of the entry providing an overview
        of its semantic meaning and its expected use-cases.

     Reference:  A link to a permanent and readily available specification
        defining the value syntax and semantics to be used for this key.

  5.5.3.  Registration Form

     Requested Range:
     Name (JSON Key Value):
     Description:
     Specification:

                                    Figure 8

  5.5.4.  Initial Values

       +===================+=============+=================+===========+
       | Name (JSON Key    | Label (CBOR | Description     | Reference |
       | Value)            | Integer Key |                 |           |
       |                   | Value)      |                 |           |
       +===================+=============+=================+===========+
       | uas_type          | 0           | Enumeration of  | This RFC, |
       |                   |             | UAS Type        | Section   |
       |                   |             |                 | 4.1       |
       +-------------------+-------------+-----------------+-----------+
       | uas_ids           | 1           | UAS IDs         | This RFC, |
       |                   |             |                 | Section   |
       |                   |             |                 | 4.1       |
       +-------------------+-------------+-----------------+-----------+
       | auth              | 2           | Authentication  | This RFC, |
       |                   |             | Data            | Section   |
       |                   |             |                 | 4.1       |
       +-------------------+-------------+-----------------+-----------+
       | self_id           | 3           | Self ID         | This RFC, |



  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 27]


  Internet-Draft                  det-tada                    October 2025


       |                   |             |                 | Section   |
       |                   |             |                 | 4.1       |
       +-------------------+-------------+-----------------+-----------+
       | classification    | 4           | UA Category &   | This RFC, |
       |                   |             | Class           | Section   |
       |                   |             |                 | 4.1       |
       +-------------------+-------------+-----------------+-----------+
       | area              | 5           | Area Count,     | This RFC, |
       |                   |             | Radius, etc.    | Section   |
       |                   |             |                 | 4.1       |
       +-------------------+-------------+-----------------+-----------+
       | operator_id       | 6           | Operator ID     | This RFC, |
       |                   |             |                 | Section   |
       |                   |             |                 | 4.1       |
       +-------------------+-------------+-----------------+-----------+
       | ua_status         | 7           | Enumeration of  | This RFC, |
       |                   |             | Status          | Section   |
       |                   |             |                 | 4.1       |
       +-------------------+-------------+-----------------+-----------+
       | ua_position       | 8           | UA Position     | This RFC, |
       |                   |             |                 | Section   |
       |                   |             |                 | 4.1       |
       +-------------------+-------------+-----------------+-----------+
       | ua_bearing        | 9           | Bearing / Track | This RFC, |
       |                   |             | Direction       | Section   |
       |                   |             |                 | 4.1       |
       +-------------------+-------------+-----------------+-----------+
       | ua_speed          | 10          | Vertical &      | This RFC, |
       |                   |             | Horizontal      | Section   |
       |                   |             | Speeds          | 4.1       |
       +-------------------+-------------+-----------------+-----------+
       | ua_height         | 11          | Height Above    | This RFC, |
       |                   |             | Ground or Take- | Section   |
       |                   |             | off             | 4.1       |
       +-------------------+-------------+-----------------+-----------+
       | accuracy          | 12          | Enumerations of | This RFC, |
       |                   |             | Accuracies      | Section   |
       |                   |             |                 | 4.1       |
       +-------------------+-------------+-----------------+-----------+
       | operator_position | 13          | Operator        | This RFC, |
       |                   |             | Position        | Section   |
       |                   |             |                 | 4.1       |
       +-------------------+-------------+-----------------+-----------+
       | timestamp         | 14          | UTC Timestamp   | This RFC, |
       |                   |             |                 | Section   |
       |                   |             |                 | 4.1       |
       +-------------------+-------------+-----------------+-----------+
       | compliance        | 15          | Compliance      | This RFC, |



  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 28]


  Internet-Draft                  det-tada                    October 2025


       |                   |             | Enumeration     | Section   |
       |                   |             |                 | 4.1       |
       +-------------------+-------------+-----------------+-----------+
       | raa               | 23          | RAA             | This RFC  |
       +-------------------+-------------+-----------------+-----------+
       | hda               | 24          | HDA             | This RFC  |
       +-------------------+-------------+-----------------+-----------+
       | csr               | 25          | DER Encoded     | This RFC  |
       |                   |             | X.509 CSR       |           |
       +-------------------+-------------+-----------------+-----------+
       | uas               | 26          | UAS Datum Map   | This RFC, |
       |                   |             |                 | Section   |
       |                   |             |                 | 4.1       |
       +-------------------+-------------+-----------------+-----------+
       | utm               | 27          | UTM Operational | This RFC  |
       |                   |             | Intent & Source |           |
       +-------------------+-------------+-----------------+-----------+
       | spec              | 28          | CAA             | This RFC  |
       |                   |             | Specification   |           |
       |                   |             | Code            |           |
       +-------------------+-------------+-----------------+-----------+
       | canonical_cert    | 39          | DER Encoded     | This RFC  |
       |                   |             | X.509           |           |
       |                   |             | Certificate     |           |
       +-------------------+-------------+-----------------+-----------+
       | be_chain          | 30          | List of         | This RFC  |
       |                   |             | Broadcast       |           |
       |                   |             | Endorsements    |           |
       +-------------------+-------------+-----------------+-----------+
       | registrant        | 31          | Registrant      | This RFC  |
       |                   |             | Information     |           |
       +-------------------+-------------+-----------------+-----------+
       | hhit              | 32          | Hierarchial     | This RFC  |
       |                   |             | Host Identity   |           |
       |                   |             | Tag             |           |
       +-------------------+-------------+-----------------+-----------+
       | oracle_x509       | 33          | Oracle X.509    | This RFC  |
       |                   |             | Certificate     |           |
       +-------------------+-------------+-----------------+-----------+
       | uas_serial_number | 34          | ANSI/CTA 2063-A | This RFC  |
       |                   |             | UAS Serial      |           |
       |                   |             | Number          |           |
       +-------------------+-------------+-----------------+-----------+
       | caa_assigned_id   | 35          | CAA Assigned ID | This RFC  |
       +-------------------+-------------+-----------------+-----------+
       | pilot_license_id  | 36          | Pilot License   | This RFC  |
       |                   |             | Number          |           |
       +-------------------+-------------+-----------------+-----------+



  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 29]


  Internet-Draft                  det-tada                    October 2025


                   Table 4: Pre-Allocated DRIP CBOR/JSON Keys

  6.  Security Considerations

     The considerations discussed in [RFC9153], [RFC9374], [RFC9434],
     [RFC9575] and [DET-DNS] apply.

     DIMEs use and provide various methods to protect data through:
     Attestation, Authentication, Authorization, Access Control,
     Attribution, Accounting, and Audit (AAA).  All data, handled under
     DRIP, MUST be protected by AAA, as per applicable regulation and
     policy (which, in some cases, for public data, may impose minimal
     requirements).  All private data MUST also be protected by strong
     encryption where permitted by applicable law etc.  These requirements
     apply to data at rest and in transit in all phases of the process,
     i.e. registration and query.

     Attestation may be mandated by CAAs for devices (such as UA).  Remote
     ATtestation ProcedureS (RATS) [RFC9334] is recommended for DRIP.  The
     specific attestation mechanisms in a given jurisdiction are out of
     scope for this document.

        Author Note: RGM, what else should go here?

  6.1.  Cryptographic Materials

     Best practices dictate that cryptographic materials that should only
     be available to selected parties SHOULD be generated by one or more
     of those parties and stored accessibly only on those parties devices.
     E.g. the asymmetric key-pair from which a DET will be derived SHOULD
     be generated by the entity identified by that DET and the
     corresponding private key should be stored only on that entity's
     device.  There may be scenarios where other parts of the UAS MAY
     generate the cryptographic materials and provision them as needed
     during an operation.  Any such system MUST ensure security of the
     cryptographic material is guaranteed.

  7.  Privacy & Transparency Considerations

     The considerations discussed in [RFC9153] and Section 10 of [RFC9434]
     apply.

        Author Note: do we copy/paste Section 10 of [RFC9434] and update
        here or is below sufficient?







  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 30]


  Internet-Draft                  det-tada                    October 2025


  7.1.  DETs as Session ID and Authentication Key ID

     The properties of a DET allow it to be used as a Session ID and/or an
     Authentication Key ID.  There may be scenarios in which Session IDs
     are desired for privacy but Authentication is not; although this may
     reduce transparency and security, a DET MAY be used exclusively as a
     Session ID in such.  There are scenarios in which Authentication is
     desired but Session IDs are not (e.g. where a CAA does not allow
     Session IDs); a DET MAY be used exclusively as an Authentication Key
     ID in such.  In the scenario expected to be most common, both Session
     IDs and Authentication are desired; the same DET SHOULD be used as
     both the Session ID and Authentication Key ID in such.  Consequences
     and operational impact of using different DETs for the Session ID and
     Authentication Key ID of the same entity are unknown and not covered
     in this document.

  7.2.  Selective Encryption

        Author Note: renamed section and/or add more explicit disclaimer?

     Selective encryption may be allowed in some circumstances.  An HHIT
     may be used in a private lookup to access decryption key material or
     obtain decryption as a service.

     Selective encryption of UAS RID using DRIP is only allowed when the
     DET to be used as the Session ID is issued by an HDA associated with
     a USS and that DET is associated with the corresponding Operational
     Intent in UTM.  This enables the encryption of selected data elements
     in Broadcast RID to provide a layer of privacy for operators (e.g.
     their position) without compromising transparency to entities (e.g.
     public safety / law enforcement personnel) that need to know.

     Selective encryption typically requires network connectivity of the
     Observer to perform the private query to obtain the decryption
     service or key material.  CAAs should consider the expected Observer
     environment and prohibit encryption wherever and whenever Observers
     cannot reasonably be expected to have connectivity.  For example
     selective encryption, per CAA regulations, MAY be allowed in dense
     wireless IP connectivity areas (e.g. urban) but prohibited in poor
     wirelessly covered areas (e.g. rural).

     The issue of Observer network connectivity MAY be mitigated with the
     use of a shared decryption key used by multiple Session IDs under a
     given USS/HDA over a period of time, that is preloaded onto the
     Observer device before connectivity is lost.  For example Observers
     MAY query USS/HDAs for flight volumes in which they are interested to
     preload their decryption key(s) for the Operational Intents/Session
     IDs that day.



  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 31]


  Internet-Draft                  det-tada                    October 2025


  8.  References

  8.1.  Normative References

     [DET-DNS]  Wiethuechter, A. and J. Reid, "DRIP Entity Tags in the
                Domain Name System", Work in Progress, Internet-Draft,
                draft-ietf-drip-registries-33, 19 August 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-drip-
                registries-33>.

     [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/rfc/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/rfc/rfc8174>.

     [RFC9153]  Card, S., Ed., Wiethuechter, A., Moskowitz, R., and A.
                Gurtov, "Drone Remote Identification Protocol (DRIP)
                Requirements and Terminology", RFC 9153,
                DOI 10.17487/RFC9153, February 2022,
                <https://www.rfc-editor.org/rfc/rfc9153>.

     [RFC9374]  Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov,
                "DRIP Entity Tag (DET) for Unmanned Aircraft System Remote
                ID (UAS RID)", RFC 9374, DOI 10.17487/RFC9374, March 2023,
                <https://www.rfc-editor.org/rfc/rfc9374>.

     [RFC9434]  Card, S., Wiethuechter, A., Moskowitz, R., Zhao, S., Ed.,
                and A. Gurtov, "Drone Remote Identification Protocol
                (DRIP) Architecture", RFC 9434, DOI 10.17487/RFC9434, July
                2023, <https://www.rfc-editor.org/rfc/rfc9434>.

     [RFC9575]  Wiethuechter, A., Ed., Card, S., and R. Moskowitz, "DRIP
                Entity Tag (DET) Authentication Formats and Protocols for
                Broadcast Remote Identification (RID)", RFC 9575,
                DOI 10.17487/RFC9575, June 2024,
                <https://www.rfc-editor.org/rfc/rfc9575>.

     [STD95]    Internet Standard 95,
                <https://www.rfc-editor.org/info/std95>.
                At the time of writing, this STD comprises the following:







  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 32]


  Internet-Draft                  det-tada                    October 2025


                Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
                Registration Data Access Protocol (RDAP)", STD 95,
                RFC 7480, DOI 10.17487/RFC7480, March 2015,
                <https://www.rfc-editor.org/info/rfc7480>.

                Hollenbeck, S. and N. Kong, "Security Services for the
                Registration Data Access Protocol (RDAP)", STD 95,
                RFC 7481, DOI 10.17487/RFC7481, March 2015,
                <https://www.rfc-editor.org/info/rfc7481>.

                Hollenbeck, S. and A. Newton, "Registration Data Access
                Protocol (RDAP) Query Format", STD 95, RFC 9082,
                DOI 10.17487/RFC9082, June 2021,
                <https://www.rfc-editor.org/info/rfc9082>.

                Hollenbeck, S. and A. Newton, "JSON Responses for the
                Registration Data Access Protocol (RDAP)", STD 95,
                RFC 9083, DOI 10.17487/RFC9083, June 2021,
                <https://www.rfc-editor.org/info/rfc9083>.

                Blanchet, M., "Finding the Authoritative Registration Data
                Access Protocol (RDAP) Service", STD 95, RFC 9224,
                DOI 10.17487/RFC9224, March 2022,
                <https://www.rfc-editor.org/info/rfc9224>.

  8.2.  Informative References

     [F3411]    ASTM International, "Standard Specification for Remote ID
                and Tracking", ASTM F3411-22A, DOI 10.1520/F3411-22A, July
                2022, <https://www.astm.org/f3411-22a.html>.

     [F3548]    ASTM International, "Standard Specification for UAS
                Traffic Management (UTM) UAS Service Supplier (USS)
                Interoperability", ASTM F3548-21, DOI 10.1520/F3548-21,
                July 2025, <https://www.astm.org/f3548-21.html>.

     [F3586]    ASTM International, "Standard Practice for Remote ID Means
                of Compliance to Federal Aviation Administration
                Regulation 14 CFR Part 89", ASTM F3586-22,
                DOI 10.1520/F3586-22, July 2022,
                <https://www.astm.org/f3411-22a.html>.

     [ICAO-ACCP]
                International Civil Aviation Organization, "ICAO Aviation
                Common Certificate Policy", July 2025.






  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 33]


  Internet-Draft                  det-tada                    October 2025


     [ICAO-NUMBERS]
                International Civil Aviation Organization, "ICAO Remote ID
                Number Registry", July 2025,
                <https://www.icao.int/airnavigation/IATF/Pages/ASTM-
                Remote-ID.aspx>.

     [MEDIA-TYPES]
                IANA, "Media Types", July 2025,
                <https://www.iana.org/assignments/media-types/>.

     [RDAP-EXT] IANA, "RDAP Extensions", July 2025,
                <https://www.iana.org/assignments/rdap-extensions/>.

     [RFC4108]  Housley, R., "Using Cryptographic Message Syntax (CMS) to
                Protect Firmware Packages", RFC 4108,
                DOI 10.17487/RFC4108, August 2005,
                <https://www.rfc-editor.org/rfc/rfc4108>.

     [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
                (TLS) Protocol Version 1.2", RFC 5246,
                DOI 10.17487/RFC5246, August 2008,
                <https://www.rfc-editor.org/rfc/rfc5246>.

     [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
                Housley, R., and W. Polk, "Internet X.509 Public Key
                Infrastructure Certificate and Certificate Revocation List
                (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
                <https://www.rfc-editor.org/rfc/rfc5280>.

     [RFC5952]  Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
                Address Text Representation", RFC 5952,
                DOI 10.17487/RFC5952, August 2010,
                <https://www.rfc-editor.org/rfc/rfc5952>.

     [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
                Application Protocol (CoAP)", RFC 7252,
                DOI 10.17487/RFC7252, June 2014,
                <https://www.rfc-editor.org/rfc/rfc7252>.

     [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/rfc/rfc7519>.

     [RFC7616]  Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP
                Digest Access Authentication", RFC 7616,
                DOI 10.17487/RFC7616, September 2015,
                <https://www.rfc-editor.org/rfc/rfc7616>.




  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 34]


  Internet-Draft                  det-tada                    October 2025


     [RFC7617]  Reschke, J., "The 'Basic' HTTP Authentication Scheme",
                RFC 7617, DOI 10.17487/RFC7617, September 2015,
                <https://www.rfc-editor.org/rfc/rfc7617>.

     [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
                Writing an IANA Considerations Section in RFCs", BCP 26,
                RFC 8126, DOI 10.17487/RFC8126, June 2017,
                <https://www.rfc-editor.org/rfc/rfc8126>.

     [RFC8392]  Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
                "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
                May 2018, <https://www.rfc-editor.org/rfc/rfc8392>.

     [RFC8610]  Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
                Definition Language (CDDL): A Notational Convention to
                Express Concise Binary Object Representation (CBOR) and
                JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
                June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.

     [RFC8615]  Nottingham, M., "Well-Known Uniform Resource Identifiers
                (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
                <https://www.rfc-editor.org/rfc/rfc8615>.

     [RFC9063]  Moskowitz, R., Ed. and M. Komu, "Host Identity Protocol
                Architecture", RFC 9063, DOI 10.17487/RFC9063, July 2021,
                <https://www.rfc-editor.org/rfc/rfc9063>.

     [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/rfc/rfc9334>.

     [RFC9560]  Hollenbeck, S., "Federated Authentication for the
                Registration Data Access Protocol (RDAP) Using OpenID
                Connect", RFC 9560, DOI 10.17487/RFC9560, April 2024,
                <https://www.rfc-editor.org/rfc/rfc9560>.

     [STD90]    Internet Standard 90,
                <https://www.rfc-editor.org/info/std90>.
                At the time of writing, this STD comprises the following:

                Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
                Interchange Format", STD 90, RFC 8259,
                DOI 10.17487/RFC8259, December 2017,
                <https://www.rfc-editor.org/info/rfc8259>.

     [STD94]    Internet Standard 94,
                <https://www.rfc-editor.org/info/std94>.



  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 35]


  Internet-Draft                  det-tada                    October 2025


                At the time of writing, this STD comprises the following:

                Bormann, C. and P. Hoffman, "Concise Binary Object
                Representation (CBOR)", STD 94, RFC 8949,
                DOI 10.17487/RFC8949, December 2020,
                <https://www.rfc-editor.org/info/rfc8949>.

     [WELL-KNOWN]
                IANA, "Well-Known URIs", July 2025,
                <https://www.iana.org/assignments/well-known-uris/>.

     [_802.1AR] IEEE, "IEEE Standard for Local and Metropolitan Area
                Networks - Secure Device Identity",
                DOI 10.1109/ieeestd.2018.8423794, July 2025,
                <https://doi.org/10.1109/ieeestd.2018.8423794>.

  Appendix A.  DRIP CDDL Prelude

     This appendix is normative.

     ; DRIP Type Definitions
     ; (follow STD94 Section 6 for CBOR/JSON conversion)
     metadata = (
       ? uas: uas-datum,
       ? utm: [
         operational_intent: uuid,
         uss_uri: uri
       ],
       ? raa: {
         ? spec: tstr,
         + &(tstr, int): any
       },
       ? hda: {
         ? spec: tstr,
         + &(tstr, int): any
       }
       * &(tstr, int): any
     )
     x509 = bstr ; DER encoded X.509 object (CSR or Certificate)
     endorsement = bstr .size 136
     hash = bstr .size 8 ; generated with cSHAKE
     auth-data = bstr .size 1..362
     uas-id = bstr .size 20
     utc = tdate / time

     ; DRIP Keys (JSON key = CBOR label)
     ; private_use = -2^64 .. -25
     ; astm = -24 .. 23



  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 36]


  Internet-Draft                  det-tada                    October 2025


     uas_type = 0
     uas_ids = 1
     auth = 2
     self_id = 3
     area = 4
     classification = 5
     operator_id = 6
     ua_status = 7
     ua_position = 8
     ua_bearing = 9
     ua_speed = 10
     ua_height = 11
     accuracy = 12
     operator_position = 13
     timestamp = 14
     compliance = 15
     raa = 23
     hda = 24
     csr = 25
     uas = 26
     utm = 27
     spec = 28
     canonical_cert = 29
     be_chain = 30
     registrant = 31 ; jcard or pointer (i.e. hhit of operator)?
     hhit = 32
     oracle_x509 = 33
     uas_serial_number = 34
     caa_assigned_id = 35
     pilot_license_id = 36

     ; External Tags
     uuid = #6.37
     ip6 = #6.54
     position = #6.103([
             latitude: number,
             longitude: number,
             altitude: number
     ])

  Appendix B.  HID Abbreviation

     The DET MAY be abbreviated.  This is useful for display applications
     with limited screen real-estate as the display of the entire 128-bit
     (32 characters in hexadecimal, even without recommended punctuation
     or spacing) IPv6 address can be costly.  Abbreviations SHOULD follow
     the following format rules.




  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 37]


  Internet-Draft                  det-tada                    October 2025


     Hierarchy Level:  Each hierarchy level (RAA/HDA) is represented by a
        maximum of six alphanumeric characters.  This abbreviation SHOULD
        NOT be a single character in length, for obvious reasons of not
        being very useful.  The decimal representation does fit into the 4
        character restriction but is NOT RECOMMENDED.  The RECOMMENDED
        abbreviation for the RAA level is to use the ISO3166-1 Alpha 2
        code for nations.  This abbreviation MAY be found in DNS under a
        HHIT RRType of the entity or its parents.  If there is no
        abbreviation hint display devices SHOULD use a fixed size four
        character hexadecimal representation of the value.  It is
        RECOMMENDED that display applications specify a default RAA value,
        and only display the RAA abbreviation explicitly when it does not
        match the default.

     Entity Hash:  The entity is represented by a fixed size four
        character hexadecimal string using the last four characters of the
        DET.  If a collision (within the same HID space) on display
        occurs, the four characters SHOULD shift to the left by one
        hexadecimal character until the collision is resolved.  This
        window MUST stay within the last sixteen hexadecimal characters of
        the DET.  The : character found in an IPv6 address string is
        ignored.

        Review(SWC): Do we need to insert a flag character such as "*" to
        indicate when a hash has been shifted?  If the abbreviation is
        used only to avoid conflicts, no; but if anyone actually knows
        some DETs in their operation, if they get shifted, they probably
        won't recognize them.

     Delimiter:  Each section is delimited by a single character.  This
        can be any whitespace character (except newline and tab) or any
        non-alphanumeric character (period, comma, semicolon, etc.).  It
        is RECOMMENDED that the delimiter is consistent between
        components.  The RECOMMENDED delimiter is the colon (:) character.

     For example a DET with the values of RAA 16383 and HDA 1 without any
     abbreviation hint from DNS is represented by the string 3FFF 0001
     xxxx with xxxx representing a entity hash.  If an abbreviation for
     the RAA (such as DRIP01) and HDA (such as TEST) are found in DNS then
     the DET can be represented with the string of DRIP01 TEST xxxx.

     For an example of the entity hash, let's assume there are two DETs
     with the following hashes in the same HID: 0000:1111:2222:3333 and
     0000:2222:1111:3333.  At first both DETs are represented with the
     same abbreviation: RAA HDA 3333.  One of these DETs is selected by
     the display application to shift the display hash one character to
     avoid the collision resulting in the following two abbreviations: RAA
     HDA 3333 and RAA HDA 1333.



  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 38]


  Internet-Draft                  det-tada                    October 2025


  Appendix C.  Compliance Testing

     It is the responsibility of each parent node in the tree that a child
     node pass functional interoperability testing prior to issuing a
     certificate for the child node.

        Author: This section is a work in progress.

     All interfaces MUST be tested on valid and invalid data (such as
     being malformed).  When policy is required on an interface all
     essential permutations of the policy MUST be tested and all possible
     permutations SHOULD be tested.  The policy engine MUST be invoked to
     validate proper decisions (including PERMIT and DENY or their
     equivalents) and actions are being made.  All data returned from an
     interface MUST be tested to check that it conforms with
     specifications.

     There is a range in the RAA space allocated for experimentation and
     testing purposes.  Sub-ranges can be delegated to parties, for a
     limited period of time, at the behest of the RAA Designated Expert,
     to test DIME interoperability (e.g. HDA to RAA, and RAA to RAA
     interactions) in any of the below subsections.  The IANA
     Considerations section of [DET-DNS] contains more information on how
     these delegations are to be handled.

     Appendix C.4 provides a set of forms to be filled out and submitted
     as part of a CAA compliance process for using DRIP.

     +-----+           +-----+
     |     |           |     |
     |     o----(1)--->o     |
     |  X  |           |  Y  |
     |     o<---(2)----o     |
     |     |           |     |
     +-----+           +-----+

                    Figure 9: System Interface Test Diagram

  C.1.  Registration Interface

     X, Y pairs: (registrant, HDA), (HDA, RAA)

     1: Ensure that endpoints on Y can be accessed according to Y's policy
     by X.  Ensure that the endpoints conform to the normative
     requirements of Test that Y interface properly handles valid and
     malformed data.  Test that Y securely generates proper artifacts and
     stores them.




  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 39]


  Internet-Draft                  det-tada                    October 2025


     2: Ensure that the interactions for (1) properly returns data to X
     from Y.  This data MUST include the Broadcast Endorsements, X.509s
     and any other data elements required.

  C.2.  Public Query Interface

     X, Y pairs: (UAS Observer, HDA), (UAS Observer, RAA), (HDA, RAA),
     (RAA, HDA), (HDA, HDA'), (RAA, RAA')

     1: Ensure that Y has a properly configured and publicly accessible
     Authoritative Name Server for its delegated ip6.arpa domain.

     2: Ensure that Y returns the valid RRTypes defined in [DET-DNS] to X
     based on an ip6.arpa query via standard DNS methods (i.e. using UDP
     on port 53).  Ensure that the HHIT RRType contains the correct
     Certificate with an URI.

  C.3.  Private Query Interface

     X, Y pairs: (UAS Observer, HDA), (UAS Observer, RAA), (HDA, RAA),
     (RAA, HDA), (HDA, HDA'), (RAA, RAA')

     1: Ensure that the provide URI from the public query interface points
     to a valid URI.  Ensure that the endpoint on Y has proper AAA
     mechanisms as defined in this document and enforces the proper policy
     options.

     2: Ensure that the Y endpoint securely returns the data expected
     according to policy (matrix of authorized, valid request,
     unauthorized and invalid request) to X.

  C.4.  Compliance Submission Forms

     Author Note: talk with AS on this section

  Appendix D.  DRIP Key Infrastructure X.509 (DKIX)

     This appendix is normative.

     The following sections define profiles and any specific field content
     for X.509 certificates that serve as a "shadow" of Endorsements that
     make up the DRIP Key Infrastructure (DKI).  It is recommended that
     DKIX-Full (Appendix D.3) be deployed, as its CA certificates contain
     ICAO policy OIDs the reflect on the whole DKIX deployment.







  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 40]


  Internet-Draft                  det-tada                    October 2025


     A DKIX compliant Certificate Authority (CA) MUST implement generation
     of the DKI Endorsements.  It SHOULD also generate both DKIX profiles
     (Appendix D.2 and Appendix D.3).  In this section Endorsing Server
     and CA are interchangeable.

        Author Note: At this point in defining the shadow PKIs,
        alternatives to a strict hierarchy is still an open work item.

  D.1.  Signing Request

     The Certificate Signing Request (CSR) is a mandatory for all DET
     registrations.  Depending on the entity being registered, there is
     specific content rules.

     Certificate Request:
         Data:
             Version: 1 (0x0)
             Subject:
             Subject Public Key Info:
                 Public Key Algorithm: ED25519
                     ED25519 Public-Key:
                     pub:
             Attributes:
             Requested Extensions:
                 X509v3 Subject Alternative Name: critical
                     IP Address:
         Signature Algorithm: ED25519

     Subject:  As defined in Section 4.1.2.6 of [RFC5280].  This field is
        filled in based on the type of entity being registered.  When the
        attribute type is set to SERIAL_NUMBER, it MUST contain the ANSI/
        CTA 2063-A UAS Serial Number encoded as a string.  The value of
        this field for other entity types are subject to policy and are
        out of scope for this document.

     Subject Alternative Name:  When the registrant knows which HID and/or
        Suite ID they want the CSR SHOULD contain the Subject Alternate
        Name extension as defined in Section 4.2.1.6 of [RFC5280] using
        ipAddress containing the fully formed DET and MUST mark the
        extension as critical.  This DIME MUST check to ensure that the
        DET located in the extension is properly generated with the
        included public key of this CSR.  If the registrant does not know
        or care the value of their HID and/or Suite ID, the Extensions
        field MUST NOT appear and the DIME will use its HID for DET
        generation using the public key provided by this CSR.

     The use of other Extension fields are out of scope for this document.




  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 41]


  Internet-Draft                  det-tada                    October 2025


  D.2.  Lite Profile

     DKIX-Lite is designed to fully mirror the DKI in the smallest
     reasonable X.509 certificates (e.g. 240 bytes for DER), but still
     adhere to [RFC5280] MUST field usage.  The profile can be found in
     Figure 10 and a field matrix found in Table 5.

     Certificate:
         Data:
             Version: 3 (0x2)
             Serial Number:
             Signature Algorithm: ED25519
             Issuer: CN =
             Validity
                 Not Before:
                 Not After :
             Subject:
             Subject Public Key Info:
                 Public Key Algorithm: ED25519
                     ED25519 Public-Key:
                     pub:
             X509v3 extensions:
                 X509v3 Subject Alternative Name: critical
                     IP Address:
         Signature Algorithm: ED25519
         Signature Value:

                          Figure 10: DKIX-Lite Profile























  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 42]


  Internet-Draft                  det-tada                    October 2025


     +================+===============+=========+=============+==========+
     | Field          | Authorization | Issuing | Operational | Comments |
     +================+===============+=========+=============+==========+
     | Serial         | MUST          | MUST    | MUST        | Appendix |
     | Number         |               |         |             | D.4.1.1  |
     +----------------+---------------+---------+-------------+----------+
     | Subject        | MUST          | MUST    | MUST NOT    | Appendix |
     |                |               |         |             | D.4.2    |
     +----------------+---------------+---------+-------------+----------+
     | Issuer         | MUST          | MUST    | MUST        | Appendix |
     |                |               |         |             | D.4.3    |
     +----------------+---------------+---------+-------------+----------+
     | Subject        | MUST          | MUST    | MUST        | Appendix |
     | Alternative    |               |         |             | D.4.4    |
     | Name (SAN)     |               |         |             |          |
     | IP6            |               |         |             |          |
     +----------------+---------------+---------+-------------+----------+
     | Subject        | MAY           | MAY     | MAY         | Appendix |
     | Alternative    |               |         |             | D.4.5    |
     | Name (SAN)     |               |         |             |          |
     | URI            |               |         |             |          |
     +----------------+---------------+---------+-------------+----------+
     | Basic          | MUST          | MUST    | MUST NOT    | CA=True, |
     | Constraints    |               |         |             | flagged  |
     |                |               |         |             | as       |
     |                |               |         |             | Critical |
     +----------------+---------------+---------+-------------+----------+
     | Subject Key    | MUST NOT      | MUST    | MUST NOT    | -        |
     | Identifier     |               | NOT     |             |          |
     | (SKI)          |               |         |             |          |
     +----------------+---------------+---------+-------------+----------+
     | Authority      | MUST NOT      | MUST    | MUST NOT    | -        |
     | Key            |               | NOT     |             |          |
     | Identifier     |               |         |             |          |
     | (AKI)          |               |         |             |          |
     +----------------+---------------+---------+-------------+----------+
     | Key Usage      | MAY           | MAY     | MAY         | -        |
     +----------------+---------------+---------+-------------+----------+
     | CA Policy      | MAY           | MAY     | MAY         | Appendix |
     | OIDs           |               |         |             | D.4.8    |
     +----------------+---------------+---------+-------------+----------+

                        Table 5: DKIX-Lite Field Matrix








  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 43]


  Internet-Draft                  det-tada                    October 2025


  D.3.  Full Profile

     The X.509 certificates are minimalistic (less than 400 bytes for
     DER).  Any DRIP specific OIDs should come from the ICAO arc (see
     Appendix D.4.8).  The profile can be found in Figure 11 and a field
     matrix found in Table 6.

     Certificate:
         Data:
             Version: 3 (0x2)
             Serial Number:
             Signature Algorithm: ED25519
             Issuer: CN =
             Validity
                 Not Before:
                 Not After :
             Subject:
             Subject Public Key Info:
                 Public Key Algorithm: ED25519
                     ED25519 Public-Key:
                     pub:
             X509v3 extensions:
                 X509v3 Subject Alternative Name: critical
                     IP Address:
                     URI:
                 X509v3 Subject Key Identifier:
                 X509v3 Authority Key Identifier:
                 X509v3 Basic Constraints: critical
                 X509v3 Key Usage: critical
         Signature Algorithm: ED25519
         Signature Value:

                          Figure 11: DKIX-Full Profile


















  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 44]


  Internet-Draft                  det-tada                    October 2025


     +=============+===============+=============+=============+========+
     | Field       | Authorization | Issuing     | Operational |Comments|
     +=============+===============+=============+=============+========+
     | Serial      | MUST          | MUST        | MUST        |Appendix|
     | Number      |               |             |             |D.4.1.2 |
     +-------------+---------------+-------------+-------------+--------+
     | Subject     | MUST          | MUST        | MUST NOT    |Appendix|
     |             |               |             |             |D.4.2   |
     +-------------+---------------+-------------+-------------+--------+
     | Issuer      | MUST          | MUST        | MUST        |Appendix|
     |             |               |             |             |D.4.3   |
     +-------------+---------------+-------------+-------------+--------+
     | Subject     | MUST          | MUST        | MUST        |Appendix|
     | Alternative |               |             |             |D.4.4   |
     | Name (SAN)  |               |             |             |        |
     | IP6         |               |             |             |        |
     +-------------+---------------+-------------+-------------+--------+
     | Subject     | MAY           | MAY         | MAY         |Appendix|
     | Alternative |               |             |             |D.4.5   |
     | Name (SAN)  |               |             |             |        |
     | URI         |               |             |             |        |
     +-------------+---------------+-------------+-------------+--------+
     | Basic       | MUST          | MUST        | MUST NOT    |CA=True,|
     | Constraints |               |             |             |flagged |
     |             |               |             |             |as      |
     |             |               |             |             |Critical|
     +-------------+---------------+-------------+-------------+--------+
     | Subject Key | MUST          | MUST        | MUST NOT    |Appendix|
     | Identifier  |               |             |             |D.4.6   |
     | (SKI)       |               |             |             |        |
     +-------------+---------------+-------------+-------------+--------+
     | Authority   | MUST          | MUST        | MUST        |Appendix|
     | Key         |               |             |             |D.4.7   |
     | Identifier  |               |             |             |        |
     | (AKI)       |               |             |             |        |
     +-------------+---------------+-------------+-------------+--------+
     | Key Usage   | SHOULD        | SHOULD      | SHOULD      |-       |
     +-------------+---------------+-------------+-------------+--------+
     | CA Policy   | RECOMMENDED   | RECOMMENDED | RECOMMENDED |Appendix|
     | OIDs        |               |             |             |D.4.8   |
     +-------------+---------------+-------------+-------------+--------+

                       Table 6: DKIX-Full Field Matrix








  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 45]


  Internet-Draft                  det-tada                    October 2025


  D.4.  Certificate Fields

     The following sections contain clarifications on the usage of fields
     in the DKIX when they deviate from "standard" X.509 [RFC5280]
     practice or have specific functions in the context of DRIP.

  D.4.1.  Serial Number

  D.4.1.1.  Lite

     The Serial Number is a MUST field, but it has no usage in this DRIP-
     Lite.  It is 1-byte in size and thus duplicates are guaranteed.  To
     drop this field could make many X.509 parsing libraries fail.

     However, CA certificate's Serial Number MAY be the common 20 bytes.
     This is to avoid possible issues with general software expecting this
     size Serial Numbers for CAs.

     If Serial Numbers are incrementally assigned, 31 bits are sufficient
     for an Issuing CA with 2B DETs active.  A CA should determine its
     best-used Serial Number field size to limit the impact of this field
     on the certificate size.

  D.4.1.2.  Full

     The certificates will contain a 20-byte randomly generated Serial
     Number, compliant with CABForum recommendations.  Serial Numbers are
     included for CRL functionality.

  D.4.2.  Subject

     The Subject field is only used in Authorization and Issuing
     Certificates.  For Operational Certificates, the Subject is Empty and
     the DET will be in Subject Alternative Name (SAN, Appendix D.4.4).
     In the SAN, the DET can be properly encoded as an IPv6 address.

     The format defined in Figure 12 MUST be used.  The CA Subject Name
     serves a dual purpose: foremost, to place the CA within the DKI tree,
     but secondly for outside of DRIP usage to tag that this CA's function
     is to serve DRIP Entities.

     DRIP-{APEX|RAA|HDA}-{A|I}[-RAA#][-HDA#]

                          Figure 12: CA Subject Format

     As examples; an Authorization DET for RAA 16376 would be: DRIP-RAA-
     A-16376 and an Issuing DET for HDA 16376 under the same RAA would be:
     DRIP-HDA-I-16376-16376.



  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 46]


  Internet-Draft                  det-tada                    October 2025


  D.4.3.  Issuer

     The Issuer MUST be the higher level's DET.

     The Issuer for the Apex Authorization certificate MUST be its DET
     (indicating self-signed).  If the RAA Authorization certificate is
     self-signed (i.e., no Apex), its Issuer is its DET.

     The Issuer content of its DET assists in finding this specific Issuer
     in the DRIP ip6.arpa.  DNS tree and any additional information.

  D.4.4.  Subject Alternative Name IP6

     Subject Alternative Name is only used in Operational certificates.
     It is used to provide the DET as an IP address with an Empty Subject
     (SAN MUST be flagged as Critical).

     The Subject Alternative Name is also used in Manufacturer DET
     certificates.  These may contain the hardwareModuleName as described
     in [_802.1AR] that references [RFC4108].

     Per [RFC5280] and [_802.1AR], Manufacturer DET certificates with
     hardwareModuleName MUST have the notAfter date as 99991231235959Z.

  D.4.5.  Subject Alternative Name URI

     This field contains a pointer in the form of a URI where additional
     information on the CA and certificates under its control can be
     found.  For example, an authorized authority may access end-entity
     PII like an Operator phone number through this URI link using the
     method specified in Section 4.3.2.

     Authorization certificates MAY have a SAN URI and MUST when it is
     self-signed.  Issuing certificates SHOULD have a SAN URI.
     Operational certificates MAY have a SAN URI.

     The RECOMMENDED configuration with respect to Issuing and Operational
     certificates for a CA is to place the SAN URI in the Issuing
     certificate and exclude them in Operational certificates.  When
     multiple providers are used by the CA to handle additional
     information there SHOULD be a unique Issuing certificate with SAN URI
     for each provider, and Operational certificates MUST NOT contain a
     SAN URI.  Otherwise a CA with multiple providers MUST NOT have a SAN
     URI in the Issuing certificate and MUST set the SAN URI to the
     specific provider for each Operational certificate.

     The contents of the SAN URI are the base URI of the host to query for
     additional information of a DET.



  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 47]


  Internet-Draft                  det-tada                    October 2025


        Author Note: do we want to create a ./well-known/hhit-query?  Then
        base URIs in the certificates can become something like:
        https://hda.example.com, then the clients append /.well-known/
        hhit-query/<ip6> (<ip6> here is a specific DET).  Path
        preservation can then be used by the server to replace /.well-
        known/hhit-query/ with whatever is required on the path for the
        specific server such as /my/bloated/path/to/rdap/ip/.

  D.4.6.  Subject Key Identifier

     The Subject Key Identifier MUST be the DET.  This is a major
     deviation from "standard" X.509 certificates that hash (normally with
     SHA2) the Public Key to fill the Subject Key Identifier.

     The Subject Key Identifier is NOT included in Operational
     certificates.  If needed by some application, it is identical with
     SAN.

  D.4.7.  Authority Key Identifier

     The Authority Key Identifier MUST be the higher level's Subject Key
     Identifier (i.e. DET).  This partially follows standard practice to
     chain up the Authority Key Identifier from the Subject Key
     Identifier, except for how the Subject Key Identifiers are populated.

     The Authority Key Identifier for the Apex Authorization (or self-
     signed RAA Authorization) certificate MUST be the Subject Key
     Identifier (indicating self-signed).

  D.4.8.  CA Policy OIDs

     It is recommended that a CA have policy OIDs defining rules for EEs
     within its domain.  The OIDs used here will tend to be within ICAO's
     arc of 1.3.27.16.

     If the CA certificate has policy OIDs, it MUST include an ICAO LOA
     OID (arc of 1.3.27.16.1.1.0) defining "the confidence in the security
     measures that protect the private key and manage the certificate
     lifecycle".

     +=====+======================+======================================+
     | OID | Description          | Applicability                        |
     +=====+======================+======================================+
     | 1   | Low                  | This level is relevant to            |
     |     |                      | environments where Risks and         |
     |     |                      | consequences of data Compromise are  |
     |     |                      | low.  Subscriber Private Keys shall  |
     |     |                      | be stored in software at this        |



  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 48]


  Internet-Draft                  det-tada                    October 2025


     |     |                      | Identity Assurance Level (IAL).      |
     +-----+----------------------+--------------------------------------+
     | 2   | LowDevice            | This policy is identical to that     |
     |     |                      | defined for the Low Assurance        |
     |     |                      | policy (above) with the exception    |
     |     |                      | of identity proofing, re-key, and    |
     |     |                      | Activation Data.                     |
     +-----+----------------------+--------------------------------------+
     | 3   | Low-TSP Mediated     | This policy is identical to that     |
     |     | Signature            | defined for the Low Assurance        |
     |     |                      | policy (above) with the exception    |
     |     |                      | that the Private key is not in the   |
     |     |                      | possession of the user, but rather   |
     |     |                      | by a Trust Service Provider.         |
     +-----+----------------------+--------------------------------------+
     | 4   | Medium               | This level is relevant to            |
     |     |                      | environments where Risks and         |
     |     |                      | consequences of data Compromise are  |
     |     |                      | moderate.  This may include          |
     |     |                      | transactions having substantial      |
     |     |                      | monetary value or Risk of fraud or   |
     |     |                      | involving access to private          |
     |     |                      | information where the likelihood of  |
     |     |                      | malicious access is substantial.     |
     |     |                      | Subscriber Private Keys shall be     |
     |     |                      | stored in software at this IAL.      |
     +-----+----------------------+--------------------------------------+
     | 5   | MediumDevice         | This policy is identical to that     |
     |     |                      | defined for the Medium Assurance     |
     |     |                      | policy (above) with the exception    |
     |     |                      | of identity proofing, re-key, and    |
     |     |                      | Activation Data.                     |
     +-----+----------------------+--------------------------------------+
     | 6   | Medium-TSP Mediated  | This policy is identical to that     |
     |     | Signature            | defined for the Medium Assurance     |
     |     |                      | policy (above) with the exception    |
     |     |                      | that the Private key is not in the   |
     |     |                      | possession of the user, but rather   |
     |     |                      | by a Trust Service Provider.         |
     +-----+----------------------+--------------------------------------+
     | 7   | MediumHardware       | This policy is identical to that     |
     |     |                      | defined for the Medium Assurance     |
     |     |                      | policy (above) with the exception    |
     |     |                      | of Subscriber Cryptographic Module   |
     |     |                      | requirements described in            |
     |     |                      | [ICAO-ACCP].                         |
     +-----+----------------------+--------------------------------------+
     | 8   | MediumDeviceHardware | This policy is identical to that     |



  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 49]


  Internet-Draft                  det-tada                    October 2025


     |     |                      | defined for the Medium Hardware      |
     |     |                      | Assurance policy (above) with the    |
     |     |                      | exception of identity proofing, re-  |
     |     |                      | key, and Activation Data.            |
     +-----+----------------------+--------------------------------------+
     | 9   | High                 | This level is relevant to            |
     |     |                      | environments where Risks and         |
     |     |                      | consequences of data Compromise are  |
     |     |                      | high.  Certificates issued at the    |
     |     |                      | High-CardAuth IAL shall only be      |
     |     |                      | issued for Card Authentication, as   |
     |     |                      | defined by NIST SP 800-73 or         |
     |     |                      | equivalent standard.  Further, this  |
     |     |                      | policy is identical to that defined  |
     |     |                      | for the identical to the             |
     |     |                      | MediumHardware IAL except where      |
     |     |                      | specifically noted in [ICAO-ACCP].   |
     +-----+----------------------+--------------------------------------+
     | 10  | High-CardAuth        | This level is relevant to            |
     |     |                      | environments where Risks and         |
     |     |                      | consequences of data Compromise are  |
     |     |                      | high.  Certificates issued at the    |
     |     |                      | High-cardAuth IAL shall only be      |
     |     |                      | issued for Card Authentication, as   |
     |     |                      | defined by NIST SP 800-73 or         |
     |     |                      | equivalent standard.                 |
     +-----+----------------------+--------------------------------------+
     | 11  | High-ContentSigning  | This level is relevant to            |
     |     |                      | environments where Risks and         |
     |     |                      | consequences of data Compromise are  |
     |     |                      | High.  This may include              |
     |     |                      | transactions having substantial      |
     |     |                      | monetary value or Risk of fraud or   |
     |     |                      | involving access to private          |
     |     |                      | information where the likelihood of  |
     |     |                      | malicious access is substantial.     |
     |     |                      | Certificates issued at the High IAL  |
     |     |                      | shall only be issued to human        |
     |     |                      | Subscribers.Certificates issued at   |
     |     |                      | the High-contentSigning IAL shall    |
     |     |                      | only be issued to the CMS for        |
     |     |                      | signing the HIGH card security       |
     |     |                      | objects (e.g. Certificates, CRLs,    |
     |     |                      | OCSP responses).  Further, this      |
     |     |                      | policy is identical to that defined  |
     |     |                      | for the identical to the             |
     |     |                      | MediumHardware IAL except where      |
     |     |                      | specifically noted in [ICAO-ACCP].   |



  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 50]


  Internet-Draft                  det-tada                    October 2025


     +-----+----------------------+--------------------------------------+

            Table 7: ICAO LOA OID Assignments under 1.3.27.16.1.1.0

     In this document, the term “Device” is defined as a Non-Person
     Entity, i.e., an entity with a digital identity that acts in
     cyberspace but is not a human actor.  This can include Organizations,
     hardware devices (e.g. a UA), software applications, and information
     artifacts.

     Operational Certificates issued to Devices shall assert policies
     mapped to LowDevice, MediumDevice, MediumDeviceHardware, or High
     Content Signing policies.  All other policies defined here should be
     reserved for human Subscribers when used in Operational Certificates.
     Thus it is recommended that Issuing CAs/HDAs should be segregated by
     device and human subscribers so policy can be stated at the CA level
     rather in individual certificates.

  Authors' Addresses

     Adam Wiethuechter
     AX Enterprize, LLC
     4947 Commercial Drive
     Yorkville, NY 13495
     United States of America
     Email: adam.wiethuechter@axenterprize.com


     Robert Moskowitz
     HTT Consulting
     Oak Park, MI 48237
     United States of America
     Email: rgm@labs.htt-consult.com


















  Wiethuechter & Moskowitz  Expires 5 April 2026                 [Page 51]


name: draft-loffredo-regext-rdap-verified-contacts
rev: 03
title: Registration Data Access Protocol (RDAP) Extension for Verified Contact Information
time: 2026-02-23T10:39:31Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-27T10:39:31Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Data formats/interop", "Policy/governance"]
tags: []
fetched_at: 2026-03-08T13:09:22.618331+00:00
source: ietf
abstract:
  This document describes an extension to the Registration Data Access
     Protocol (RDAP) that allows the inclusion of verification status
     information for contact fields such as email addresses and phone
     numbers.  The goal is to improve data quality and trustworthiness of
     RDAP responses by indicating which pieces of contact data have been
     verified and how.


name: draft-ietf-dnsop-ns-revalidation
rev: 11
title: Delegation Revalidation by DNS Resolvers
time: 2026-01-18T22:05:15Z
group_uri: /api/v1/group/group/1452/
expires: 2026-04-22T23:09:51Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/", "/api/v1/doc/state/42/"]
categories: ["Autonomous netops", "Data formats/interop"]
tags: []
fetched_at: 2026-03-08T13:09:22.621458+00:00
source: ietf
abstract:
  This document describes an optional algorithm for the processing of
     Name Server (NS) resource record (RR) sets (RRsets) during iterative
     resolution, and describes the benefits and considerations of using
     this approach.  When following a referral response from an
     authoritative server to a child zone, DNS resolvers should explicitly
     query the authoritative NS RRset at the apex of the child zone and
     cache this in preference to the NS RRset on the parent side of the
     zone cut.  The (A and AAAA) address RRsets in the additional section
     from referral responses and authoritative NS answers for the names of
     the NS RRset, should similarly be re-queried and used to replace the
     entries with the lower trustworthiness ranking in cache.  Resolvers
     should also periodically revalidate the delegation by re-querying the
     parent zone at the expiration of the TTL of either the parent or
     child NS RRset, whichever comes first.


name: draft-johani-dnsop-transport-signaling
rev: 02
title: Authoritative DNS Transport Signaling
time: 2025-10-20T20:10:19Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-23T20:10:19Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Other AI/agent"]
tags: []
fetched_at: 2026-03-08T13:09:22.624571+00:00
source: ietf
abstract:
  This document proposes a mechanism for authoritative DNS servers to
     signal their support for alternative transport protocols (e.g., DNS
     over TLS (DoT), DNS over HTTPS (DoH) and DNS over QUIC (DoQ)).  This
     signaling may either be provided within the Additional section of
     authoritative DNS responses or be the result of direct DNS queries.

     The former, "opportunistic mode" is hint-based and aims to enable
     resolvers to discover alternative transports efficiently and then
     opportunistically upgrade connections to the authoritative, thereby
     improving privacy, security, and performance for subsequent
     interactions.  The mechanism is designed to not require any protocol
     change or additional queries.  It is safe, backward-compatible, and
     effective even when DNSSEC validation of the hint is not possible or
     desired.

     In certain circumstances and with additional overhead it is also
     possible to use direct queries to securely obtain authentication
     information for the authoritative that can then be used to
     authenticate an encrypted connection.

     It is also possible to establish a "validated mode" where the
     communication between the resolver and the authoritative server is
     provably both secure and authentic.  Validated mode may not always be
     possible, depending on whether the resolver is able to DNSSEC
     validate the signal or not.  When Validated mode is possible it does
     provide a stronger and more trustworthy connection.

     This document proposes an improvement to the opportunistic (but
     blind) testing of alternative transports suggested in RFC9539 by
     providing a mechanism by which a responding authoritative server may
     signal what alternative transports it supports.

     TO BE REMOVED: This document is being collaborated on in Github at:
     https://github.com/johanix/draft-johani-dnsop-transport-signaling
     (https://github.com/johanix/draft-johani-dnsop-transport-signaling).
     The most recent working version of the document, open issues, etc,
     should all be available there.  The authors (gratefully) accept pull
     requests.


name: draft-ounsworth-lamps-x509-ar
rev: 00
title: X.509 Certificate Extensions for Attestation Results
time: 2025-11-03T07:09:24Z
group_uri: /api/v1/group/group/1027/
expires: 2025-10-28T10:47:18Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "Data formats/interop"]
tags: []
fetched_at: 2026-03-08T13:09:22.631125+00:00
source: ietf
abstract:
  This document defines extensions for X.509 certificates to include
     attestation results as part of the certificate's content.  The
     primary use case for these extensions is in the context of
     Certificate Signing Request (CSR) attestation, where claims about the
     trustworthiness of an Attester are conveyed to the Certification
     Authority (CA) as part of the CSR process.  These extensions enable
     the CA to appraise the submitted evidence and embed attestation
     results into the issued certificate.  This allows Relying Parties to
     evaluate the Attester's trustworthiness consistently and efficiently,
     supporting scalable policies for verification in environments with
     diverse attestation technologies.


name: draft-ietf-v6ops-nd-considerations
rev: 14
title: Neighbor Discovery Considerations in IPv6 Deployments
time: 2025-11-21T00:01:15Z
group_uri: /api/v1/group/group/1578/
expires: 2025-11-27T08:27:14Z
ad: /api/v1/person/person/112869/
shepherd: /api/v1/person/email/tim@qacafe.com/
categories: ["Other AI/agent"]
tags: []
fetched_at: 2026-03-08T13:09:22.634216+00:00
source: ietf
abstract:
  The Neighbor Discovery (ND) protocol is a critical component of the
     IPv6 architecture. The protocol uses multicast in many messages. It
     also assumes a security model where all nodes on a link are trusted.
     Such a design might be inefficient in some scenarios (e.g., use of
     multicast in wireless networks) or when nodes are not trustworthy
     (e.g., public access networks). These security and operational
     issues and the associated mitigation solutions are documented in
     more than 20 RFCs. There is a need to track these issues and
     solutions in a single document.

     To that aim, this document summarizes the published ND issues and
     then describes how all these issues originate from three causes.
     Addressing the issues is made simpler by addressing the causes. This
     document also analyzes the mitigation solutions and demonstrates
     that isolating hosts into different subnets and links can help to
     address the three causes. Guidance is provided for selecting a
     suitable isolation method to prevent potential ND issues.

states:
  ["/api/v1/doc/state/3/", "/api/v1/doc/state/110/", "/api/v1/doc/state/115/", "/api/v1/doc/state/7/", "/api/v1/doc/state/44/"]


name: draft-li-zt-consideration
rev: 03
title: Consideration of Applying Zero Trust Philosophy in Network Infrastructure
time: 2026-01-15T07:33:27Z
group_uri: /api/v1/group/group/1027/
expires: 2026-07-19T07:33:27Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Policy/governance", "Autonomous netops"]
tags: []
fetched_at: 2026-03-08T13:09:22.637382+00:00
source: ietf
abstract:
  Network security has traditionally relied on a perimeter-centric
     model, assuming that traffic originating within the network can be
     implicitly trusted.  This model is fundamentally challenged by
     modern, highly distributed, and software-driven network environments
     where internal compromise is a realistic and high-impact threat
     scenario.  This document examines the critical limitations of edge-
     only network protection and the systemic risks that arise from
     insufficient internal validation.  Once the network perimeter is
     bypassed, the absence of internal protection mechanisms facilitates
     rapid lateral movement, impersonation of network entities, and
     interference with critical control and management functions.

     The document argues that Zero Trust (ZT) principles, which mandate
     continuous, dynamic verification of all entities and communications
     regardless of network location, are necessary to address contemporary
     threat models.  Deploying ZT-aligned network protection mechanisms
     beyond the network edge is essential to build resilient,
     controllable, and trustworthy networks.


name: draft-li-sidrops-drr-architecture
rev: 01
title: Decentralized RPKI Repository Architecture
time: 2026-01-06T10:01:51Z
group_uri: /api/v1/group/group/1027/
expires: 2026-07-10T10:01:51Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Other AI/agent"]
tags: []
fetched_at: 2026-03-08T13:09:22.640536+00:00
source: ietf
abstract:
  The Resource Public Key Infrastructure (RPKI) plays a crucial role in
     securing inter-domain routing.  However, the current RPKI Repository
     system suffers from fundamental limitations in reliability,
     scalability, and consistency.  In particular, single-point failures
     at repository publication points (PPs), the growing number of
     bidirectional connections between PPs and relying parties (RPs), and
     the lack of a globally consistent historical RPKI data view pose
     significant risks to the resilience, integrity, and authority of the
     global RPKI ecosystem.

     This document proposes the Decentralized RPKI Repository (dRR), a
     novel repository architecture that decouples RPKI object signing
     authority from RPKI object management authority (e.g., storage and
     distribution). dRR introduces a distributed group of certificate
     servers (CSs) and a layer of Monitors to achieve robust, scalable,
     and auditable RPKI data management.  The architecture maintains full
     compatibility with the existing RPKI trust model rooted in the five
     RIR trust anchors, enabling incremental deployment without disrupting
     current relying parties (RPs) validation semantics.  By doing so, dRR
     addresses longstanding repository challenges and enhances the overall
     efficiency and trustworthiness of RPKI-based routing security.


name: draft-kamimura-rats-behavioral-evidence
rev: 01
title: On the Relationship Between Remote Attestation and Behavioral Evidence Recording
time: 2026-01-09T08:38:53Z
group_uri: /api/v1/group/group/1027/
expires: 2026-07-13T08:38:53Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth"]
tags: []
fetched_at: 2026-03-08T13:09:22.643620+00:00
source: ietf
abstract:
  This document provides an informational discussion of the conceptual
     relationship between remote attestation, as defined in RFC 9334 (RATS
     Architecture), and behavioral evidence recording mechanisms.  It
     observes that these two verification capabilities address
     fundamentally different questions - attestation addresses "Is this
     system in a trustworthy state?" while behavioral evidence addresses
     "What did the system actually do?" - and discusses how they could
     conceptually complement each other in accountability frameworks.
     This document is purely descriptive: it does not propose any
     modifications to RATS architecture, define new mechanisms or
     protocols, or establish normative requirements.  It explicitly does
     not define any cryptographic binding between attestation and
     behavioral evidence.


name: draft-bondar-wca
rev: 00
title: Warrant Certificate Authorities (WCA): Auditable Data Provenance for AI-Agent Tool-Call Chains
time: 2026-03-01T11:19:47Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-02T11:19:47Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "AI safety/alignment", "Policy/governance", "Data formats/interop"]
tags: []
fetched_at: 2026-03-08T13:09:22.647565+00:00
source: ietf
abstract:
  Large Language Model (LLM)-based agent systems increasingly invoke
     external tools and data sources, yet the epistemic provenance of
     consumed data remains architecturally unregulated.  Data crossing
     tool-call boundaries acquires the apparent trustworthiness of the
     interface rather than reflecting the institutional standing of its
     actual source -- a phenomenon termed "semantic laundering."

     This document specifies the Warrant Certificate Authority (WCA): an
     end-to-end cryptographic attestation infrastructure that certifies
     data sources, not data content.  WCA introduces a provenance layer
     satisfying reference monitor properties (complete mediation,
     tamperproofness, verifiability) for all agent-to-tool interactions.
     The architecture draws on the PKI trust model, OS provenance
     paradigms (IMA, CamFlow, LPM), and supply-chain security frameworks
     (SLSA, in-toto).

     This document defines data structures for tool-call attestation,
     warrant certificates, and a trust hierarchy of certificate
     authorities.  It specifies the provenance-layer protocol and
     introduces Warrant Attestation Levels (WAL-0 through WAL-3) as a
     graduated adoption framework analogous to SLSA build levels.

full_text:
  Network Working Group                                          R. Bondar
  Internet-Draft                                              1 March 2026
  Intended status: Informational                                          
  Expires: 2 September 2026


  Warrant Certificate Authorities (WCA): Auditable Data Provenance for AI-
                           Agent Tool-Call Chains
                            draft-bondar-wca-00

  Abstract

     Large Language Model (LLM)-based agent systems increasingly invoke
     external tools and data sources, yet the epistemic provenance of
     consumed data remains architecturally unregulated.  Data crossing
     tool-call boundaries acquires the apparent trustworthiness of the
     interface rather than reflecting the institutional standing of its
     actual source -- a phenomenon termed "semantic laundering."

     This document specifies the Warrant Certificate Authority (WCA): an
     end-to-end cryptographic attestation infrastructure that certifies
     data sources, not data content.  WCA introduces a provenance layer
     satisfying reference monitor properties (complete mediation,
     tamperproofness, verifiability) for all agent-to-tool interactions.
     The architecture draws on the PKI trust model, OS provenance
     paradigms (IMA, CamFlow, LPM), and supply-chain security frameworks
     (SLSA, in-toto).

     This document defines data structures for tool-call attestation,
     warrant certificates, and a trust hierarchy of certificate
     authorities.  It specifies the provenance-layer protocol and
     introduces Warrant Attestation Levels (WAL-0 through WAL-3) as a
     graduated adoption framework analogous to SLSA build levels.

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



  Bondar                  Expires 2 September 2026                [Page 1]


  Internet-Draft                     WCA                        March 2026


     This Internet-Draft will expire on 2 September 2026.

  Copyright Notice

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

     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.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   5
     3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   6
       3.1.  Warrant Erosion . . . . . . . . . . . . . . . . . . . . .   7
       3.2.  Semantic Laundering . . . . . . . . . . . . . . . . . . .   7
       3.3.  Insufficiency of Content-Evaluating Mediators . . . . . .   7
     4.  Architecture Overview . . . . . . . . . . . . . . . . . . . .   8
       4.1.  Design Principle  . . . . . . . . . . . . . . . . . . . .   8
       4.2.  System Components . . . . . . . . . . . . . . . . . . . .   8
     5.  Data Structures . . . . . . . . . . . . . . . . . . . . . . .   9
       5.1.  Trusted Source Registry Entry . . . . . . . . . . . . . .   9
       5.2.  Tool-Call Attestation . . . . . . . . . . . . . . . . . .  10
       5.3.  Warrant Certificate . . . . . . . . . . . . . . . . . . .  10
       5.4.  WCA Certificate . . . . . . . . . . . . . . . . . . . . .  11
       5.5.  Attestation Log Entry . . . . . . . . . . . . . . . . . .  11
     6.  WCA Trust Hierarchy . . . . . . . . . . . . . . . . . . . . .  12
       6.1.  Root WCA  . . . . . . . . . . . . . . . . . . . . . . . .  12
       6.2.  Domain WCA  . . . . . . . . . . . . . . . . . . . . . . .  12
       6.3.  Source Certificates . . . . . . . . . . . . . . . . . . .  12
       6.4.  Certificate Lifecycle . . . . . . . . . . . . . . . . . .  13
     7.  Provenance Layer Protocol . . . . . . . . . . . . . . . . . .  13
       7.1.  Protocol Flow . . . . . . . . . . . . . . . . . . . . . .  13
       7.2.  Reference Monitor Properties  . . . . . . . . . . . . . .  13
       7.3.  Attestation Log . . . . . . . . . . . . . . . . . . . . .  14
     8.  Warrant Attestation Levels  . . . . . . . . . . . . . . . . .  14
       8.1.  WAL-0: No Provenance  . . . . . . . . . . . . . . . . . .  14
       8.2.  WAL-1: Provenance Exists  . . . . . . . . . . . . . . . .  14
       8.3.  WAL-2: Signed Provenance  . . . . . . . . . . . . . . . .  14
       8.4.  WAL-3: Full Verification  . . . . . . . . . . . . . . . .  14
       8.5.  Migration Path  . . . . . . . . . . . . . . . . . . . . .  15
     9.  Non-Interference Requirements . . . . . . . . . . . . . . . .  15
       9.1.  Definition  . . . . . . . . . . . . . . . . . . . . . . .  15
       9.2.  Mediated Self-Licensing Risk  . . . . . . . . . . . . . .  15



  Bondar                  Expires 2 September 2026                [Page 2]


  Internet-Draft                     WCA                        March 2026


       9.3.  Mitigation Strategies . . . . . . . . . . . . . . . . . .  16
     10. Integration Considerations  . . . . . . . . . . . . . . . . .  16
       10.1.  Agent Framework Integration  . . . . . . . . . . . . . .  16
       10.2.  Source-Side Requirements . . . . . . . . . . . . . . . .  16
       10.3.  Performance Considerations . . . . . . . . . . . . . . .  17
     11. Security Considerations . . . . . . . . . . . . . . . . . . .  17
       11.1.  Threat Model . . . . . . . . . . . . . . . . . . . . . .  17
       11.2.  Response Substitution  . . . . . . . . . . . . . . . . .  17
       11.3.  Agent Self-Licensing . . . . . . . . . . . . . . . . . .  17
       11.4.  Replay Attacks . . . . . . . . . . . . . . . . . . . . .  17
       11.5.  Source Impersonation . . . . . . . . . . . . . . . . . .  17
       11.6.  WCA Compromise . . . . . . . . . . . . . . . . . . . . .  18
       11.7.  Attestation Log Tampering  . . . . . . . . . . . . . . .  18
       11.8.  Limitations  . . . . . . . . . . . . . . . . . . . . . .  18
     12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
       12.1.  WCA URN Namespace  . . . . . . . . . . . . . . . . . . .  18
       12.2.  WAL Level Registry . . . . . . . . . . . . . . . . . . .  18
       12.3.  WCA Epistemic Domain Registry  . . . . . . . . . . . . .  19
       12.4.  WCA Media Types  . . . . . . . . . . . . . . . . . . . .  19
     13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
       13.1.  Normative References . . . . . . . . . . . . . . . . . .  19
       13.2.  Informative References . . . . . . . . . . . . . . . . .  20
     Appendix A.  Formal Security Properties . . . . . . . . . . . . .  22
       A.1.  Property 1: No Channel-Based Semantic Laundering  . . . .  22
       A.2.  Property 2: Self-Licensing Prevention under
             Non-Interference  . . . . . . . . . . . . . . . . . . . .  22
       A.3.  Property 3: Provenance Completeness . . . . . . . . . . .  22
       A.4.  Property 4: Query-Response Binding  . . . . . . . . . . .  22
       A.5.  Property 5: Warrant Erosion Auditability  . . . . . . . .  23
       A.6.  Composability . . . . . . . . . . . . . . . . . . . . . .  23
     Appendix B.  TLA+ Model Summary . . . . . . . . . . . . . . . . .  23
     Appendix C.  Comparison with Related Systems  . . . . . . . . . .  23
     Appendix D.  JSON Serialization Examples  . . . . . . . . . . . .  24
       D.1.  Warrant Certificate . . . . . . . . . . . . . . . . . . .  24
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  24
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  24

  1.  Introduction

     The rapid deployment of Large Language Model (LLM)-based agent
     architectures has created a category of data provenance risk that
     existing security frameworks do not address.  When AI agents invoke
     external tools -- APIs, databases, web scrapers, knowledge graphs --
     they implicitly trust the data returned.  A response from a trusted
     API may have originated from a retracted study passed through several
     interpretive layers, yet the agent treats all tool outputs uniformly
     as "tool output," conflating the channel's trustworthiness with the
     content's actual provenance.



  Bondar                  Expires 2 September 2026                [Page 3]


  Internet-Draft                     WCA                        March 2026


     This problem is structurally analogous to the blockchain oracle
     problem [CHAINLINK], where smart contracts must rely on external data
     feeds without the ability to verify their correctness on-chain.
     However, AI-agent systems face an additional dimension: not merely
     data accuracy, but preservation of epistemic justification across
     architectural boundaries.

     Prior work [SEMANTIC-LAUNDERING] formalized two phenomena:

     *  Warrant Erosion: the inevitable degradation of epistemic
        justification through interpretive processing.

     *  Semantic Laundering: the acquisition of unwarranted credibility by
        data crossing trusted tool boundaries, constituting a channel-to-
        content trust conflation.

     The same authors [RESPONSIBILITY-VACUUM] demonstrated that human
     oversight undergoes a phase transition from genuine evaluation to
     ritualized approval at sufficient throughput, establishing that
     content-evaluating mediators cannot scale.

     This document specifies the Warrant Certificate Authority (WCA), an
     infrastructure that certifies data sources rather than data content.
     The key insight is architectural: just as PKI Certificate Authorities
     certify server identity without evaluating web page content, WCA
     certifies the institutional standing of data sources without judging
     the truth of individual responses.

     This design is structurally analogous to provenance layers in
     operating systems:

     *  IMA (Integrity Measurement Architecture) [IMA] tracks what code
        ran on a system via kernel-level measurement and TPM anchoring.

     *  CamFlow [CAMFLOW] tracks all information flows as a provenance
        monitor satisfying the reference monitor concept.

     *  LPM (Linux Provenance Modules) [LPM] provides 170 provenance hooks
        parallel to LSM security hooks with 2.7% overhead.

     *  PASS [PASS] introduced provenance-aware storage at the filesystem
        level.

     None of these systems evaluate the correctness or meaning of the data
     they track.  They provide complete, tamperproof, verifiable records
     of what happened.  WCA provides the same for AI agent tool calls: not
     judgment, but attestation.




  Bondar                  Expires 2 September 2026                [Page 4]


  Internet-Draft                     WCA                        March 2026


     This document makes the following contributions:

     1.  Specification of data structures for tool-call attestation,
         warrant certificates, and a hierarchical trust model for
         certificate authorities.

     2.  A provenance-layer protocol satisfying reference monitor
         properties (complete mediation, tamperproofness, verifiability)
         for AI agent tool calls.

     3.  Warrant Attestation Levels (WAL-0 through WAL-3): a graduated
         adoption framework analogous to SLSA [SLSA] build levels,
         providing practical deployment milestones.

     4.  Non-interference requirements and mitigation strategies for
         mediated self-licensing risks.

     5.  Security analysis covering response substitution, self-licensing,
         replay attacks, source impersonation, and attestation log
         tampering.

  2.  Conventions and 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.

     The following terms are used throughout this document:

     Agent:  An LLM-based system that invokes external tools and data
        sources to accomplish tasks.

     Attestation:  A cryptographically signed record binding a specific
        query to a specific response from an identified source at a
        specific time.

     Attestation Log:  An append-only, hash-chained sequence of
        attestation records maintained by the provenance layer.

     Channel-to-Content Trust Conflation:  The error of treating a
        communication channel's trustworthiness as evidence for the
        trustworthiness of specific data transmitted through that channel.

     Domain WCA:  An intermediate certificate authority covering a
        specific epistemic domain, subordinate to a Root WCA.




  Bondar                  Expires 2 September 2026                [Page 5]


  Internet-Draft                     WCA                        March 2026


     Epistemic Domain:  A bounded field of knowledge within which a
        source's institutional authority applies (e.g., "pharmacology",
        "legal-records").

     Epistemic Warrant:  The structured justification backing a
        proposition, comprising observations, inference rules, and
        institutional attestations.  WCA operationalizes only the
        institutional attestation component.

     Institutional Anchor:  The organizational basis for a source's
        authority within its epistemic domain.

     Non-Interference:  The condition that an agent is purely a consumer
        of registered source data, with no pathway to modify or influence
        what registered sources store or return.

     Provenance Layer:  The mandatory intermediary component that mediates
        all tool calls between agent and external sources.

     Root WCA:  The top-level certificate authority in a WCA hierarchy.

     Semantic Laundering:  The phenomenon whereby weakly warranted data
        acquires unwarranted epistemic status by crossing a trusted tool-
        call boundary.

     Self-Licensing:  The condition where an agent generates a proposition
        and subsequently treats it as externally warranted.

     Source:  An external system that provides data to agents via tool
        calls.

     Trusted Source Registry:  A registry maintained by WCA operators
        containing registered sources with their public keys, epistemic
        domains, and institutional anchors.

     Warrant Certificate (WC):  A compound data structure comprising a
        tool-call attestation, the source's certificate, and a chain proof
        to a trusted Root WCA.

     Warrant Attestation Level (WAL):  One of four graduated levels (WAL-0
        through WAL-3) specifying increasing provenance guarantees for
        agent systems.

     W_institutional(s, D):  The institutional warrant of source s in
        domain D.

  3.  Problem Statement




  Bondar                  Expires 2 September 2026                [Page 6]


  Internet-Draft                     WCA                        March 2026


  3.1.  Warrant Erosion

     Epistemic warrant is a structured object, not a scalar:

     warrant(p) = <O, I, S>
     where:
       O = {observations grounding p}
       I = {admissible inference rules deriving p from O}
       S = {signed attestations from institutional sources}

     For any interpretive process f:

     warrant(f(p)) is a subset of warrant(p) by O and I

     Interpretation can only lose observations and inference rules, never
     gain them.  This is the Warrant Erosion Principle
     [SEMANTIC-LAUNDERING].

  3.2.  Semantic Laundering

     Semantic laundering occurs when:

     Laundering(p, t) iff
       S(p) = {} AND trusted(t) AND agent_assigns(W(p) >= W_min)

     Data without institutional attestation gains "warranted" status
     solely by crossing a trusted tool-call interface.  This constitutes
     channel-to-content trust conflation.

  3.3.  Insufficiency of Content-Evaluating Mediators

     For any mediator M that evaluates content:

     evaluates_content(M) implies
       there exists boundary b_M such that
         Laundering(p, b_M) is possible

     The argument proceeds in four steps: (a) M must identify proposition
     boundaries (semantic judgment), (b) M must define canonical
     representations (representational assumptions), (c) M must assign
     warrant status (ritualizes under throughput [RESPONSIBILITY-VACUUM]),
     (d) M's "certified" label becomes a new laundering channel.

     This result motivates WCA's design: certify sources, not content.







  Bondar                  Expires 2 September 2026                [Page 7]


  Internet-Draft                     WCA                        March 2026


  4.  Architecture Overview

  4.1.  Design Principle

     WCA certifies sources, not content.  This distinction avoids the
     mediator vulnerability.  Evaluating content requires semantic
     judgment that scales poorly; certifying provenance requires only
     identity verification and institutional audit -- operations performed
     at registration time, not per-query.

  4.2.  System Components

     A WCA deployment consists of:

     *  Root WCA: Top-level certificate authority.

     *  Domain WCAs: Intermediate CAs for specific epistemic domains.

     *  Trusted Source Registry (R): Authorized data sources with keys and
        domain assignments.

     *  Provenance Layer: Enforcement component mediating all tool calls.

     *  Attestation Log (L): Append-only, hash-chained transaction log.

     *  Registered Sources: Data providers implementing WCA signing.

























  Bondar                  Expires 2 September 2026                [Page 8]


  Internet-Draft                     WCA                        March 2026


     +--------------+
     |  LLM Agent   |
     +------+-------+
            | query q + nonce n
            v
     +------+---------------------------+
     |      PROVENANCE LAYER            |
     |  +-----------------------------+ |
     |  | 1. Log outgoing query       | |
     |  | 2. Lookup source in R       | |
     |  | 3. Route query to source    | |
     |  | 4. Receive signed response  | |
     |  | 5. Verify signature + cert  | |
     |  | 6. Build warrant certificate| |
     |  | 7. Append to attestation log| |
     |  | 8. Deliver (r, WC) or REJECT| |
     |  +-----------------------------+ |
     +------+---------------------------+
            | response r + WC (or rejection)
            v
     +------+-------+
     | Tool / Source |
     | (signs r)    |
     +--------------+

  5.  Data Structures

  5.1.  Trusted Source Registry Entry

     {
       "source_id":   "urn:wca:source:<name>",
       "public_key":  "<SubjectPublicKeyInfo>",
       "domain":      "urn:wca:domain:<domain-name>",
       "anchor":      { "organization": "...", "basis": "..." },
       "valid_from":  "<DateTime>",
       "valid_until": "<DateTime>",
       "issuer_wca":  "urn:wca:authority:<wca-name>",
       "revocation":  { "crl_uri": "...", "ocsp_uri": "..." }
     }

     source_id:  Globally unique URI using the "urn:wca:source:" prefix.

     public_key:  MUST be ECDSA P-256 [RFC6979] or Ed25519 [RFC8032].

     domain:  MUST be from the WCA Epistemic Domain Registry
        (Section 12.3).

     anchor:  Institutional basis for authority, populated during



  Bondar                  Expires 2 September 2026                [Page 9]


  Internet-Draft                     WCA                        March 2026


        registration audit.

     valid_from / valid_until:  Validity period.  Source certificates
        SHOULD have a maximum validity of one year.  Renewal requires re-
        audit.

  5.2.  Tool-Call Attestation

     For query q from agent a to source s returning response r:

     signature = Sign(K_priv_s,
                      H(query || response || timestamp ||
                        nonce || agent_id))

     where Sign() is ECDSA-P256-SHA256 [RFC6979] or Ed25519 [RFC8032], H()
     is SHA-256 [RFC6234], and || denotes concatenation of canonical byte
     encodings.

     Each field MUST be prefixed with a 4-byte big-endian length followed
     by the field bytes.

     The source MUST sign the binding of all five components.  Nonce
     inclusion prevents replay; agent_id inclusion prevents cross-agent
     substitution.

     Protocol:

     1.  Agent generates query q and cryptographically random nonce n (>=
         16 bytes).

     2.  Provenance layer forwards (q, agent_id, n) to source s.

     3.  Source computes response r.

     4.  Source obtains timestamp tau from a trusted time source.

     5.  Source computes signature.

     6.  Source returns (r, tau, signature).

     7.  Provenance layer verifies using K_pub_s from R.

  5.3.  Warrant Certificate








  Bondar                  Expires 2 September 2026               [Page 10]


  Internet-Draft                     WCA                        March 2026


     {
       "attestation":        "<ToolCallAttestation>",
       "source_certificate": "<SourceCertificate>",
       "chain_proof":        ["<CertificateChainEntry>"]
     }

     The SourceCertificate issuer_signature is:

     issuer_signature = Sign(K_priv_WCA,
                             H(source_id || public_key ||
                               domain || anchor ||
                               valid_from || valid_until))

  5.4.  WCA Certificate

     {
       "wca_id":           "urn:wca:authority:<name>",
       "public_key":       "<SubjectPublicKeyInfo>",
       "domain_scope":     ["urn:wca:domain:<d1>", "..."],
       "trust_anchor":     { "organization": "...", "basis": "..." },
       "parent_wca":       "urn:wca:authority:<parent>" or null,
       "valid_from":       "<DateTime>",
       "valid_until":      "<DateTime>",
       "parent_signature": "<OCTET STRING>" or null
     }

     Root WCA certificates are self-signed.  Domain WCA certificates MUST
     be signed by their parent WCA.  WCA key pairs MUST be generated and
     stored in HSMs.  Root WCA key generation MUST use multi-party key
     ceremony procedures.

  5.5.  Attestation Log Entry

     {
       "sequence_number": 42,
       "query":           "<exact bytes>",
       "source_id":       "urn:wca:source:<name>",
       "response":        "<exact bytes>",
       "signature":       "<base64>",
       "timestamp":       "<DateTime>",
       "warrant_cert":    "<WarrantCertificate>",
       "previous_hash":   "<hex>",
       "entry_hash":      "<hex>"
     }







  Bondar                  Expires 2 September 2026               [Page 11]


  Internet-Draft                     WCA                        March 2026


     entry_hash is computed over all preceding fields.  previous_hash
     links to the predecessor.  The log MUST be append-only.
     Implementations SHOULD periodically commit the chain head to an
     external transparency log.

  6.  WCA Trust Hierarchy

  6.1.  Root WCA

     *  MUST store private key in HSM with multi-party access controls.

     *  MUST use offline key storage.

     *  MUST maintain Certificate Transparency log of issued Domain WCA
        certificates.

     *  SHOULD be operated by a consortium or standards body.

  6.2.  Domain WCA

     *  MUST have certificate signed by Root or parent Domain WCA.

     *  MUST specify domain_scope.

     *  MUST perform institutional audit before issuing source
        certificates.

     *  MUST maintain CRL or operate OCSP responder.

     Example hierarchy:

     Root WCA (global trust anchor)
       |
       +-- Health WCA (medicine, pharmacology, genomics)
       |     +-- urn:wca:source:fda-druginteractions-v3
       |     +-- urn:wca:source:pubmed-api-v2
       |
       +-- Legal WCA (legal-records, court-rulings)
       |     +-- urn:wca:source:pacer-federal-courts
       |
       +-- Meteorological WCA (weather, climate)
             +-- urn:wca:source:noaa-weather-api-v3

  6.3.  Source Certificates

     Issuance requires: (1) institutional audit, (2) key verification, (3)
     domain validation.  Certificates SHOULD have maximum one-year
     validity.  Renewal MUST include re-audit.



  Bondar                  Expires 2 September 2026               [Page 12]


  Internet-Draft                     WCA                        March 2026


  6.4.  Certificate Lifecycle

     Issuance -> Active -> Renewal (with re-audit) or Revocation.
     Revocation triggers: key compromise, institutional standing change,
     misrepresentation of data sourcing, WCA operator determination.

     Provenance layer MUST check revocation before accepting signatures.
     Implementations SHOULD cache revocation status (max 24 hours).

  7.  Provenance Layer Protocol

  7.1.  Protocol Flow

     Step 1 - Query Registration:  Agent submits query q with fresh nonce
        n.  Provenance layer records (q, agent_id, n, timestamp_local).

     Step 2 - Source Lookup:  Consult R; verify source is registered and
        certificate is valid.  If invalid, MUST reject and log rejection
        with reason code.

     Step 3 - Query Routing:  Forward (q, agent_id, n) to source over
        authenticated channel.  SHOULD use mTLS.

     Step 4 - Response Receipt:  Source computes r, obtains tau, signs
        binding, returns (r, tau, signature).

     Step 5 - Signature Verification:  Verify using K_pub_s from Cert_s.
        On failure, MUST reject, MUST log failure, MUST NOT deliver to
        agent.

     Step 6 - Warrant Certificate Construction:  Assemble WC =
        (Att(q,s,r), Cert_s, ChainProof).

     Step 7 - Attestation Log Append:  Append e_i = (seq_i, q, s_id, r,
        signature, tau, WC, H(e_{i-1})).

     Step 8 - Delivery or Rejection:  Deliver (r, WC) or rejection notice.
        Rejected data MUST NOT enter agent reasoning context.

     Warrant assignment upon delivery:

     W(r | valid WC from source s in domain D) = W_institutional(s, D)
     W(r | invalid WC or absent WC)            = 0

  7.2.  Reference Monitor Properties

     The provenance layer MUST satisfy three properties per [ANDERSON] and
     [CAMFLOW]:



  Bondar                  Expires 2 September 2026               [Page 13]


  Internet-Draft                     WCA                        March 2026


     RM1 - Complete Mediation:  Every external data access by the agent
        MUST pass through the provenance layer.  The agent MUST NOT have
        direct network access to external sources.  SHOULD be enforced via
        network isolation.

     RM2 - Tamperproofness:  Attestation log MUST be append-only and hash-
        chained.

     RM3 - Verifiability:  Any party with log access and public keys MUST
        be able to independently verify every entry.

  7.3.  Attestation Log

     The log MUST be append-only and hash-chained.  Implementations SHOULD
     replicate to external audit services.  SHOULD define retention policy
     per regulatory context.  SHOULD periodically commit chain head to
     external transparency log.

  8.  Warrant Attestation Levels

  8.1.  WAL-0: No Provenance

     Baseline state.  No guarantees.  Default for current agent systems.

  8.2.  WAL-1: Provenance Exists

     Source identification recorded; cryptographic verification MAY be
     absent.  Provenance layer MUST log source identity and responses.
     Post-hoc attribution possible but not cryptographically verified.
     Adoption cost: minimal (middleware only).

  8.3.  WAL-2: Signed Provenance

     Sources MUST sign responses per Section 5.2.  Source keys MUST be
     certified by Domain WCA.  Provenance layer MUST verify signatures.
     Guarantees: query-response binding, source authenticity, anti-
     laundering bound.  Adoption cost: moderate.

  8.4.  WAL-3: Full Verification

     Provenance layer MUST satisfy RM1-RM3.  All tool calls MUST be logged
     in hash-chained attestation log.  Agents MUST generate signed queries
     with nonces.  Non-interference MUST be enforced or M2 MUST be
     implemented (Section 9.3).  Guarantees: all five security properties
     (Appendix A).  Adoption cost: highest.






  Bondar                  Expires 2 September 2026               [Page 14]


  Internet-Draft                     WCA                        March 2026


           +==========================+=========+=================+
           | Use Case                 | Min WAL | Rationale       |
           +==========================+=========+=================+
           | Exploratory research     | WAL-0   | Low stakes      |
           +--------------------------+---------+-----------------+
           | General info retrieval   | WAL-1   | Post-hoc review |
           +--------------------------+---------+-----------------+
           | Business intelligence    | WAL-2   | Source verify   |
           +--------------------------+---------+-----------------+
           | Medical decision support | WAL-3   | Safety-critical |
           +--------------------------+---------+-----------------+
           | Legal research           | WAL-3   | Regulatory      |
           +--------------------------+---------+-----------------+
           | Financial trading        | WAL-3   | Fiduciary duty  |
           +--------------------------+---------+-----------------+

                                   Table 1

  8.5.  Migration Path

     Phase 1 (WAL-0 to WAL-1): Deploy logging middleware.  Phase 2 (WAL-1
     to WAL-2): Source signing + Domain WCA setup.  Phase 3 (WAL-2 to WAL-
     3): Full RM1-RM3 + attestation log.

  9.  Non-Interference Requirements

  9.1.  Definition

     Agent a satisfies non-interference w.r.t. registry R iff:

     NI-1:  a has no write access to any registered source s in R.

     NI-2:  a does not control or operate any registered source s in R.

     NI-3:  a cannot influence the stored state of any upstream system
        feeding s in R.

     WAL-3 deployments MUST enforce non-interference or implement an
     equivalent mitigation.

  9.2.  Mediated Self-Licensing Risk

     When NI-1 is violated, the following loop is possible:

     1.  Agent generates content.

     2.  Agent writes content to registered source.




  Bondar                  Expires 2 September 2026               [Page 15]


  Internet-Draft                     WCA                        March 2026


     3.  Agent queries that source.

     4.  Source returns content with valid signature.

     5.  Provenance layer issues WC.

     6.  Agent's own content carries institutional warrant.

     TLA+ model checking confirms: with non-interference, 286 states
     explored, no self-licensing.  Without: counterexample in 3
     transitions.

  9.3.  Mitigation Strategies

     WAL-3 deployments MUST enforce at least one:

     M1 - Non-Interference at Deployment:  Read-only access to registered
        sources.  Strongest mitigation.

     M2 - Origin-Aware Warrant Assignment:  If data in source was written
        by agent a, queries from a receive W = 0.

     M3 - Institutional Transformation Gate:  Agent-written data undergoes
        institutional process (peer review, QA) before becoming queryable
        with warrant.

  10.  Integration Considerations

  10.1.  Agent Framework Integration

     LangChain/LangGraph:  Provenance layer as BaseTool.invoke() wrapper.

     AutoGen/AG2:  Shared provenance layer at tool execution boundary.

     Model Context Protocol (MCP):  MCP servers implement signing; MCP
        clients verify via provenance layer.

     OpenAI Function Calling / Anthropic Tool Use:  Provenance layer wraps
        function execution step.

  10.2.  Source-Side Requirements

     Sources at WAL-2+ MUST: generate key pair (ECDSA P-256 or Ed25519),
     implement signing endpoint, undergo institutional audit, implement
     certificate renewal and key rotation.

     Sources SHOULD: use HSMs, implement rate limiting, monitor for
     anomalous signing.



  Bondar                  Expires 2 September 2026               [Page 16]


  Internet-Draft                     WCA                        March 2026


  10.3.  Performance Considerations

     Per-query overhead: sub-millisecond for cryptographic operations.
     Ed25519 signs at ~70K ops/sec, verifies at ~30K ops/sec.  SHA-256 >1
     GB/s.  Dominated by network latency.

     LPM demonstrated 2.7% overhead for whole-system kernel provenance;
     WCA at tool-call granularity is expected negligible.

  11.  Security Considerations

  11.1.  Threat Model

     Attacker can: MITM traffic, operate malicious sources, inject
     unattested data, replay responses, impersonate sources, tamper with
     log.

     Trust assumptions: Root WCA key security (HSM), sound crypto
     primitives, correct RM1-RM3 enforcement, institutional audit at
     registration.

     Out of scope: registered source providing incorrect data (source
     quality, not provenance).

  11.2.  Response Substitution

     Defense: signature covers H(q || r || tau || nonce || agent_id).
     Modification detected.  Residual: key compromise (standard PKI
     mitigations).

  11.3.  Agent Self-Licensing

     Defense: non-interference prevents registration and indirect
     pathways.  W = 0 for agent-generated propositions.  Residual: NI
     violation enables mediated self-licensing (Section 9.3).

  11.4.  Replay Attacks

     Defense: nonce in signature binding.  Timestamp enables freshness.
     Implementations MUST use >= 16 byte random nonces.

  11.5.  Source Impersonation

     Defense: certificate chain to Root WCA.  Residual: WCA compromise.







  Bondar                  Expires 2 September 2026               [Page 17]


  Internet-Draft                     WCA                        March 2026


  11.6.  WCA Compromise

     Defense: HSMs, multi-party ceremonies, CT logs, CRLs/OCSP, short-
     lived certificates.

  11.7.  Attestation Log Tampering

     Defense: hash chain; modification cascades.  External transparency
     log anchoring for additional assurance.

  11.8.  Limitations

     WCA does NOT defend against: source inaccuracy, domain mismatch,
     agent reasoning errors, WCA-source collusion, interpretive warrant
     erosion (but preserves originals in log for audit).

  12.  IANA Considerations

  12.1.  WCA URN Namespace

     This document requests registration of formal URN namespace "wca" per
     [RFC8141].

     Syntax: urn:wca:<entity-type>:<entity-name>

     Entity types: "authority", "source", "domain".

  12.2.  WAL Level Registry

     New IANA registry "Warrant Attestation Levels":

                 +=======+===================+===============+
                 | Level | Name              | Reference     |
                 +=======+===================+===============+
                 | 0     | No Provenance     | This document |
                 +-------+-------------------+---------------+
                 | 1     | Provenance Exists | This document |
                 +-------+-------------------+---------------+
                 | 2     | Signed Provenance | This document |
                 +-------+-------------------+---------------+
                 | 3     | Full Verification | This document |
                 +-------+-------------------+---------------+

                                    Table 2

     New levels require Standards Action [RFC8126].





  Bondar                  Expires 2 September 2026               [Page 18]


  Internet-Draft                     WCA                        March 2026


  12.3.  WCA Epistemic Domain Registry

     New IANA registry "WCA Epistemic Domains" with initial entries:

            +==================+==================================+
            | Domain           | Description                      |
            +==================+==================================+
            | pharmacology     | Drug data, interactions          |
            +------------------+----------------------------------+
            | medical-records  | Clinical records                 |
            +------------------+----------------------------------+
            | medical-lit      | Peer-reviewed medical literature |
            +------------------+----------------------------------+
            | legal-records    | Court records, filings           |
            +------------------+----------------------------------+
            | legal-lit        | Legal scholarship                |
            +------------------+----------------------------------+
            | meteorology      | Weather, climate                 |
            +------------------+----------------------------------+
            | genomics         | Genomic sequences                |
            +------------------+----------------------------------+
            | financial-reg    | Regulatory filings               |
            +------------------+----------------------------------+
            | financial-market | Market data                      |
            +------------------+----------------------------------+
            | geospatial       | Geographic, satellite data       |
            +------------------+----------------------------------+

                                    Table 3

     New domains require Specification Required [RFC8126].

  12.4.  WCA Media Types

     application/wca-warrant-certificate+json:  JSON serialization of
        Warrant Certificates.

     application/wca-attestation-log+json:  JSON serialization of
        Attestation Log entries.

  13.  References

  13.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/rfc/rfc2119>.



  Bondar                  Expires 2 September 2026               [Page 19]


  Internet-Draft                     WCA                        March 2026


     [RFC6234]  Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
                (SHA and SHA-based HMAC and HKDF)", RFC 6234,
                DOI 10.17487/RFC6234, May 2011,
                <https://www.rfc-editor.org/rfc/rfc6234>.

     [RFC6979]  Pornin, T., "Deterministic Usage of the Digital Signature
                Algorithm (DSA) and Elliptic Curve Digital Signature
                Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
                2013, <https://www.rfc-editor.org/rfc/rfc6979>.

     [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
                Signature Algorithm (EdDSA)", RFC 8032,
                DOI 10.17487/RFC8032, January 2017,
                <https://www.rfc-editor.org/rfc/rfc8032>.

     [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
                Writing an IANA Considerations Section in RFCs", BCP 26,
                RFC 8126, DOI 10.17487/RFC8126, June 2017,
                <https://www.rfc-editor.org/rfc/rfc8126>.

     [RFC8141]  Saint-Andre, P. and J. Klensin, "Uniform Resource Names
                (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017,
                <https://www.rfc-editor.org/rfc/rfc8141>.

     [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/rfc/rfc8174>.

     [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
                Interchange Format", STD 90, RFC 8259,
                DOI 10.17487/RFC8259, December 2017,
                <https://www.rfc-editor.org/rfc/rfc8259>.

  13.2.  Informative References

     [ANDERSON] Anderson, J. P., "Computer Security Technology Planning
                Study", Technical Report ESD-TR-73-51, 1972.

     [AUTH-PROMPTS]
                Rajagopalan, M. and V. Rao, "Protecting Context and
                Prompts: Deterministic Security for Non-Deterministic AI",
                arXiv 2602.10481, 2026.

     [BAID]     Lin, Z., Zhang, S., Liao, G., Tao, D., and T. Wang,
                "Binding Agent ID", arXiv 2512.17538, 2025.

     [CAMEL]    Debenedetti, E., Shumailov, I., and T. Fan, "Defeating
                Prompt Injections by Design", arXiv 2503.18813, 2025.



  Bondar                  Expires 2 September 2026               [Page 20]


  Internet-Draft                     WCA                        March 2026


     [CAMFLOW]  Pasquier, T., Han, X., Goldstein, M., Moyer, T., Eyers,
                D., Seltzer, M., and J. Bacon, "Practical Whole-System
                Provenance Capture", arXiv 1711.05296, 2017.

     [CHAINLINK]
                Ellis, S., Juels, A., and S. Nazarov, "Chainlink: A
                Decentralized Oracle Network", White Paper, 2017.

     [CIV]      Gupta, A., "CIV: Can AI Keep a Secret? Contextual
                Integrity Verification", arXiv 2508.09288, 2025.

     [DIDS-VCS] Garzon, S. R., "AI Agents with Decentralized Identifiers
                and Verifiable Credentials", arXiv 2511.02841, 2025.

     [GETTIER]  Gettier, E. L., "Is Justified True Belief Knowledge?",
                Analysis Vol. 23, No. 6, pp. 121-123, 1963.

     [IMA]      Linux IMA, "Integrity Measurement Architecture", n.d.,
                <https://sourceforge.net/p/linux-ima/wiki/Home/>.

     [IN-TOTO]  in-toto Project, "A Framework for Securing Software Supply
                Chains", n.d., <https://in-toto.io/>.

     [LPM]      Bates, A., Tian, D. J., Butler, K. R. B., and T. Moyer,
                "Trustworthy Whole-System Provenance for the Linux
                Kernel", USENIX Security Symposium, 2015.

     [MAIF]     Narajala, V. S., "MAIF: Enforcing AI Trust and Provenance
                with an Artifact-Centric Paradigm", arXiv 2511.15097,
                2025.

     [OMEGA]    Stavrakakis, D., "Trusted AI Agents in the Cloud",
                arXiv 2512.05951, 2025.

     [PASS]     Muniswamy-Reddy, K., Holland, D. A., Braun, U., and M.
                Seltzer, "Provenance-Aware Storage Systems", USENIX ATC,
                2006.

     [PROV-AGENT]
                Souza, R., "PROV-AGENT: Unified Provenance for AI Agent
                Interactions", arXiv 2508.02866, 2025.

     [RAG-SIGN] Holmes, S. A., "RAG Sign: Cryptographic Authentication for
                RAG-Enabled LLMs", Springer LNCS 15692, 2025.







  Bondar                  Expires 2 September 2026               [Page 21]


  Internet-Draft                     WCA                        March 2026


     [RESPONSIBILITY-VACUUM]
                Romanchuk, O. and R. Bondar, "The Responsibility Vacuum:
                Organizational Failure in Scaled Agent Systems",
                arXiv 2601.15059, January 2026,
                <https://arxiv.org/abs/2601.15059>.

     [SEMANTIC-LAUNDERING]
                Romanchuk, O. and R. Bondar, "Semantic Laundering in AI
                Agent Architectures: Why Tool Boundaries Do Not Confer
                Epistemic Warrant", arXiv 2601.08333, January 2026,
                <https://arxiv.org/abs/2601.08333>.

     [SLSA]     OpenSSF, "SLSA: Supply-chain Levels for Software
                Artifacts", n.d., <https://slsa.dev/>.

     [SPIFFE]   SPIFFE Project, "Secure Production Identity Framework for
                Everyone", n.d., <https://spiffe.io/>.

     [VFA]      Gupta, A., "Verifiability-First Agents", arXiv 2512.17259,
                2025.

  Appendix A.  Formal Security Properties

     All properties assume RM1-RM3 and EUF-CMA signature security.

  A.1.  Property 1: No Channel-Based Semantic Laundering

     For all p received by agent a: W(p) <= W_institutional(source(p)).
     Data cannot gain warrant above source's institutional standing.

  A.2.  Property 2: Self-Licensing Prevention under Non-Interference

     For all p generated by agent a: if NonInterference(a, R) then W(p) =
     0.

  A.3.  Property 3: Provenance Completeness

     For all data d in agent context: either d has attestation log entry
     with valid WC, or W(d) = 0.

  A.4.  Property 4: Query-Response Binding

     Valid signature implies r is exactly what source s returned to query
     q at time tau.  Substitution detectable.







  Bondar                  Expires 2 September 2026               [Page 22]


  Internet-Draft                     WCA                        March 2026


  A.5.  Property 5: Warrant Erosion Auditability

     Agent interpretation may degrade warrant, but original data and
     attestation are always recoverable from log L.

  A.6.  Composability

     Multi-hop chains: W(final) = min_i(W_institutional(source_i)).  No
     laundering through composition.

  Appendix B.  TLA+ Model Summary

     Model verified with TLC:

     *  WCA_Strict.cfg (non-interference): PASS, 286 states.

     *  WCA_MediatedLoop.cfg (NI violated): FAIL, counterexample in 3
        transitions (agent generates, writes to source, queries back with
        warrant > 0).

  Appendix C.  Comparison with Related Systems

       +=============================+========================+=======+
       | Dimension                   | Covered By             | WCA   |
       +=============================+========================+=======+
       | Agent identity              | BAID, DIDs+VCs, SPIFFE | --    |
       +-----------------------------+------------------------+-------+
       | Execution environment       | Omega, TEEs            | --    |
       +-----------------------------+------------------------+-------+
       | Action audit trails         | PROV-AGENT, VFA, MAIF  | --    |
       +-----------------------------+------------------------+-------+
       | Access control              | CaMeL                  | --    |
       +-----------------------------+------------------------+-------+
       | Prompt/context integrity    | Auth.  Prompts, CIV    | --    |
       +-----------------------------+------------------------+-------+
       | Output signing              | RAG Sign               | --    |
       +-----------------------------+------------------------+-------+
       | *Data source warrant*       | *NONE*                 | *YES* |
       +-----------------------------+------------------------+-------+
       | *Anti-channel-laundering*   | *NONE*                 | *YES* |
       +-----------------------------+------------------------+-------+
       | *Self-licensing prevention* | *NONE*                 | *YES* |
       +-----------------------------+------------------------+-------+
       | *End-to-end attestation*    | *NONE*                 | *YES* |
       +-----------------------------+------------------------+-------+

                                   Table 4




  Bondar                  Expires 2 September 2026               [Page 23]


  Internet-Draft                     WCA                        March 2026


  Appendix D.  JSON Serialization Examples

  D.1.  Warrant Certificate

     {
       "attestation": {
         "query": "GET /interactions?drug_a=ibuprofen&drug_b=warfarin",
         "source_id": "urn:wca:source:fda-druginteractions-v3",
         "response": "{\"interaction\":\"major\",\"severity\":\"high\"}",
         "timestamp": "2026-02-12T14:30:00Z",
         "nonce": "a7f3c9e1d4b2f6a8e0c7d3b5a9f1e2c4",
         "agent_id": "urn:agent:medical-advisor-v2",
         "signature": "MEUCIQD.../base64...=="
       },
       "source_certificate": {
         "source_id": "urn:wca:source:fda-druginteractions-v3",
         "public_key": "MFkwEwYHKoZIzj0.../base64...",
         "domain": "urn:wca:domain:pharmacology",
         "anchor": {
           "organization": "U.S. Food and Drug Administration",
           "basis": "Federal regulatory mandate",
           "audit_date": "2026-01-15"
         },
         "valid_from": "2026-01-01T00:00:00Z",
         "valid_until": "2027-01-01T00:00:00Z",
         "issuer_wca_id": "urn:wca:authority:health-wca-us",
         "issuer_signature": "MEUCIQCx.../base64...=="
       },
       "chain_proof": [
         {
           "wca_id": "urn:wca:authority:health-wca-us",
           "parent": "urn:wca:authority:root-wca-global-v1",
           "signature": "MEYCIQDp.../base64...=="
         }
       ]
     }

  Acknowledgments

     The foundational concepts of warrant erosion and semantic laundering
     were developed jointly with Oleg Romanchuk in [SEMANTIC-LAUNDERING]
     and [RESPONSIBILITY-VACUUM].

  Author's Address

     Roman Bondar
     Email: bondar.roman@gmail.com




  Bondar                  Expires 2 September 2026               [Page 24]


name: draft-ffm-rats-cca-token
rev: 03
title: Arm's Confidential Compute Architecture Reference Attestation Token
time: 2026-03-02T16:28:00Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-03T16:28:00Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth"]
tags: []
fetched_at: 2026-03-08T13:09:22.654078+00:00
source: ietf
abstract:
  The Arm Confidential Compute Architecture (CCA) is series of hardware
     and software innovations that enhance Arm’s support for Confidential
     Computing for large, compute-intensive workloads.  Devices that
     implement CCA can produce attestation tokens as described in this
     memo, which are the basis for trustworthiness assessment of the
     Confidential Compute environment.  This document specifies the CCA
     attestation token structure and semantics.

     The CCA attestation token is a profile of the Entity Attestation
     Token (EAT).  This specification describes what claims are used in an
     attestation token generated by CCA compliant systems, how these
     claims get serialized to the wire, and how they are cryptographically
     protected.

     This informational document is published as an independent submission
     to improve interoperability with Arm's architecture.  It is not a
     standard nor a product of the IETF.


name: w3c-authentform
rev: 00
title: User Agent Authentication Forms
time: 19990203
states: []
categories: ["Human-agent interaction"]
tags: []
fetched_at: 2026-03-08T13:09:36.711264+00:00
source: w3c
abstract:
  This note proposes a new HTML capability to aid in the development of authenticated web user interfaces.


name: w3c-cuap
rev: 00
title: Common User Agent Problems
time: 20030128
states: []
categories: ["Other AI/agent"]
tags: []
fetched_at: 2026-03-08T13:09:36.724552+00:00
source: w3c
abstract:
  This document explains some common mistakes in user agents due to incorrect or incomplete implementation of specifications, and suggests remedies. It also suggests some "good behavior" where specifications themselves do not specify any particular behavior (e.g., in the face of error conditions). This document is not a complete set of guidelines for good user agent behavior. Note: This document does not incriminate specific user agents. W3C does not generally track bugs or errors in implementations. That information is generally tracked by the vendors themselves or third parties.


name: w3c-UAAG10
rev: 00
title: User Agent Accessibility Guidelines 1.0
time: 20021217
states: []
categories: ["Human-agent interaction", "Policy/governance"]
tags: []
fetched_at: 2026-03-08T13:09:36.727976+00:00
source: w3c
abstract:
  This document provides guidelines for designing user agents that lower barriers to Web accessibility for people with disabilities (visual, hearing, physical, cognitive, and neurological). User agents include HTML browsers and other types of software that retrieve and render Web content. A user agent that conforms to these guidelines will promote accessibility through its own user interface and through other internal facilities, including its ability to communicate with other technologies (especially assistive technologies). Furthermore, all users, not just users with disabilities, should find conforming user agents to be more usable. In addition to helping developers of HTML browsers and media players, this document will also benefit developers of assistive technologies because it explains what types of information and control an assistive technology may expect from a conforming user agent. Technologies not addressed directly by this document (e.g., technologies for braille rendering) will be essential to ensuring Web access for some users with disabilities.


name: w3c-UAAG10-TECHS
rev: 00
title: Techniques for User Agent Accessibility Guidelines 1.0
time: 20021217
states: []
categories: ["Human-agent interaction", "Data formats/interop"]
tags: []
fetched_at: 2026-03-08T13:09:36.731260+00:00
source: w3c
abstract:
  This document provides techniques for satisfying the checkpoints defined in "User Agent Accessibility Guidelines 1.0" [UAAG10] . These techniques address key aspects of the accessibility of user interfaces, content rendering, application programming interfaces ( APIs ), and languages such as the Hypertext Markup Language ( HTML ), Cascading Style Sheets ( CSS ) and the Synchronized Multimedia Integration Language ( SMIL ). The techniques listed in this document are not required for conformance to the Guidelines. These techniques are not necessarily the only way of satisfying the checkpoint, nor are they a definitive set of requirements for satisfying a checkpoint.


name: w3c-UAAG20-requirements
rev: 00
title: User Agent Accessibility Guidelines 2.0 Requirements
time: 20071031
states: []
categories: ["Policy/governance", "Human-agent interaction"]
tags: []
fetched_at: 2026-03-08T13:09:36.734568+00:00
source: w3c
abstract:
  This First Public Working Draft outlines the requirements that the User Agent Accessibility Guidelines Working Group (UAWG) has set for development of User Agent Accessibility Guidelines 2.0 (UAAG 2.0). These requirements are based on feedback from the use of UAAG 1.0 and will be used to determine if the UAWG has met its goals as UAAG 2.0 advances through the W3C Recommendation Track Process.


name: w3c-UAAG20
rev: 00
title: User Agent Accessibility Guidelines (UAAG) 2.0
time: 20151215
states: []
categories: ["Human-agent interaction", "Policy/governance"]
tags: []
fetched_at: 2026-03-08T13:09:36.738210+00:00
source: w3c
abstract:
  This document provides guidelines for designing user agents that lower barriers to Web accessibility for people with disabilities. User agents include browsers and other types of software that retrieve and render Web content. A user agent that conforms to these guidelines will promote accessibility through its own user interface and through other internal facilities, including its ability to communicate with other technologies (especially assistive technologies). Furthermore, all users, not just users with disabilities, should find conforming user agents to be more usable. In addition to helping developers of browsers and media players, this document will also benefit developers of assistive technologies because it explains what types of information and control an assistive technology may expect from a conforming user agent. Technologies not addressed directly by this document (e.g., technologies for braille rendering) will be essential to ensuring Web access for some users with disabilities. The "User Agent Accessibility Guidelines 2.0" ( UAAG 2.0) is part of a series of accessibility guidelines published by the W3C Web Accessibility Initiative ( WAI ).


name: w3c-wai-aria-implementation
rev: 00
title: WAI-ARIA 1.0 User Agent Implementation Guide
time: 20140320
states: []
categories: ["Human-agent interaction", "Data formats/interop"]
tags: []
fetched_at: 2026-03-08T13:09:36.751165+00:00
source: w3c
abstract:
  Describes how user agents should support keyboard navigation, respond to roles, states, and properties provided in Web content via WAI-ARIA, and expose this to accessibility APIs.


name: w3c-UAAG20-Reference
rev: 00
time: 20151215
states: []
categories: ["Human-agent interaction", "Policy/governance"]
tags: []
fetched_at: 2026-03-08T13:09:36.757658+00:00
source: w3c
title:
  UAAG 2.0 Reference: Explanations, Examples, and Resources for User Agent Accessibility Guidelines 2.0

abstract:
  This document provides explanation of the intent of UAAG 2.0 success criteria, examples of implementation of the UAAG 2.0 guidelines, best practice recommendations and additional resources for the guidelines.


name: w3c-agent-attributes
rev: 00
title: Client-Specific Web Services by Using User Agent Attributes
time: 19971230
states: []
categories: ["Agent discovery/reg", "Data formats/interop"]
tags: []
fetched_at: 2026-03-08T13:09:36.760685+00:00
source: w3c
abstract:
  This document describes a simple framework for realizing client-specific web services. The proposed method uses the client properties such as screen size and colors, available input methods, web page capacity, secondary storage size, product category, CPU type, and etc., which we call "User Agent Attributes". We also describe an implementation of this framework by using the User-Agent header in HTTP. This enables the client-specific services for various Internet information appliances like Internet-TVs, PDAs, and smart phones.


name: w3c-imagemap
rev: 00
title: Imagemapped Images and Image-Incapable User Agents
time: 19961127
states: []
categories: ["Human-agent interaction", "Data formats/interop"]
tags: []
fetched_at: 2026-03-08T13:09:36.763528+00:00
source: w3c
abstract:
  This memo discusses appropriate handling of documents containing imagemapped images in cases where the user-agent cannot display or otherwise process inline images. Typical examples where this is so are (i) text-only browsers such as lynx, text-to-speech or braille browsers; (ii) graphical browsers with disabled image loading; or (iii) information-gathering robots that do not retrieve or process inlined image files.


