# drafts

name: draft-happel-structured-email-trust
rev: 04
title: Trust and security considerations for Structured Email
time: 2025-08-30T18:32:55Z
group_uri: /api/v1/group/group/2380/
expires: 2025-11-14T12:15:29Z
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-02-27T22:56:05.127597+00:00
abstract:
  This document discusses trust and security considerations for
     structured email and provides recommendations for message user agents
     on how to deal with structured data in email messages.

full_text:
  sml                                                         H.-J. Happel
  Internet-Draft                                                   audriga
  Intended status: Standards Track                          A. Gulbrandsen
  Expires: 14 November 2025                                          ICANN
                                                               13 May 2025


           Trust and security considerations for Structured Email
                   draft-happel-structured-email-trust-04

  Abstract

     This document discusses trust and security considerations for
     structured email and provides recommendations for message user agents
     on how to deal with structured data in email messages.

  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 14 November 2025.

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





  Happel & Gulbrandsen    Expires 14 November 2025                [Page 1]


  Internet-Draft                  SML Trust                       May 2025


  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
     3.  Types of security concerns  . . . . . . . . . . . . . . . . .   3
       3.1.  Spam/virus filters  . . . . . . . . . . . . . . . . . . .   3
       3.2.  Formal display of data  . . . . . . . . . . . . . . . . .   3
       3.3.  Automated processing  . . . . . . . . . . . . . . . . . .   4
       3.4.  External references . . . . . . . . . . . . . . . . . . .   4
       3.5.  Social engineering  . . . . . . . . . . . . . . . . . . .   4
     4.  Trust mechanisms  . . . . . . . . . . . . . . . . . . . . . .   5
       4.1.  Trusted senders . . . . . . . . . . . . . . . . . . . . .   5
       4.2.  Sender signatures . . . . . . . . . . . . . . . . . . . .   6
       4.3.  Domain signatures . . . . . . . . . . . . . . . . . . . .   6
       4.4.  Recipient-generated identifiers . . . . . . . . . . . . .   6
       4.5.  Secrets and related messages  . . . . . . . . . . . . . .   6
     5.  Categories of use cases . . . . . . . . . . . . . . . . . . .   7
     6.  Implementation guidelines . . . . . . . . . . . . . . . . . .   7
       6.1.  Processing structured data  . . . . . . . . . . . . . . .   7
       6.2.  Inlining data . . . . . . . . . . . . . . . . . . . . . .   7
     7.  Implementation status . . . . . . . . . . . . . . . . . . . .   8
       7.1.  Structured Email plugin for Roundcube Webmail . . . . . .   8
     8.  Security considerations . . . . . . . . . . . . . . . . . . .   8
     9.  Privacy considerations  . . . . . . . . . . . . . . . . . . .   8
     10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
     11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
       11.1.  Normative References . . . . . . . . . . . . . . . . . .   8
       11.2.  Informative References . . . . . . . . . . . . . . . . .   9
     Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .   9
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

  1.  Introduction

     Structured email, as described in [I-D.sml-structured-email], makes
     the content of some email messages machine-readable, such that user
     agents can provide higher-level functions than displaying/replying,
     for example "add this to calendar".

     Naturally, new functions bring new trust and security considerations,
     or bring new urgency to existing issues.  This document discusses
     issues related to trust and security of structured email, and
     provides advice in some cases.









  Happel & Gulbrandsen    Expires 14 November 2025                [Page 2]


  Internet-Draft                  SML Trust                       May 2025


  2.  Requirements Language

     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.

  3.  Types of security concerns

     This section gives an overview of the various types of security and
     privacy concerns that arise when email messages contain structured
     data.  The same concerns often arise for other messages, of course.

  3.1.  Spam/virus filters

     Structured email increases the syntactical and semantic complexity of
     email messages.  If a spam/virus filter parses structured email in
     order to block malevolent messages, the filter's parser will
     necessarily differ from that of the MUA that will finally act on the
     structured data, creating a risk of misclassification.

     These risks are elevated when a structured data format has complex
     syntax, syntax that offers several optional or alternative ways to
     express the same substance, and of course by parsers that deviate
     from the specification for better bug compatibiloty.

  3.2.  Formal display of data

     A common example is displaying a received calendar invitation using
     dates/times in the recipient's timezone, in a fixed format.

     Formal display introduces additional possibilities of discrepancy
     between the different representations.  For example, a single message
     might contains a multipart/alternative containing a text/plain
     description of a flight itinerary, a text/html description of the
     same itinerary, and a structured representation.  All three may be
     different, leading to confusion (and in this example, perhaps to
     missing a flight).

     Unintentional discrepancy is a risk for senders; some recipients may
     be misinformed.

     If a message is sent to a group and there is a discrepancy, different
     members of the group may see it differently.






  Happel & Gulbrandsen    Expires 14 November 2025                [Page 3]


  Internet-Draft                  SML Trust                       May 2025


     If a particular MUA displays the formal representation within the
     message, a malevolent sender could try to mimic the visual
     representation using HTML with CSS, but with misleading content.

  3.3.  Automated processing

     Automated processing covers actions that are taken as soon as the
     message arrives rather than when a human user reads the message.  For
     example, a user might want flight reservations to be automatically
     added to a travel itinerary application and/or a calendar.

     Such automation could be a custom MUA feature or a future extension
     of the Sieve email filtering language ([RFC5228]).  A related example
     for abuse in automated processing is calendar spam ([CalSpam]).

  3.4.  External references

     Email messages with a text/html body part ("HTML email messages") may
     contain image resources that link to web servers.  Such links can be
     used for tracking user interaction with the message.

     Similar concerns apply to structured data types which include image
     references, such as the cover image of a music album or the teaser
     image of a news article.

     RDF structured data can be partial by design and include references
     to additional data.  Using a "follow your nose" approach, tools can
     follow URL references to obtain further structured data concerning a
     resource.  For example, a piece of structured data about an article
     could reference the article's authors only by URL.  For a meaningful
     processing of author information, one might try to obtain further
     data using that URL.

  3.5.  Social engineering

     While the risks of social engineering are hardly new and the human-
     readable text in a message can in principle be used to persuade the
     human reader to do anything, structured data widens the variety of
     actions the human reader can easily perform.  If there are more
     buttons to click, then there's also a greater variety of attacks.

     Put differently: A user who might not be able to follow the
     instructions in a long and involved text-based social engineering
     attack may be able to follow simple instructions such as "click this
     ten that".






  Happel & Gulbrandsen    Expires 14 November 2025                [Page 4]


  Internet-Draft                  SML Trust                       May 2025


  4.  Trust mechanisms

     Several implementations of structured email restrict processing to
     messages that are particularly trusted.  That is to say, an incoming
     message is in one of these three categories:

     1.  Spam.  Structured data is not processed.

     2.  Ordinary.  Structured data is not processed.

     3.  Trusted.  Structured data is processed.

     This section gives an overview of the trust mechanisms used at the
     time of writing.

     It does not attempt to describe whether a trust-based mechanism is
     appopriate in a particular case.

     It is RECOMMENDED to restrict trust to a simple "or", rather than
     e.g. an elaborate scoring mechanism that's difficult to understand
     for users.

  4.1.  Trusted senders

     For the case of displaying remote images embedded in HTML email
     messages, MUAs often allow users to manually choose if they trust a
     certain sender.  Sometimes, addresses in the MUA's address book are
     considered trusted, or in a special list in the address book.  While
     this is mentioned in [RFC6132] and [RFC6134], this mechanism is
     currently not standardized.

     Several services manage trust centrally: trusted senders are trusted
     by the mail service rather than by the individual users.

     Some services differentiate between local mail and mail that arrived
     across the internet, and trust local mail.  In particular, one author
     has seen that attachments sent by remote senders are distrusted
     ("warning! do you really want to download this?") while attachments
     from senders within the recipient's organization are assumed to be
     benevolent.

     OPEN ISSUE: Whether this should discuss combining sender trust with
     sender/domain signatures.  Pro: A sender that has used DKIM may be
     assumed trustworthy if subsequent message also do it, less so if not.
     Contra: Isn't this what DMARC does, and best regulated only there?






  Happel & Gulbrandsen    Expires 14 November 2025                [Page 5]


  Internet-Draft                  SML Trust                       May 2025


  4.2.  Sender signatures

     Sender signatures such as PGP or S/MIME could potentially be used as
     a trust indicator.  The authors aren't aware of any concrete examples
     of this in the past, perhaps because of limited deployment.

  4.3.  Domain signatures

     DKIM defines a signature on sender domain that may be used to verify
     that a message was sent by the same sender as an earlier message.

     Some mail hosts restrict structured processing to messages with DKIM
     signatures, or to a set of senders who are identified by their DKIM
     signatures.

  4.4.  Recipient-generated identifiers

     Part of the simplicity of email is the fact that just the email
     address is required to reach out to a recipient.  This however
     requires the the recipient to discern whether a message is desirable
     or abusive.

     Recipient-generated transaction identifiers aim to pass a certain
     secret to the sender, which helps to prove legitimacy.  One such
     approach are one-time email aliases, which are generated for a single
     transaction or series of transactions.

  4.5.  Secrets and related messages

     A message may contain a secret or hard-to-guess identifier.

     A message may leverage another message's trust level by referencing
     an identifier from the other message.

     For example, a ticket sold by a concert venue may reference the
     payment transaction ID that's also mentioned in a message from the
     payment processor.  If these IDs are difficult to guess and the
     receiver trusts the payment processor, then this gives some reason to
     trust that the ticket is bona fide and could safely be added to the
     user's ticket/wallet app.

     In another example, a message with a calendar update may reference an
     identifier from the original calendar entry.  If this ID is hard to
     guess and the recipient acted on the message containing the original
     entry, then this gives some reason to trust that the change is bona
     fide.

     OPEN ISSUE: How to specify the secret.



  Happel & Gulbrandsen    Expires 14 November 2025                [Page 6]


  Internet-Draft                  SML Trust                       May 2025


     One possible solution: The leveraging message contains a
     specification of sender domain and optinal xpath query, and the MUA
     decides whether the sender is on its list.  But I don't like having
     xpath, its interop is said to be poor and a malevolent sender could
     specify something easily guessed.  For example, the messages I
     receive from a popular payment processor contain my name; an attacker
     could use an xpath query that results in my name.

     Another possible solution: The leveraging message specifies the
     sender of the leveraged message and the secret, and each MUA contains
     a hardcoded xpath query to find the ONLY kind of secret it trusts for
     that particular sender.

  5.  Categories of use cases

     Certain types of structured data might need to be kept more secure
     than others.  For instance, the structured data representation of a
     music album shared by a friend would not contain major personal
     information, while e.g., medical records or financial statements
     certainly would.

  6.  Implementation guidelines

  6.1.  Processing structured data

     MUAs SHOULD consider structured data in incoming email messages only
     if either of these criteria hold:

     *  The sender is trusted (e.g., part of the user's address book) and
        the messsage either contains a valid personal or domain signature

     *  The message is part of an ongoing thread with a trusted sender

     If none of these criteria is fulfilled, MUAs should fall back to
     alternative presentations (e.g., "text/html" or "text/plain").

     Open issue 2: Really SHOULD?  I (Arnt) don't see this guidance as
     clearly right.  It doesn't match existing code well, and doesn't seem
     to be where we want to go.

  6.2.  Inlining data

     Structured data included in an email message should be self-contained
     in order to avoid privacy problems.  This implies that if an MUA is
     able to provide meaningful user interaction (rather than mere
     display), then it should do that without loading additional
     referenced resources from the web.




  Happel & Gulbrandsen    Expires 14 November 2025                [Page 7]


  Internet-Draft                  SML Trust                       May 2025


  7.  Implementation status

     RFC Editor: before publication please remove this section and the
     reference to [RFC7942].

     This section records the status of known implementations of the
     protocol defined by this specification at the time of posting of this
     Internet-Draft, and is based on a proposal described in [RFC7942].
     The description of implementations in this section is intended to
     assist the IETF in its decision processes in progressing drafts to
     RFCs.  Please note that the listing of any individual implementation
     here does not imply endorsement by the IETF.  Furthermore, no effort
     has been spent to verify the information presented here that was
     supplied by IETF contributors.  This is not intended as, and must not
     be construed to be, a catalog of available implementations or their
     features.  Readers are advised to note that other implementations may
     exist.

     According to [RFC7942], "this will allow reviewers and working groups
     to assign due consideration to documents that have the benefit of
     running code, which may serve as evidence of valuable experimentation
     and feedback that have made the implemented protocols more mature.
     It is up to the individual working groups to use this information as
     they see fit".

  7.1.  Structured Email plugin for Roundcube Webmail

     The plugin currently uses the "trusted sender" feature of Roundcube
     to determine if structured data should be processed.

  8.  Security considerations

     Security considerations are a core subject of this document.

  9.  Privacy considerations

     Privacy considerations are a core subject of this document.

  10.  IANA Considerations

     This document has no IANA actions at this time.

  11.  References

  11.1.  Normative References






  Happel & Gulbrandsen    Expires 14 November 2025                [Page 8]


  Internet-Draft                  SML Trust                       May 2025


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

  11.2.  Informative References

     [I-D.sml-structured-email]
                "*** BROKEN REFERENCE ***".

     [RFC5228]  Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email
                Filtering Language", RFC 5228, DOI 10.17487/RFC5228,
                January 2008, <https://www.rfc-editor.org/rfc/rfc5228>.

     [RFC6132]  George, R. and B. Leiba, "Sieve Notification Using
                Presence Information", RFC 6132, DOI 10.17487/RFC6132,
                July 2011, <https://www.rfc-editor.org/rfc/rfc6132>.

     [RFC6134]  Melnikov, A. and B. Leiba, "Sieve Extension: Externally
                Stored Lists", RFC 6134, DOI 10.17487/RFC6134, July 2011,
                <https://www.rfc-editor.org/rfc/rfc6134>.

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

     [CalSpam]  "Calendar operator practices — Guidelines to protect
                against calendar abuse", n.d.,
                <https://standards.calconnect.org/csd/cc-18003.html>.

     [MachineReadable]
                "NIST IR 7511 Rev 4", n.d.,
                <https://csrc.nist.gov/glossary/term/Machine_Readable>.

  Appendix A.  Acknowledgements

     The authors wish to thank Ben Bucksch, Alexey Melnikov, Phillip Tao
     and others whose suggestions were made before this paragraph was
     started.

  Authors' Addresses





  Happel & Gulbrandsen    Expires 14 November 2025                [Page 9]


  Internet-Draft                  SML Trust                       May 2025


     Hans-Joerg Happel
     audriga
     Email: happel@audriga.com
     URI:   https://www.audriga.com


     Arnt Gulbrandsen
     ICANN
     6 Rond Point Schumann, Bd. 1
     1040 Brussels
     Belgium
     Email: arnt@gulbrandsen.priv.no
     URI:   https://icann.org/ua






































  Happel & Gulbrandsen    Expires 14 November 2025               [Page 10]


name: draft-eggert-mailmaint-uaautoconf
rev: 04
title: Automatic Configuration of Email, Calendar, and Contact Server Settings
time: 2025-09-28T23:32:52Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-01T23:32:52Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/"]
categories: ["Agent discovery/reg", "Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:05.127603+00:00
abstract:
  This document specifies an automatic configuration mechanism for
     email, calendar, and contact user agent applications.  Service
     providers publish standardized configuration information that user
     agent applications retrieve and use to simplify server setup
     procedures.

full_text:
  mailmaint                                                      D. Eggert
  Internet-Draft                                              M. Diephouse
  Intended status: Informational                                 Apple Inc
  Expires: 2 April 2026                                  29 September 2025


  Automatic Configuration of Email, Calendar, and Contact Server Settings
                    draft-eggert-mailmaint-uaautoconf-04

  Abstract

     This document specifies an automatic configuration mechanism for
     email, calendar, and contact user agent applications.  Service
     providers publish standardized configuration information that user
     agent applications retrieve and use to simplify server setup
     procedures.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 2 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
     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.




  Eggert & Diephouse        Expires 2 April 2026                  [Page 1]


  Internet-Draft    Auto-Config of Email Server Settings    September 2025


  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Document Conventions  . . . . . . . . . . . . . . . . . . . .   3
     3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     4.  JSON Configuration  . . . . . . . . . . . . . . . . . . . . .   4
       4.1.  Example . . . . . . . . . . . . . . . . . . . . . . . . .   5
       4.2.  Protocols . . . . . . . . . . . . . . . . . . . . . . . .   6
       4.3.  Authentication  . . . . . . . . . . . . . . . . . . . . .   7
       4.4.  Informational . . . . . . . . . . . . . . . . . . . . . .   7
         4.4.1.  Provider Information  . . . . . . . . . . . . . . . .   8
         4.4.2.  Help  . . . . . . . . . . . . . . . . . . . . . . . .   9
     5.  Flow  . . . . . . . . . . . . . . . . . . . . . . . . . . . .   9
       5.1.  Email Address . . . . . . . . . . . . . . . . . . . . . .  10
       5.2.  Configuration Source  . . . . . . . . . . . . . . . . . .  10
         5.2.1.  Primary Source  . . . . . . . . . . . . . . . . . . .  10
         5.2.2.  DNS MX Fallback . . . . . . . . . . . . . . . . . . .  17
       5.3.  Configuration JSON Validation . . . . . . . . . . . . . .  21
       5.4.  Selecting Protocols and Authentication  . . . . . . . . .  21
         5.4.1.  OAuth . . . . . . . . . . . . . . . . . . . . . . . .  22
         5.4.2.  HTTP Authentication Mechanisms  . . . . . . . . . . .  23
         5.4.3.  Other Protocols Authentication Mechanisms . . . . . .  24
       5.5.  Confirming Server Names . . . . . . . . . . . . . . . . .  27
       5.6.  Username  . . . . . . . . . . . . . . . . . . . . . . . .  27
       5.7.  Configuring OAuth . . . . . . . . . . . . . . . . . . . .  28
       5.8.  Configuring Password-Based Authentication . . . . . . . .  28
     6.  Configuration Validation  . . . . . . . . . . . . . . . . . .  29
       6.1.  User Approval . . . . . . . . . . . . . . . . . . . . . .  29
       6.2.  OAuth2 requirements . . . . . . . . . . . . . . . . . . .  29
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  29
       7.1.  Mistyped Domain Names . . . . . . . . . . . . . . . . . .  30
       7.2.  Attacker Controlled JSON Configuration  . . . . . . . . .  30
       7.3.  DNS . . . . . . . . . . . . . . . . . . . . . . . . . . .  31
       7.4.  Transport Security Validation . . . . . . . . . . . . . .  31
       7.5.  Updating the Configuration  . . . . . . . . . . . . . . .  32
       7.6.  Provider Information  . . . . . . . . . . . . . . . . . .  32
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  32
       8.1.  The User-Agent Auto-Configuration Protocol Registry . . .  32
         8.1.1.  Registration Template . . . . . . . . . . . . . . . .  33
         8.1.2.  Initial Registrations . . . . . . . . . . . . . . . .  33
       8.2.  Registration  . . . . . . . . . . . . . . . . . . . . . .  34
         8.2.1.  Registration of Well-Known URI
                 user-agent-configuration  . . . . . . . . . . . . . .  34
         8.2.2.  Registration of DNS Underscore Label
                 _ua-auto-config . . . . . . . . . . . . . . . . . . .  34
     9.  Normative References  . . . . . . . . . . . . . . . . . . . .  34
     Appendix A.  Configuration JSON Schema  . . . . . . . . . . . . .  39
     Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  41



  Eggert & Diephouse        Expires 2 April 2026                  [Page 2]


  Internet-Draft    Auto-Config of Email Server Settings    September 2025


     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  41

  1.  Introduction

     Manual configuration of email, calendar, and contact user agent
     applications requires users to correctly specify numerous technical
     parameters including server hostnames, port numbers, and
     authentication protocols.  This manual process frequently results in
     configuration errors and setup failures, even among technically
     skilled users.

     This document defines a mechanism that significantly simplifies this
     configuration process.  Service providers can publish standardized
     configuration data that user agents can automatically retrieve and
     use.  In most cases, users need only provide their email address and
     account password to complete the setup.

     For service providers that support the OAuth Profile for Open Public
     Clients [OAuthPublic], this mechanism also enables automatic OAuth
     configuration.  The user agent automatically determines all necessary
     details to set up OAuth authentication for the associated account.

  2.  Document Conventions

     In protocol examples, this document uses a prefix of "C: " to denote
     lines sent by the user agent to the server, and "S: " for lines sent
     by the server to the user agent.  Lines prefixed with "// " are
     comments explaining the previous protocol line.  These prefixes and
     comments are not part of the protocol.  Lines without any of these
     prefixes are continuations of the previous line, and no line break is
     present in the protocol unless specifically mentioned.

     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.

  3.  Overview

     The automatic configuration process begins when a user wants to set
     up their user agent application.  The user agent requests the user's
     email address and then uses the domain portion of that address to
     retrieve configuration data for the account.







  Eggert & Diephouse        Expires 2 April 2026                  [Page 3]


  Internet-Draft    Auto-Config of Email Server Settings    September 2025


     Configuration retrieval uses the Well-Known URIs mechanism defined in
     [RFC8615].  The specific suffix for this configuration is user-agent-
     configuration.  Section 5.2 provides detailed information about the
     retrieval process.

     The configuration is provided as a JSON document (detailed in
     Section 4) that informs the user agent about:

     *  Human-readable information about the service provider

     *  Supported protocols for this domain

     *  Server endpoints for each protocol

     *  OAuth Profile for Open Public Clients support availability

     The user agent uses this configuration to determine whether the
     provider supports protocols that the user agent can also use, helping
     decide whether to continue with the setup process.  For example, an
     email user agent might check for support of JMAP, IMAP, POP3, and
     SMTP protocols.

     Next, the user agent typically connects to the relevant services to
     verify which authentication methods they support and whether the user
     agent can use those methods.  For instance, if the user agent needs
     both IMAP and SMTP, it will connect to both servers to check their
     capabilities and confirm compatibility with the user agent's
     supported authentication mechanisms.

     Based on the available options, the user agent then proceeds with one
     of two approaches:

     1.  Continue configuration using OAuth Profile for Open Public
         Clients, or

     2.  Request the user's password for traditional authentication

     Finally, the user agent uses the obtained credentials (OAuth tokens
     or password) to connect to the servers specified in the configuration
     document and validates that the credentials work correctly with the
     desired protocols.

  4.  JSON Configuration

     The configuration document describes which services are available and
     their corresponding endpoints for a specific domain.





  Eggert & Diephouse        Expires 2 April 2026                  [Page 4]


  Internet-Draft    Auto-Config of Email Server Settings    September 2025


     The configuration file MUST conform to the JSON schema specification
     provided in Appendix A.

     The configuration uses the media type application/json.  The HTTP
     server MUST set the corresponding Content-Type header as specified in
     [RFC9110].

  4.1.  Example

     The following example demonstrates a typical JSON configuration:

     ========== NOTE: '\' line wrapping per RFC 8792 ===========

     {
         "protocols": {
             "jmap": {
                 "url": "https://jmap.example.com/session"
             },
             "imap": {
                 "host": "imap.example.com"
             },
             "pop3": {
                 "host": "pop3.example.com"
             },
             "smtp": {
                 "host": "smtp.example.com"
             },
             "caldav": {
                 "url": "https://sync.example.com/calendar/"
             },
             "carddav": {
                 "url": "https://sync.example.com/contacts/"
             }
         },
         "authentication": {
             "oauth-public": {
                 "issuer": "https://auth.example.com/"
             },
             "password": true
         },
         "info": {
             "provider": {
                 "name": "Example Provider Name",
                 "shortName": "Example",
                 "logo": [
                     {
                         "url": "https://www.example.net/logo.svg",
                         "content-type": "image/svg+xml"



  Eggert & Diephouse        Expires 2 April 2026                  [Page 5]


  Internet-Draft    Auto-Config of Email Server Settings    September 2025


                     }
                 ]
             },
             "help": {
                 "documentation": "https://help.example.net/howto/\
                     set-up-your-mail-app.html",
                 "developer": "https://developer.example.net/\
                     client-apps/",
                 "contact": ["mailto:it@team.example.net"]
             }
         }
     }

  4.2.  Protocols

     The protocols object specifies all protocols that the domain supports
     and identifies the server endpoint for each protocol.

     For the following HTTP-based protocols:

     *  JMAP defined in [RFC8620],

     *  CalDAV defined in [RFC4791], and

     *  CardDAV defined in [RFC6352]

     *  WebDAV defined in [RFC4918]

     each protocol entry MUST include a url value containing a URL with
     the https scheme.  This URL MUST specify an endpoint that serves the
     corresponding protocol.  The server MUST use the default port 443 for
     HTTPS, and the URL MUST NOT include an explicit port number.

     Hostnames in URLs MUST support Internationalized Domain Names (IDNs)
     as defined in [RFC5890] and [RFC5891].  Service providers MAY use
     either Unicode labels (u-labels) or ASCII Compatible Encoding labels
     (a-labels) in their configuration.  User agents MUST support both
     forms and handle the conversion between them as specified in
     [RFC5891].

     Example:

     "jmap": {
         "url": "https://jmap.example.com/session"
     }

     For the following text-based protocols:




  Eggert & Diephouse        Expires 2 April 2026                  [Page 6]


  Internet-Draft    Auto-Config of Email Server Settings    September 2025


     *  IMAP defined in [RFC9051],

     *  SMTP defined in [RFC5321], and

     *  POP3 defined in [RFC1939]

     *  ManageSieve defined in [RFC5804]

     each protocol entry MUST include a host value specifying the hostname
     of the server that provides the corresponding protocol.  The server
     MUST use the default port number for that protocol, with connections
     secured using TLS.  Section 5.4.3 goes into details about TLS and
     which ports to use.

     Hostnames MUST support Internationalized Domain Names (IDNs) as
     defined in [RFC5890] and [RFC5891].  Service providers MAY use either
     Unicode labels (u-labels) or ASCII Compatible Encoding labels
     (a-labels) in their configuration.  User agents MUST support both
     forms and handle the conversion between them as specified in
     [RFC5891].

     Example:

     "imap": {
         "host": "imap.mail.example.com"
     }

  4.3.  Authentication

     The authentication object specifies which authentication mechanisms
     the provider supports.

     The nested password value indicates whether the provider supports
     username and password authentication.

     The nested oauth-public object contains a single issuer value that
     specifies the authorization server's issuer identifier as defined in
     [RFC8414].  This value is a URL that uses the https scheme and has no
     query or fragment components.  User agents can use this identifier
     for authentication via [OAuthPublic].  The presence of the oauth-
     public object indicates that the provider supports OAuth.

  4.4.  Informational

     The info object contains information that user agents can present to
     users.  The only required field is info/provider/name, which SHOULD
     clearly identify the provider to the user.  The optional
     info/provider/shortName provides a shorter version of name.



  Eggert & Diephouse        Expires 2 April 2026                  [Page 7]


  Internet-Draft    Auto-Config of Email Server Settings    September 2025


     The info/provider/logo array can contain one or more entries pointing
     to the provider's logo images.  User agents can use these to display
     the provider's logo to users.

     The info/help/documentation field provides a URL that can be
     presented to users for additional information about the provider.
     The info/help/developer field contains a URL with information
     specifically for user agent developers.  The info/help/contact array
     lists URLs that users can use to contact the provider, such as mailto
     URLs.

     A minimal info example:

     "info": {
         "provider": {
             "name": "Example Provider Name"
         }
     }

  4.4.1.  Provider Information

     provider object can have name, shortName, and logo properties.

     The name and shortName values are intended for display to the user.

     The name property specifies the provider's display name, such as the
     name used in the provider's marketing materials.  It SHOULD be no
     longer than 30 characters, but MUST be no longer than 60 characters.

     The shortName property is optional.  It specifies a brief version of
     the provider's name, as commonly recognized by users.  It SHOULD be
     no longer than 12 characters, and it MUST NOT be longer than 20
     characters.

     Both name and shortName MUST NOT include any Control-characters and
     SHOULD NOT include any excessive white space.

     The logo property contains an array of provider logo variants.  User
     agents select the variant that best matches their UI requirements and
     technical constraints.

     Each object in the array contains the following properties:

     *  url - Location where the logo can be retrieved.  User agents MAY
        download the logo file during configuration and store it locally.






  Eggert & Diephouse        Expires 2 April 2026                  [Page 8]


  Internet-Draft    Auto-Config of Email Server Settings    September 2025


     *  content-type - Media type of the logo image.  This follows
        [RFC2045] media type format, specifying the main type and subtype
        without parameters.  The main media type MUST be image.

     *  width - Image width in pixels.  Optional.  Omitted for SVG files.

     *  height - Image height in pixels.  Optional.  Omitted for SVG
        files.

     The logos SHOULD at least include one of each

     *  image/svg+xml

     *  image/png with size 128 by 128

     *  image/png with size 512 by 512

     If the server provides images in the SVG format, these images MUST
     use the SVG Tiny PS Profile specified in [I-D.svg-tiny-ps-abrotman].

  4.4.2.  Help

     These fields are intended to allow a service provider to provide
     additional information about configuring user agents.

     The documentation property should link to a document intended for
     users.  It can provide additional information to users about how to
     configure their user agent.  A user agent MAY choose to display a
     link to this URL.  User agent SHOULD NOT display links with a URL
     scheme other than https.

     The developer property should link to a document intended for user
     agent developers.  The document this URL links to can provide
     additional information to the developer.

     The contact property should provide a way for user agent developers
     to contact the service providers.  It is _not_ intended as a way for
     users to contact the service provider.  User agents MUST NOT display
     this link in their user interface.  This URL would typically be a
     mailto URL or a URL linking to a contact form for developers to use.

  5.  Flow

     Section 3 provides a high-level overview of the automatic
     configuration process.  This section details the individual steps
     involved in this process.





  Eggert & Diephouse        Expires 2 April 2026                  [Page 9]


  Internet-Draft    Auto-Config of Email Server Settings    September 2025


  5.1.  Email Address

     During the initial configuration process, the user agent requests the
     user's email address.  User agents SHOULD accept any valid mailbox
     format as specified in Section 3.4 of [RFC5322].

  5.2.  Configuration Source

     After the user provides their email address, the user agent extracts
     the domain part of the user's email address according to
     Section 3.4.1 of [RFC5322].  For example:

             +================================+=================+
             | Text Entered by User           | domain          |
             +================================+=================+
             | jdoe@foo.example.com           | foo.example.com |
             +--------------------------------+-----------------+
             | "J Doe" <jdoe@foo.example.com> | foo.example.com |
             +--------------------------------+-----------------+
             | <jdoe@foo.example.com>         | foo.example.com |
             +--------------------------------+-----------------+

                      Table 1: Domain from email address

     This domain is then used to retrieve the JSON configuration resource.

     There are two methods for retrieving the JSON configuration: a
     primary method and an MX fallback method.  The primary method should
     be attempted first, with the MX fallback method used only if the
     primary method fails.

  5.2.1.  Primary Source

     The primary method for retrieving configuration data uses well-known
     URIs with DNS-based digest validation.

  5.2.1.1.  Well-Known Uniform Resource Identifier

     The user agent retrieves configuration data over HTTP using the
     format described in Section 4.

     Configuration retrieval uses [RFC8615] Well-Known URIs.  The user
     agent constructs the URI using the _domain_ from the user's email
     address and the _configuration name_ user-agent-configuration.  The
     detailed URI construction process is specified in [RFC8615].






  Eggert & Diephouse        Expires 2 April 2026                 [Page 10]


  Internet-Draft    Auto-Config of Email Server Settings    September 2025


     The domain name MUST support Internationalized Domain Names (IDNs) as
     defined in [RFC5890] and [RFC5891].  User agents MUST handle both
     Unicode labels (u-labels) and ASCII Compatible Encoding labels
     (a-labels) when processing domain names from email addresses, and
     convert them appropriately for URI construction as specified in
     [RFC5891].

     The URI follows this template:

     ========== NOTE: '\' line wrapping per RFC 8792 ===========

     https://ua-auto-config.{domain}/\
       .well-known/user-agent-configuration.json

     If the user's email address' domain is foo.example.com, the user
     agent constructs the following URI:

     ========== NOTE: '\' line wrapping per RFC 8792 ===========

     https://ua-auto-config.foo.example.com/\
       .well-known/user-agent-configuration.json

     This URI always uses the https scheme.  User agents MUST retrieve the
     configuration file only via https (HTTP over TLS).

     The user agent MUST validate that the connection is secured by TLS.
     See Section 7.4 for details about TLS with respect to retrieving the
     configuration.

     The media type of the configuration is application/json, and the HTTP
     server MUST set a corresponding Content-Type type header.  See
     [RFC9110].  The user agent MUST validate that the content-type of the
     returned resource is application/json.

     The HTTP server that serves the JSON configuration MUST NOT require
     any form of HTTP authentication to return the configuration.

     For example:













  Eggert & Diephouse        Expires 2 April 2026                 [Page 11]


  Internet-Draft    Auto-Config of Email Server Settings    September 2025


     C: GET /.well-known/user-agent-configuration.json HTTP/2
     C: Host: foo.example.com
     C: user-agent: curl/8.4.0
     C: accept: application/json
     C:

     S: HTTP/2 200
     S: server: nginx/1.25.3
     S: date: Mon, 23 Oct 2025 10:30:00 GMT
     S: content-type: application/json
     S: content-length: 1184
     S:
     S: {
     S:     "protocols": {
     S:         "jmap": {
     S: ...

  5.2.1.2.  DNS-Based Digest Validation

     After retrieving the auto-configuration resource from the well-known
     URI as described in Section 5.2.1.1, the user agent MUST validate its
     integrity before use.  This validation is performed by comparing a
     locally computed digest of the resource against a digest published in
     a DNS TXT resource record (RR).

     If the validation fails, the user agent MUST ignore the auto-
     configuration resource.

  5.2.1.2.1.  Validation Procedure

     The user agent MUST perform the following steps to validate the auto-
     configuration resource:

     1.  Let the "decoded message content" be the payload body of the HTTP
         response after all Transfer-Encoding (e.g., "chunked") and
         Content-Encoding (e.g., "gzip", "br") transformations have been
         reversed.  This is the final, decompressed representation of the
         resource.  See Section 6.1 of [RFC9112] and Section 8.4 of
         [RFC9110] for details on these encodings.

     2.  Construct a DNS query QNAME using the template _ua-auto-
         config.{domain}, where {domain} is the domain part of the user's
         identifier (e.g., "foo.example.com" for "jdoe@foo.example.com").

     3.  Perform a DNS query for the TXT RR type at the constructed QNAME.
         The response may contain multiple TXT RRs.

     4.  For each TXT RR returned in the DNS response:



  Eggert & Diephouse        Expires 2 April 2026                 [Page 12]


  Internet-Draft    Auto-Config of Email Server Settings    September 2025


         a.  Parse the record according to the syntax in
             Section 5.2.1.2.2.  If the record is malformed or is missing
             any of the mandatory tags (v, a, d), discard this RR and
             proceed to the next one.

         b.  Let the "remote algorithm" be the value of the a tag.  If the
             user agent does not support this algorithm, discard this RR
             and proceed to the next one.

         c.  Let the "remote digest" be the Base64-decoded value of the d
             tag.  If decoding fails, discard this RR and proceed to the
             next one.

         d.  Using the "remote algorithm", compute a "local digest" of the
             "decoded message content" obtained in step 1.

         e.  Perform a byte-for-byte comparison of the "local digest" and
             the "remote digest".  If they are identical, the validation
             is successful.  The user agent MUST immediately stop
             processing further TXT RRs and MAY use the auto-configuration
             resource.

     5.  If, after checking all valid and supported TXT RRs, no match is
         found, the validation has failed.  The user agent MUST discard
         the "decoded message content" and behave as if no auto-
         configuration resource was found.

     Note: A compliant HTTP client library will typically handle the
     decoding of Transfer-Encoding and Content-Encoding transparently.
     The requirement in this document is to ensure that the digest is
     computed on the final data, not on an intermediate, encoded
     representation.

  5.2.1.2.2.  DNS Resource Record for Auto-Configuration

     Configuration information for a given domain is published as a DNS
     TXT resource record (RR) at a special name, _ua-auto-config,
     prepended to the domain name.  For example, for the domain
     example.com, the lookup would be for a TXT record at _ua-auto-
     config.example.com.

  5.2.1.2.2.1.  Record Syntax

     The content of the TXT RR is a string of tag=value pairs separated by
     semicolons (;).  Tags are short ASCII strings that identify a
     particular parameter.  Values are ASCII strings whose format depends
     on the tag.




  Eggert & Diephouse        Expires 2 April 2026                 [Page 13]


  Internet-Draft    Auto-Config of Email Server Settings    September 2025


     The formal syntax of the record is described using ABNF [RFC5234] as
     follows:

     config-record   = tag-value *( *WSP ";" *WSP tag-value ) *WSP [";"]

     tag-value       = version-tag / alg-tag / digest-tag / future-tag

     version-tag     = "v" *WSP "=" *WSP "UAAC1"
     alg-tag         = "a" *WSP "=" *WSP digest-algorithm
     digest-algorithm = "sha256" / "sha512" / "sha3-512"
     digest-tag      = "d" *WSP "=" *WSP 1*base64-char

     future-tag      = 1*tag-name *WSP "=" *WSP 1*tag-value-char

     tag-name        = ALPHA / DIGIT
     tag-value-char  = %x21-3A / %x3C-7E ; Any visible ASCII char
                                       ; except semicolon

     base64-char     = ALPHA / DIGIT / "+" / "/" / "="
     ; As defined in Section 4 of RFC 4648

     WSP             = " " / HTAB
     ; As defined in Appendix B.1 of RFC 5234

  5.2.1.2.2.2.  Tags

     The following tags are defined.  Tag names are case-sensitive and
     MUST be processed as lowercase.

        +-----+------------------------------------------+-----------+
        | Tag | Description                              | Status    |
        +-----+------------------------------------------+-----------+
        | v   | Version.  The value MUST be "UAAC1" for  | Mandatory |
        |     | records compliant with this              |           |
        |     | specification.                           |           |
        +-----+------------------------------------------+-----------+
        | a   | Digest Algorithm.  The value MUST be one | Mandatory |
        |     | of "sha256", "sha512", or "sha3-512".    |           |
        |     | This identifies the algorithm used to    |           |
        |     | create the digest in the 'd' tag.        |           |
        +-----+------------------------------------------+-----------+
        | d   | Digest.  The Base64-encoded digest of    | Mandatory |
        |     | the JSON resource described in           |           |
        |     | Section 5.2.1.1.  The encoding MUST      |           |
        |     | follow Section 4 of [RFC4648].           |           |
        +-----+------------------------------------------+-----------+

                            Table 2: Defined Tags



  Eggert & Diephouse        Expires 2 April 2026                 [Page 14]


  Internet-Draft    Auto-Config of Email Server Settings    September 2025


  5.2.1.2.2.3.  Digest Algorithm

     Three digest algorithms are supported:

     *  SHA-256 ("sha256") as defined in [RFC6234]

     *  SHA-512 ("sha512") as defined in [RFC6234]

     *  SHA-3-512 ("sha3-512") as defined in [RFC8702]

     The digest is computed over the raw bytes of the JSON resource
     retrieved from the well-known URI, after any HTTP transfer or content
     encoding has been decoded.

     Servers MUST publish DNS records for both SHA-256 and SHA-512
     algorithms.  Servers MAY additionally publish records using SHA-
     3-512.

  5.2.1.2.2.4.  Parsing Rules

     A client parsing the record MUST adhere to the following rules:

     *  The record MUST contain the v, a, and d tags.  If any of these
        tags are missing, the record is invalid and MUST be ignored.

     *  The order of the tags is not significant.

     *  Whitespace (WSP) is permitted on either side of the = and ;
        separators and MUST be ignored.

     *  If a tag is encountered that is not defined in this document
        (e.g., a tag from a future version), the parser MUST ignore that
        entire tag=value pair.  This allows for future extensions.

     *  If any of the mandatory tags (v, a) have values other than those
        specified in this document, the record is invalid and MUST be
        ignored.

  5.2.1.2.3.  Primary Source Example

     This example demonstrates the primary configuration retrieval process
     for a user with email address user@example.com.

     The user agent performs the following steps:

     1.  Constructs the well-known URI from the email domain:





  Eggert & Diephouse        Expires 2 April 2026                 [Page 15]


  Internet-Draft    Auto-Config of Email Server Settings    September 2025


        ========== NOTE: '\' line wrapping per RFC 8792 ===========

        https://ua-auto-config.example.com/\
          .well-known/user-agent-configuration.json

     2.  Retrieves the JSON configuration over HTTPS and receives:

        {
            "protocols": {
                "jmap": {
                    "url": "https://jmap.example.com/session"
                },
                "imap": {
                    "host": "imap.example.com"
                },
                "smtp": {
                    "host": "smtp.example.com"
                }
            },
            "authentication": {
                "oauth-public": {
                    "issuer": "https://auth.example.com/"
                },
                "password": true
            },
            "info": {
                "provider": {
                    "name": "Example Provider"
                }
            }
        }

     3.  Queries DNS for TXT record at _ua-auto-config.example.com and
         receives:

        ========== NOTE: '\' line wrapping per RFC 8792 ===========

        _ua-auto-config.example.com.    TXT    "v=UAAC1; a=sha256; \
          d=K7gNU3sdo+OL0wNhqoVWhr3g6s1xYv72ol/pe/Unols="

     4.  Computes the SHA-256 digest of the retrieved JSON configuration
         and verifies it matches the digest in the DNS TXT record.

     5.  Since validation succeeds, the user agent may proceed to use this
         configuration for account setup.






  Eggert & Diephouse        Expires 2 April 2026                 [Page 16]


  Internet-Draft    Auto-Config of Email Server Settings    September 2025


  5.2.2.  DNS MX Fallback

     If the user agent is unable to retrieve a configuration from the
     well-known URL described in Section 5.2.1, the user agent MUST
     attempt to construct URLs for the configuration resource using DNS MX
     records as described in this section.

     Conversely, if the user agent was able to retrieve a configuration
     from the well-known URL described in Section 5.2.1, the user agent
     MUST NOT perform the fallback described in this section.

     This fallback mechanism allows user agents to discover configuration
     information when the primary method fails, using the email domain's
     MX records to identify alternative sources for the auto-configuration
     resource.

  5.2.2.1.  MX Fallback Procedure

     The user agent MUST perform the following steps to retrieve
     configuration using MX records:

     1.  Verify that the email domain supports MTA Strict Transport
         Security as described in Section 5.2.2.2.  If MTA STS is not
         supported, MUST abort the MX fallback process.

     2.  Perform a DNS query for MX resource records for the email domain.

     3.  Identify all MX records that share the same highest priority
         (lowest numerical value).  For example, if the MX records have
         priorities 10, 10, and 20, the highest priority MX records are
         those with priority 10.

     4.  For each MX record identified in the previous step:

         a.  Construct a well-known URI based on the MX hostname as
             described in Section 5.2.2.3.

         b.  Retrieve the JSON auto-configuration resource from the
             constructed URI.

         c.  Validate the retrieved resource using DNS-based digest
             validation as described in Section 5.2.1.2, but using the DNS
             query name _ua-auto-config.{mx-hostname} where {mx-hostname}
             is the hostname from the MX record.







  Eggert & Diephouse        Expires 2 April 2026                 [Page 17]


  Internet-Draft    Auto-Config of Email Server Settings    September 2025


     5.  Verify that all successfully retrieved and validated
         configurations are bitwise identical.  If any configurations
         differ, the user agent MUST reject all configurations and treat
         the MX fallback as failed.

     6.  If at least one configuration was successfully retrieved and
         validated, and all retrieved configurations are identical, the
         user agent MAY use this configuration.

  5.2.2.2.  MTA Strict Transport Security

     MTA Strict Transport Security (MTA STS) defined in [RFC8461] provides
     a way to validate MX records against a resource retrieved over HTTP
     with TLS.

     The user agent MUST validate that the email domain supports the MTA
     STS profile.  If the email domain does not support MTA STS, the user
     agent MUST NOT use any MX records to perform auto-configuration.

     When performing the HTTPS Policy Fetching outlined in Section 3.3 of
     [RFC8461], the user agent MUST use the same, strict TLS checks as for
     the auto-configuration JSON resource.  See Section 7.4 of this
     document for detail.

  5.2.2.3.  MX-Based Well-Known URI

     The user agent constructs a Well-Known URI based on the MX hostname
     using this template:

     ========== NOTE: '\' line wrapping per RFC 8792 ===========

     https://ua-auto-config.{mx-hostname}/\
       .well-known/user-agent-configuration.json

     For the MX hostname bar.mail.example.com, the user agent constructs
     the following URI:

     ========== NOTE: '\' line wrapping per RFC 8792 ===========

     https://ua-auto-config.bar.mail.example.com/\
       .well-known/user-agent-configuration.json

     This URI construction follows the same pattern as described in
     Section 5.2.1.1, but uses the MX hostname instead of the email
     domain.  The user agent MUST apply the same TLS validation
     requirements as specified in Section 7.4.





  Eggert & Diephouse        Expires 2 April 2026                 [Page 18]


  Internet-Draft    Auto-Config of Email Server Settings    September 2025


  5.2.2.4.  MX Fallback Example

     This example demonstrates the MX fallback process for a user with
     email address user@example.com.

     First, the user agent attempts to retrieve the configuration from the
     primary well-known URI:

     ========== NOTE: '\' line wrapping per RFC 8792 ===========

     https://ua-auto-config.example.com/.well-known/\
      user-agent-configuration.json

     but this fails (perhaps the server is unreachable or returns an
     error).

     The user agent then begins the MX fallback process:

     1.  The user agent verifies MTA STS support:

         a.  Queries DNS for a TXT record at _mta-sts.example.com and
             receives:

            _mta-sts.example.com.    TXT    "v=STSv1; id=20240101120000;"

         b.  Retrieves the MTA STS policy from https://mta-
             sts.example.com/.well-known/mta-sts.txt and receives:

            version: STSv1
            mode: enforce
            mx: mail1.example.com
            mx: mail2.example.com
            mx: *.backup.example.com
            max_age: 604800

         c.  Queries DNS for MX records for example.com and receives:

            example.com.    MX    10 mail1.example.com.
            example.com.    MX    10 mail2.example.com.
            example.com.    MX    20 backup.example.com.

         d.  Validates that the MX records are consistent with the MTA STS
             policy.  All MX hostnames (mail1.example.com,
             mail2.example.com, and backup.example.com) match entries in
             the policy, so MTA STS validation succeeds.






  Eggert & Diephouse        Expires 2 April 2026                 [Page 19]


  Internet-Draft    Auto-Config of Email Server Settings    September 2025


     2.  The user agent identifies that mail1.example.com and
         mail2.example.com both have the highest priority (10), so these
         are the MX records to process for auto-configuration.

     3.  For each highest priority MX record:

         *  For mail1.example.com:

            -  Constructs URI:

               ========== NOTE: '\' line wrapping per RFC 8792 ===========

               https://ua-auto-config.mail1.example.com/\
                .well-known/user-agent-configuration.json

            -  Retrieves the JSON configuration successfully

            -  Validates the configuration against DNS TXT record at _ua-
               auto-config.mail1.example.com

         *  For mail2.example.com:

            -  Constructs URI:

               ========== NOTE: '\' line wrapping per RFC 8792 ===========

               https://ua-auto-config.mail2.example.com/\
                .well-known/user-agent-configuration.json

            -  Retrieves the JSON configuration successfully

            -  Validates the configuration against DNS TXT record at _ua-
               auto-config.mail2.example.com

     4.  The user agent verifies that both retrieved configurations are
         bitwise identical.

     5.  Since both configurations were successfully retrieved, validated,
         and are identical, the user agent may proceed to use this
         configuration for account setup.

     If any step in this process fails (MTA STS not supported, MX records
     don't match the MTA STS policy, no MX records found, configurations
     differ, or validation fails), the user agent treats the MX fallback
     as unsuccessful and may need to prompt the user for manual
     configuration.





  Eggert & Diephouse        Expires 2 April 2026                 [Page 20]


  Internet-Draft    Auto-Config of Email Server Settings    September 2025


  5.3.  Configuration JSON Validation

     After successfully retrieving a configuration resource, user agents
     MUST validate that the configuration contains valid JSON syntax
     according to RFC 8259.  Additionally, user agents MUST validate the
     retrieved configuration against the JSON schema specification
     provided in Appendix A.  If the JSON syntax is invalid, user agents
     MUST ignore the configuration entirely and not use any portion of it.

     User agents MUST process only the properties that they support and
     MUST ignore properties not specified in the schema.  This requirement
     enables future extensions of the format without breaking existing
     user agent implementations.

  5.4.  Selecting Protocols and Authentication

     After successfully retrieving and validating the configuration JSON,
     the user agent needs to determine:

     *  Which protocols to use

     *  Which authentication mechanism to employ

     Both user agents and servers support multiple protocols.  The user
     agent needs to decide which protocols to use and determine whether
     the protocols specified in the configuration are sufficient to
     proceed.  This document does not provide recommendations regarding
     protocol preferences or minimum protocol requirements, as these
     decisions depend on the specific needs and implementation details of
     individual user agents.

     The automatic configuration flow supports two distinct authentication
     types:

     *  Username and password-based authentication

     *  OAuth-based authentication

     User agents can support one or both authentication methods.
     Similarly, servers for each protocol can support one or both methods.
     Additionally, the specific implementation details of authentication
     can vary between protocols.

     User agents SHOULD probe each protocol and server of interest to
     determine compatible authentication methods.  This probing process
     can influence the user agent's protocol selection and allows the user
     agent to verify server availability.




  Eggert & Diephouse        Expires 2 April 2026                 [Page 21]


  Internet-Draft    Auto-Config of Email Server Settings    September 2025


     This document does not provide recommendations regarding protocol
     preferences.  The user agent MUST make these decisions based on its
     needs.

     If the user agent determines that it can use either password-based
     authentication or OAuth authentication, the user agent SHOULD prefer
     OAuth-based authentication.

  5.4.1.  OAuth

     The JSON configuration includes an oauth-public entry when the
     provider supports OAuth.  The issuer value specifies the
     authorization server's issuer identifier.  According to Section 2.2
     of [OAuthPublic], the OAuth Authorization Server Metadata is served
     at a URL constructed using this issuer value with the template

     {issuer}/.well-known/oauth-authorization-server

     For example, if the JSON configuration contains this entry:

     "oauth-public" : {
         "issuer" : "https://auth.example.com"
     },

     the OAuth Authorization Server Metadata would be at the URL
     https://auth.example.com/.well-known/oauth-authorization-server

     Note that as defined in [RFC8414], the authorization server's issuer
     identifier MUST be a URL that uses the https scheme without any query
     or fragment components.  Clients MUST verify that the issuer value is
     valid according to [RFC8414].

     Before the user agent chooses to use OAuth for any protocols, it
     SHOULD make sure that it can retrieve the OAuth Authorization Server
     Metadata from the corresponding URI.

     The user agent SHOULD connect to each protocol that it might be
     interested in to detect which authentication mechanism it supports.
     The user agent MUST NOT perform any authentication at this point, but
     it SHOULD record which mechanism(s) the server for each protocol of
     interest supports.

     The user agent SHOULD still probe each server as described in the
     next sections 5.4.2 and 5.4.3 to check that the servers it is
     interested in have OAuth support.






  Eggert & Diephouse        Expires 2 April 2026                 [Page 22]


  Internet-Draft    Auto-Config of Email Server Settings    September 2025


  5.4.2.  HTTP Authentication Mechanisms

     To check which HTTP authentication schemes a particular HTTP server
     supports, the user agent SHOULD send a request to the server's
     endpoint without any Authorization header.  For example:

     GET /jmap/session HTTP/1.1
     host: api.example.com
     accept: application/json

     As detailed in [RFC9110] the server SHOULD respond to this with a 401
     Unauthorized status code and a www-authenticate response header
     indicating which authentication scheme(s) are supported.

     The user agent SHOULD include an accept header with the content type
     it would expect for the given protocol.  For JMAP, for example, the
     user agent SHOULD include accept: application/json as a header in
     this request.

     If the server supports OAuth, the www-authenticate response header
     would include Bearer.  [RFC6749] describes this in more detail.
     [RFC6750] and [RFC7616] describe username + password authentication
     using the so-called 'Basic' HTTP authentication scheme and the HTTP
     digest access authentication respectively.  Other password based
     authentication mechanisms exist for HTTP, but their discussion is
     outside the scope of this document.

     For example, a response header

     HTTP/1.1 401 Unauthorized
     www-authenticate: Bearer realm="api.example.com"

     would indicate that the server supports OAuth.

     Alternatively, a response such as

     ========== NOTE: '\' line wrapping per RFC 8792 ===========

     HTTP/1.1 401 Unauthorized
     www-authenticate: Digest realm="api.example.com", qop="auth", \
     algorithm=SHA-256, nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", \
     opaque="5ccc069c403ebaf9f0171e9517f40e41"

     would indicate that the server supports digest access authentication.







  Eggert & Diephouse        Expires 2 April 2026                 [Page 23]


  Internet-Draft    Auto-Config of Email Server Settings    September 2025


     Details of HTTP authentication are described in [RFC9110] but it is
     worth noting that a server supporting multiple authentication methods
     can return either multiple www-authenticate header fields in its
     response or a single www-authenticate header field with multiple
     authentication methods.

  5.4.3.  Other Protocols Authentication Mechanisms

     For text-based protocols (IMAP, POP3, and SMTP) the user agent SHOULD
     connect to the server to check that:

     *  the user agent can reach the server,

     *  the server implements the expected protocol, and

     *  which authentication mechanisms the server supports.

     The user agent MUST attempt to connect to the server on the default
     ports:

     *  port 993 for IMAP

     *  port 995 for POP3

     *  port 465 for SMTP

     using TLS.  See [RFC2595] and [RFC3207] for details about using TLS
     with these protocols.

     The user agent SHOULD NOT attempt to connect to an IMAP, POP3, or
     SMTP server on their cleartext ports.

     The user agent MUST NOT allow for configuration with a cleartext
     protocol that is not protected by TLS.

     The user agent MUST validate that the connection is secured by TLS,
     and that the server certificate is valid and matches the expected
     domain name.  See Section 7.4 for details on transport security
     validation.

     If the server announces the OAUTHBEARER SASL authentication method,
     the user agent can assume that this server supports using
     [OAuthPublic].  For IMAP for example, if the server's CAPABILITY
     contains AUTH=OAUTHBEARER this would indicate this support.







  Eggert & Diephouse        Expires 2 April 2026                 [Page 24]


  Internet-Draft    Auto-Config of Email Server Settings    September 2025


     Servers SHOULD NOT announce support for the OAUTHBEARER SASL
     mechanism if they do not support [OAuthPublic].  Servers MUST
     announce support for the OAUTHBEARER SASL mechanism if they support
     OAuth Profile for Open Public Clients.  Servers SHOULD NOT use the
     XOAUTH2 SASL mechanism.

     There are various SASL authentication mechanisms for password-based
     authentication, and additionally IMAP and POP3 also support password-
     based authentication through LOGIN and APOP respectively.  The user
     agent needs to probe each server to determine which authentication
     methods are supported by both the user agent and the server.

  5.4.3.1.  IMAP

     The IMAP protocol provides various other authentication mechanisms.
     There are various SASL mechanisms for username + password
     authentication.  [RFC4959] describes how to use SASL with IMAP.

     Unless the server sends the LOGINDISABLED capability, clients know
     that they can use the LOGIN command for username + password
     authentication.

     For IMAP, a sample session might look like this:

     ========== NOTE: '\' line wrapping per RFC 8792 ===========

     S: * OK [CAPABILITY IMAP4 IMAP4rev1 SASL-IR AUTH=PLAIN \
     AUTH=OAUTHBEARER] IMAP Server
     C: A1 LOGOUT
     S: * BYE
     S: A1 OK

     In this case the server returned its IMAP capabilities as part of the
     so-called greeting messages.  The support for the OAUTHBEARER SASL
     authentication mechanism indicates to the client that the server
     supports OAuth.  Similarly the PLAIN SASL authentication mechanism
     indicates that the server supports username + password
     authentication.  The absence of the LOGINDISABLED also indicates
     support for username and password authentication.

     If the server doesn't include its capabilities in the server
     greeting, the client SHOULD send a CAPABILITY command as outlined in
     Section 6.1.1 of [RFC9051].  The client SHOULD send a LOGOUT command
     as outlined in Section 6.1.3 of [RFC9051] and check that the server
     sends an untagged BYE response.






  Eggert & Diephouse        Expires 2 April 2026                 [Page 25]


  Internet-Draft    Auto-Config of Email Server Settings    September 2025


  5.4.3.2.  SMTP

     SMTP similarly announces which authentication mechanisms is supports.
     [RFC4954] describes how to use SASL with SMTP.

     For SMTP, the client would use the EHLO command to retrieve the SMTP
     server's supported authentication mechanisms.  For example:

     S: 220 smtp.example.com ESMTP service ready
     C: EHLO client.example.com
     S: 250-smtp.example.com
     S: 250-PIPELINING
     S: 250-SIZE 10240000
     S: 250-AUTH PLAIN LOGIN OAUTHBEARER
     S: 250-ENHANCEDSTATUSCODES
     S: 250 8BITMIME
     C: QUIT
     S: 221 Bye

     Section 3.2 of [RFC5321] describe this client initiation of the SMTP
     protocol.  [RFC4954] describes SMTP authentication in detail.  In the
     above example PLAIN and LOGIN indicate that the server supports
     username + password based authentication, and OAUTHBEARER indicates
     that the server supports OAuth.

     The client SHOULD send a QUIT command and check for the server's 221
     Bye response.

  5.4.3.3.  POP3

     For POP3 [RFC5034] describes how to use SASL.  POP3 additionally
     supports password based authentication using its USER and PASS
     commands, or through the optional APOP command.  The client can check
     which SASL authentication methods the server supports using the CAPA
     command.

     For example:

     S: +OK pop.example.com POP3 server ready
     C: CAPA
     S: +OK List of capabilities follows
     S: SASL PLAIN OAUTHBEARER
     S: IMPLEMENTATION BlurdyBlurp POP3 server
     S: .
     C: QUIT
     S: +OK POP3 server signing off (maildrop empty)





  Eggert & Diephouse        Expires 2 April 2026                 [Page 26]


  Internet-Draft    Auto-Config of Email Server Settings    September 2025


     The client SHOULD send a QUIT command and check for the server's +OK
     response.

  5.5.  Confirming Server Names

     The client SHOULD display to the user the hostnames of all servers
     that it intends to authenticate with.  This list of server hostnames
     gives the user a chance to validate if they want to move ahead.

     The client MAY choose to limit the hostnames to their second-level
     domain names when displaying this list.  Instead of displaying
     mail.example.com the client would display example.com if it chooses
     to do so.  Limiting the hostnames to their second-level domain names
     helps users identify if this is the domain they intend to connect to
     or not.

     The client MUST NOT cut off parts of long second-level domains, to
     avoid spoofing.  At least 63 characters of the second-level domain
     names MUST be displayed.

     If the user mistyped their email address in Section 5.1, letting the
     user confirm the server hostnames gives the user a chance to notice
     this.

     Clients can enhance the user experience by using the info section of
     the configuration (described in Section 4.4) to display the
     provider's name and logo during this configuration step.

     Section 7.1 list security considerations related to the user
     confirming these hostnames.

  5.6.  Username

     For password-based authentication, the full addr-spec part of the
     email address MUST be used as the username.  For example:

               +============================+==================+
               | Text Entered by User       | username         |
               +============================+==================+
               | jdoe@example.com           | jdoe@example.com |
               +----------------------------+------------------+
               | "J Doe" <jdoe@example.com> | jdoe@example.com |
               +----------------------------+------------------+
               | <jdoe@example.com>         | jdoe@example.com |
               +----------------------------+------------------+

                      Table 3: Username from email address




  Eggert & Diephouse        Expires 2 April 2026                 [Page 27]


  Internet-Draft    Auto-Config of Email Server Settings    September 2025


     For OAuth Profile for Open Public Clients, the client MUST send this
     username as the login_hint in the authorization request URL.

     The provider MUST ensure that any valid email address that the user
     might enter during setup is a valid username for all servers given in
     this configuration.  This will require a mapping on the server level
     from email address to internal username.  This mapping happens
     internally in the server and the client is not involved in this
     mapping.

  5.7.  Configuring OAuth

     If the client and the provider both support OAuth Profile for Open
     Public Clients, and if the servers that the client wants to use
     support OAuth, the client can configure OAuth.

     The authentication section in the JSON configuration described in
     Section 4.3 will let the client create a URL to retrieve the OAuth
     Authorization Server Metadata as described in section Section 5.4.1.
     With this metadata, the client can then use [OAuthPublic] to
     configure OAuth.

     Part of this will require opening the authorization request URL in an
     external user-agent, which is typically the default browser.  The
     client SHOULD make it very apparent to the user which hostname is
     being used for the authorization request URL.  The client SHOULD make
     the user confirm least the second-level domain name(s) of the
     hostname of this URL.  This is to minimize the risk of the user
     exposing their credentials to a third party.

     As described in Section 5.5, the client SHOULD also confirm the
     server hostnames with the user.  For OAuth authentication, the client
     SHOULD include the hostname of the authorization request URL in this
     list of hostnames.

  5.8.  Configuring Password-Based Authentication

     If the client and provider both support password-based
     authentication, and if the servers that the client wants to use
     support password-based authentication, the client can configure
     itself to use these servers.

     The client SHOULD at this point ask the user for the password for
     their account with the provider.







  Eggert & Diephouse        Expires 2 April 2026                 [Page 28]


  Internet-Draft    Auto-Config of Email Server Settings    September 2025


     Once the user has entered their password, the client SHOULD validate
     that it is able to authenticate using the entered password with all
     servers that it is interested in.  Only then would it save the new
     configuration.

  6.  Configuration Validation

  6.1.  User Approval

     Regardless of the mechanism used to obtain the configuration, clients
     SHOULD display the configuration details to users and request
     explicit confirmation before use.  During this confirmation process:

     *  At least the second-level domain names of all involved hostnames
        MUST be displayed clearly and prominently.

     *  Clients MUST NOT truncate long second-level domain names to
        prevent spoofing attacks.  At least 63 characters MUST be
        displayed.

  6.2.  OAuth2 requirements

     If OAuth2 is used, the OAuth2 server MUST adhere to [OAuthPublic].

     Notably, the Dynamic Client Registration MUST be implemented and
     return a working Client ID in response HTTP calls defined by the
     specification.

     The OAuth2 scopes defined in [OAuthPublic] MUST be included and MUST
     give access to the servers returned in the JSON configuration
     described in Section 4.

     A single token MUST work for all servers in the JSON configuration,
     such that a single user login is sufficient for all services.  For
     that purpose, the client will include all relevant scopes in the
     authentication requests.

  7.  Security Considerations

     While the mechanism described in this document makes it easier for
     users to correctly configure their user agent, there's an associated
     risk with making it easier for users to expose their credentials to a
     third party.

     User agents using the mechanism described in this document need to
     design their user interface and user experience such that this risk
     is minimized.  Actual affordances depend on implementation details of
     the user interface and are outside the scope of this document.



  Eggert & Diephouse        Expires 2 April 2026                 [Page 29]


  Internet-Draft    Auto-Config of Email Server Settings    September 2025


  7.1.  Mistyped Domain Names

     As part of the first step of the mechanism described in this
     document, the user enters their email address.  If the user mistyped
     the domain part of their email address, and if the mistyped domain
     exists and supports the mechanism described in this document, the
     user could expose their credentials to the owner of that domain.  An
     attacker could use this in an attempt to gain knowledge of the user's
     credentials.

     As a result, user agents need to carefully design their user
     interface and user experience as to let the user know which domain is
     being used.  It would make sense to display this very clearly to the
     user, before they enter any credentials.

     The user agent would want to display a list of all second-level
     domains (SLDs) for all the servers that it intends to use.  The user
     can then confirm these.

     When the mechanism described in this document uses OAuth, it would
     make sense to ask the user to confirm the domains of the servers that
     will be used and additionally confirm the domains of

     *  the URL to retrieve the OAuth Authorization Server Metadata and/or

     *  the authorization request URL.

     When asking the user to confirm these domains, it would make sense to
     only display the second-level domain (SLD) of those domains.  This
     would make it more difficult for an attacker to do URL obfuscation
     and use subdomain phishing.

     When using a browser for OAuth, the user agent would want to display
     the second-level domain (SLD) that the browser is currently
     displaying, and update this when redirects happen or new pages are
     loaded.

  7.2.  Attacker Controlled JSON Configuration

     If an attacker can direct the user agent to use an attacker-
     controlled JSON configuration, the attacker would be able to direct
     the user to servers of the attacker's choosing.

     In Section 7.1 some mechanisms to limit this attack vector are
     described.

     However, the user agent needs to combine this with a conservative
     trust policy for its TLS when retrieving the JSON configuration.



  Eggert & Diephouse        Expires 2 April 2026                 [Page 30]


  Internet-Draft    Auto-Config of Email Server Settings    September 2025


  7.3.  DNS

     If the user agent uses the DNS mechanisms described in
     Section 5.2.1.2, care needs to be taken to make sure that an attacker
     hasn't altered the DNS response.  Using DNSSEC is one method of
     improving the security aspects of this approach.  Alternatively, user
     agents MAY choose not use the DNS based mechanisms described in
     Section 5.2.1.2 at all.

  7.4.  Transport Security Validation

     Whenever secure transport is used (including TLS for HTTPS
     connections and QUIC's TLS-based security layer for HTTP/3), user
     agents MUST check the certificates presented by the server.  This
     certificate MUST be within its validity period (prior to its
     expiration date) and MUST chain to a root CA that is trusted by the
     user agent.  The certificate MUST have a subject alternative name
     (SAN) ([RFC5280]) with a DNS-ID ([RFC9525]) matching the hostname,
     per the rules given in [RFC9525].  The certificate MAY also be
     checked for revocation via OCSP ([RFC6960]), CRLs ([RFC6818]), or
     some other mechanism.  The general TLS usage guidance in [RFC9525]
     SHOULD be followed.

     If these checks fail or the server certificate is otherwise invalid,
     the user agent MUST disconnect and MUST NOT use any configuration
     retrieved from that URI.

     Certificate validation failures represent significant security risks,
     as they may indicate attempts to redirect users' credentials to an
     attacker.  User agents SHOULD NOT allow users to override certificate
     validation checks.

     User agents MAY implement more restrictive transport security
     policies for configuration retrieval than those typically required
     for web browsing, in order to provide stronger security guarantees.
     For TLS connections, user agents MAY want to limit the allowed
     protocol version(s) to recent versions, and MAY similarly want to
     restrict the allowed cipher suites.  For QUIC connections, user
     agents MAY apply similar restrictions to the underlying TLS handshake
     parameters.

     The HTTP server serving the Well-Known resource described in
     Section 5.2.1.1 MUST have support for TLS 1.3 ([RFC8446]) or higher.








  Eggert & Diephouse        Expires 2 April 2026                 [Page 31]


  Internet-Draft    Auto-Config of Email Server Settings    September 2025


  7.5.  Updating the Configuration

     The mechanism described in this document can be used to upgrade a
     user's configuration.  The user agent could check for configurations
     even when it has a working configuration for an account.  If the user
     agent finds a configuration that is better (in some way) than the
     already existing configuration, it could then upgrade the existing
     configuration.

     But in doing so, the user agent would increase the attack window that
     a potential attacker has.  Instead of only giving an attacker the
     opportunity when the user configures their user agent for the first
     time, the attacker would now have an opportunity each time the user
     agent checks for a better configuration.  That could be undesirable.

  7.6.  Provider Information

     Image parsers are a common attack vector, and clients MUST NOT
     display the logo images described in Section 4.4.1 unless they can do
     so in a way that doesn't expose the client to such attacks.

  8.  IANA Considerations

  8.1.  The User-Agent Auto-Configuration Protocol Registry

     This document establishes the user-agent auto-configuration protocol
     registry.

     User-agent auto-configuration protocols are registered on the advice
     of one or more Designated Experts (appointed by the IESG or their
     delegate), with a Specification Required (using terminology from
     [RFC8126]).  However, to allow for the allocation of values prior to
     publication, the Designated Expert(s) may approve registration once
     they are satisfied that such a specification will be published.

     Registration requests are sent to the ____@ietf.org mailing list for
     review and comment, with an appropriate subject (e.g., "Request for
     well-known URI: example").

     Before a period of 14 days has passed, the Designated Expert(s) will
     either approve or deny the registration request, communicating this
     decision both to the review list and to IANA.  Denials should include
     an explanation and, if applicable, suggestions as to how to make the
     request successful.  Registration requests that are undetermined for
     a period longer than 21 days can be brought to the IESG's attention
     (using the iesg@iesg.org mailing list) for resolution.





  Eggert & Diephouse        Expires 2 April 2026                 [Page 32]


  Internet-Draft    Auto-Config of Email Server Settings    September 2025


     Registry Name:
        User-Agent Auto-Configuration Protocols

     Registration Procedure:
        Specification Required (per [RFC8126])

  8.1.1.  Registration Template

     Name
        The commonly used name of the protocol

     Protocol Key:
        The JSON key using in the protocols object in the JSON
        configuration described in Section 4

     URL Scheme:
        (Optional) The URL scheme to be used for this protocol.  HTTP
        based protocols specify https.  If left empty, the protocols entry
        in the JSON configuration will only specify a hostname using host.
        If a URL scheme is specified, the JSON configuration entry will
        instead use url with a URL using this URL scheme.

     Specification
        Which RFC(s) or document(s) specify the protocol

     Additional Properties:
        Which additional property values are present in the protocol's
        JSON object.

  8.1.2.  Initial Registrations

     +=============+=============+========+================+============+
     | Name        | Protocol    | URL    | Specification  | Additional |
     |             | Key         | scheme |                | Properties |
     +=============+=============+========+================+============+
     | JMAP        | jmap        | https  | RFC 8620, RFC  |            |
     |             |             |        | 8621, RFC      |            |
     |             |             |        | 8887, RFC 9610 |            |
     +-------------+-------------+--------+----------------+------------+
     | IMAP        | imap        |        | RFC 9051       |            |
     +-------------+-------------+--------+----------------+------------+
     | POP3        | pop3        |        | RFC 1939, RFC  |            |
     |             |             |        | 5034           |            |
     +-------------+-------------+--------+----------------+------------+
     | SMTP        | smtp        |        | RFC 5321, RFC  |            |
     |             |             |        | 2822           |            |
     +-------------+-------------+--------+----------------+------------+
     | CalDAV      | caldav      | https  | RFC 4791       |            |



  Eggert & Diephouse        Expires 2 April 2026                 [Page 33]


  Internet-Draft    Auto-Config of Email Server Settings    September 2025


     +-------------+-------------+--------+----------------+------------+
     | CardDAV     | carddav     | https  | RFC 6352       |            |
     +-------------+-------------+--------+----------------+------------+
     | WebDAV      | webdav      | https  | RFC 4918       |            |
     +-------------+-------------+--------+----------------+------------+
     | ManageSieve | managesieve |        | RFC 5804, RFC  |            |
     |             |             |        | 5228           |            |
     +-------------+-------------+--------+----------------+------------+

            Table 4: Initial registrations to the User-Agent Auto-
                       Configuration Protocol Registry

     The _Additional Properties_ field is empty in all of the initial
     values.

  8.2.  Registration

  8.2.1.  Registration of Well-Known URI user-agent-configuration

     This registers the user-agent-configuration name from Section 5.2.1.1
     in the "Well-Known URIs" registry as specified in [RFC8615].

      +==========================+==========+===============+===========+
      | URI suffix               |Change    | Specification |Related    |
      |                          |controller| document(s)   |information|
      +==========================+==========+===============+===========+
      | user-agent-configuration |IETF      | This document |/          |
      +--------------------------+----------+---------------+-----------+

               Table 5: Registration in Well-Known URIs Registry

  8.2.2.  Registration of DNS Underscore Label _ua-auto-config

     This registers the DNS underscore label _ua-auto-config used in
     Section 5.2.1.2 in the "Underscored and Globally Scoped DNS Node
     Names" registry as specified in [RFC8552].

                 +=========+=================+===============+
                 | RR Type | _NODE NAME      | Reference     |
                 +=========+=================+===============+
                 | TXT     | _ua-auto-config | This document |
                 +---------+-----------------+---------------+

                    Table 6: Registration in Underscored and
                    Globally Scoped DNS Node Names Registry

  9.  Normative References




  Eggert & Diephouse        Expires 2 April 2026                 [Page 34]


  Internet-Draft    Auto-Config of Email Server Settings    September 2025


     [RFC1939]  Myers, J. and M. Rose, "Post Office Protocol - Version 3",
                STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996,
                <https://www.rfc-editor.org/info/rfc1939>.

     [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
                Extensions (MIME) Part One: Format of Internet Message
                Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
                <https://www.rfc-editor.org/info/rfc2045>.

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/info/rfc2119>.

     [RFC2595]  Newman, C., "Using TLS with IMAP, POP3 and ACAP",
                RFC 2595, DOI 10.17487/RFC2595, June 1999,
                <https://www.rfc-editor.org/info/rfc2595>.

     [RFC3207]  Hoffman, P., "SMTP Service Extension for Secure SMTP over
                Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207,
                February 2002, <https://www.rfc-editor.org/info/rfc3207>.

     [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
                Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
                <https://www.rfc-editor.org/info/rfc4648>.

     [RFC4791]  Daboo, C., Desruisseaux, B., and L. Dusseault,
                "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
                DOI 10.17487/RFC4791, March 2007,
                <https://www.rfc-editor.org/info/rfc4791>.

     [RFC4918]  Dusseault, L., Ed., "HTTP Extensions for Web Distributed
                Authoring and Versioning (WebDAV)", RFC 4918,
                DOI 10.17487/RFC4918, June 2007,
                <https://www.rfc-editor.org/info/rfc4918>.

     [RFC4954]  Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service
                Extension for Authentication", RFC 4954,
                DOI 10.17487/RFC4954, July 2007,
                <https://www.rfc-editor.org/info/rfc4954>.

     [RFC4959]  Siemborski, R. and A. Gulbrandsen, "IMAP Extension for
                Simple Authentication and Security Layer (SASL) Initial
                Client Response", RFC 4959, DOI 10.17487/RFC4959,
                September 2007, <https://www.rfc-editor.org/info/rfc4959>.






  Eggert & Diephouse        Expires 2 April 2026                 [Page 35]


  Internet-Draft    Auto-Config of Email Server Settings    September 2025


     [RFC5034]  Siemborski, R. and A. Menon-Sen, "The Post Office Protocol
                (POP3) Simple Authentication and Security Layer (SASL)
                Authentication Mechanism", RFC 5034, DOI 10.17487/RFC5034,
                July 2007, <https://www.rfc-editor.org/info/rfc5034>.

     [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
                Specifications: ABNF", STD 68, RFC 5234,
                DOI 10.17487/RFC5234, January 2008,
                <https://www.rfc-editor.org/info/rfc5234>.

     [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/info/rfc5280>.

     [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
                DOI 10.17487/RFC5321, October 2008,
                <https://www.rfc-editor.org/info/rfc5321>.

     [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
                DOI 10.17487/RFC5322, October 2008,
                <https://www.rfc-editor.org/info/rfc5322>.

     [RFC5804]  Melnikov, A., Ed. and T. Martin, "A Protocol for Remotely
                Managing Sieve Scripts", RFC 5804, DOI 10.17487/RFC5804,
                July 2010, <https://www.rfc-editor.org/info/rfc5804>.

     [RFC5890]  Klensin, J., "Internationalized Domain Names for
                Applications (IDNA): Definitions and Document Framework",
                RFC 5890, DOI 10.17487/RFC5890, August 2010,
                <https://www.rfc-editor.org/info/rfc5890>.

     [RFC5891]  Klensin, J., "Internationalized Domain Names in
                Applications (IDNA): Protocol", RFC 5891,
                DOI 10.17487/RFC5891, August 2010,
                <https://www.rfc-editor.org/info/rfc5891>.

     [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/info/rfc6234>.

     [RFC6352]  Daboo, C., "CardDAV: vCard Extensions to Web Distributed
                Authoring and Versioning (WebDAV)", RFC 6352,
                DOI 10.17487/RFC6352, August 2011,
                <https://www.rfc-editor.org/info/rfc6352>.




  Eggert & Diephouse        Expires 2 April 2026                 [Page 36]


  Internet-Draft    Auto-Config of Email Server Settings    September 2025


     [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
                RFC 6749, DOI 10.17487/RFC6749, October 2012,
                <https://www.rfc-editor.org/info/rfc6749>.

     [RFC6750]  Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
                Framework: Bearer Token Usage", RFC 6750,
                DOI 10.17487/RFC6750, October 2012,
                <https://www.rfc-editor.org/info/rfc6750>.

     [RFC6818]  Yee, P., "Updates to the Internet X.509 Public Key
                Infrastructure Certificate and Certificate Revocation List
                (CRL) Profile", RFC 6818, DOI 10.17487/RFC6818, January
                2013, <https://www.rfc-editor.org/info/rfc6818>.

     [RFC6960]  Santesson, S., Myers, M., Ankney, R., Malpani, A.,
                Galperin, S., and C. Adams, "X.509 Internet Public Key
                Infrastructure Online Certificate Status Protocol - OCSP",
                RFC 6960, DOI 10.17487/RFC6960, June 2013,
                <https://www.rfc-editor.org/info/rfc6960>.

     [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/info/rfc7616>.

     [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/info/rfc8126>.

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

     [RFC8414]  Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
                Authorization Server Metadata", RFC 8414,
                DOI 10.17487/RFC8414, June 2018,
                <https://www.rfc-editor.org/info/rfc8414>.

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

     [RFC8461]  Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A.,
                and J. Jones, "SMTP MTA Strict Transport Security (MTA-
                STS)", RFC 8461, DOI 10.17487/RFC8461, September 2018,
                <https://www.rfc-editor.org/info/rfc8461>.




  Eggert & Diephouse        Expires 2 April 2026                 [Page 37]


  Internet-Draft    Auto-Config of Email Server Settings    September 2025


     [RFC8552]  Crocker, D., "Scoped Interpretation of DNS Resource
                Records through "Underscored" Naming of Attribute Leaves",
                BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019,
                <https://www.rfc-editor.org/info/rfc8552>.

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

     [RFC8620]  Jenkins, N. and C. Newman, "The JSON Meta Application
                Protocol (JMAP)", RFC 8620, DOI 10.17487/RFC8620, July
                2019, <https://www.rfc-editor.org/info/rfc8620>.

     [RFC8702]  Kampanakis, P. and Q. Dang, "Use of the SHAKE One-Way Hash
                Functions in the Cryptographic Message Syntax (CMS)",
                RFC 8702, DOI 10.17487/RFC8702, January 2020,
                <https://www.rfc-editor.org/info/rfc8702>.

     [RFC9051]  Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message
                Access Protocol (IMAP) - Version 4rev2", RFC 9051,
                DOI 10.17487/RFC9051, August 2021,
                <https://www.rfc-editor.org/info/rfc9051>.

     [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/info/rfc9110>.

     [RFC9112]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
                Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
                June 2022, <https://www.rfc-editor.org/info/rfc9112>.

     [RFC9525]  Saint-Andre, P. and R. Salz, "Service Identity in TLS",
                RFC 9525, DOI 10.17487/RFC9525, November 2023,
                <https://www.rfc-editor.org/info/rfc9525>.

     [I-D.svg-tiny-ps-abrotman]
                Brotman, A. and J. T. Adams, "SVG Tiny Portable/Secure",
                Work in Progress, Internet-Draft, draft-svg-tiny-ps-
                abrotman-10, 1 May 2025,
                <https://datatracker.ietf.org/doc/html/draft-svg-tiny-ps-
                abrotman-10>.









  Eggert & Diephouse        Expires 2 April 2026                 [Page 38]


  Internet-Draft    Auto-Config of Email Server Settings    September 2025


     [OAuthPublic]
                Jenkins, N. and B. Bucksch, "OAuth Profile for Open Public
                Clients", Work in Progress, Internet-Draft, draft-ietf-
                mailmaint-oauth-public,
                <https://datatracker.ietf.org/doc/html/draft-ietf-
                mailmaint-oauth-public>.

  Appendix A.  Configuration JSON Schema

     The following JSON schema defines the format of the JSON
     configuration in Section 4

     ========== NOTE: '\' line wrapping per RFC 8792 ===========

     {
         "$schema": "https://json-schema.org/draft/2020-12/schema",
         "$id": "ua-auto-conf",
         "title": "User-Agent Automatic Configuration",
         "description": "Automatic Configuration of Email, Calendar, \
             and Contact Server Settings",
         "type": "object",
         "properties": {
             "protocols": {
                 "type": "object",
                 "properties": {
                     "caldav": { "$ref": "#/$defs/http-server" },
                     "carddav": { "$ref": "#/$defs/http-server" },
                     "imap": { "$ref": "#/$defs/text-server" },
                     "jmap": { "$ref": "#/$defs/http-server" },
                     "managesieve": { "$ref": "#/$defs/text-server" },
                     "pop3": { "$ref": "#/$defs/text-server" },
                     "smtp": { "$ref": "#/$defs/text-server" },
                     "webdav": { "$ref": "#/$defs/http-server" }
                 }
             },
             "authentication": {
                 "properties": {
                     "oauth-public": {
                         "properties": {
                             "issuer": {
                                 "format": "uri",
                                 "type": "string"
                             }
                         },
                         "required": [
                             "issuer"
                         ],
                         "type": "object"



  Eggert & Diephouse        Expires 2 April 2026                 [Page 39]


  Internet-Draft    Auto-Config of Email Server Settings    September 2025


                     },
                     "password": {
                         "type": "boolean"
                     }
                 },
                 "required": [ "password" ]
             },
             "info": {
                 "type": "object",
                 "properties": {
                     "provider": {
                         "type": "object",
                         "properties": {
                             "name": { "type": "string", "minLength": 1 },
                             "shortName": { "type": "string", \
                                 "minLength": 1 },
                             "logo": {
                                 "type": "array",
                                 "items": {
                                     "type": "object",
                                     "properties": {
                                         "url": { "type": "string", \
                                             "format": "uri" },
                                         "content-type": { \
                                             "type": "string", \
                                             "minLength": 1 },
                                         "width": { "type": "integer", \
                                             "minimum": 1 },
                                         "height": { "type": "integer", \
                                             "minimum": 1 }
                                     },
                                     "required": [ "url", "content-type" ]
                                 }
                             }
                         },
                         "required": [ "name" ]
                     },
                     "help": {
                         "type": "object",
                         "properties": {
                             "documentation": { "type": "string", \
                                 "format": "uri" },
                             "developer": { "type": "string", \
                                 "format": "uri" },
                             "contact": {
                                 "type": "array",
                                 "items": { "type": "string", \
                                     "minLength": 1 }



  Eggert & Diephouse        Expires 2 April 2026                 [Page 40]


  Internet-Draft    Auto-Config of Email Server Settings    September 2025


                             }
                         }
                     }
                 },
                 "required": [ "provider" ]
             }
         },
         "required": [ "protocols", "info" ],
         "$defs": {
             "http-server": {
                 "type": "object",
                 "properties": {
                     "url": { "type": "string", "format": "uri" }
                 },
                 "required": ["url"]
             },
             "text-server": {
                 "type": "object",
                 "properties": {
                     "host": { "type": "string", "format": "hostname" }
                 },
                 "required": ["host"]
             }
         }
     }

  Acknowledgements

     This document is based on the work of Ben Bucksch.

  Authors' Addresses

     Daniel Eggert
     Apple Inc
     One Apple Park Way
     Cupertino,  CA 95014
     United States of America
     Email: deggert@apple.com
     URI:   https://www.apple.com


     Matt Diephouse
     Apple Inc
     One Apple Park Way
     Cupertino,  CA 95014
     United States of America
     Email: diephouse@apple.com
     URI:   https://www.apple.com



  Eggert & Diephouse        Expires 2 April 2026                 [Page 41]


name: draft-tojens-dhcp-option-concat-considerations
rev: 01
title: DHCP Option Concatenation Considerations
time: 2025-09-04T07:09:37Z
group_uri: /api/v1/group/group/1027/
expires: 2025-09-04T23:36:02Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: ["Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:05.127607+00:00
abstract:
  DHCP has a length limit of 255 on individual options because of its
     one-byte length field for options.  To accommodate longer options,
     splitting option data across multiple instances of the same Option
     Type is defined by RFC 3396.  However, this mechanism was defined to
     require support for all option types.  This has led to real-world
     implementations in the years since the RFC was published to deviate
     from these requirements to avoid breaking basic functionality.  This
     document updates RFC 3396 to be more flexible regarding when DHCP
     agents are required to concatenate options to reflect deployement
     experiences.

full_text:
  dhc                                                            T. Jensen
  Internet-Draft                                                 M. Justel
  Updates: 3396 (if approved)                                    Microsoft
  Intended status: Informational                              3 March 2025
  Expires: 4 September 2025


                  DHCP Option Concatenation Considerations
             draft-tojens-dhcp-option-concat-considerations-01

  Abstract

     DHCP has a length limit of 255 on individual options because of its
     one-byte length field for options.  To accommodate longer options,
     splitting option data across multiple instances of the same Option
     Type is defined by RFC 3396.  However, this mechanism was defined to
     require support for all option types.  This has led to real-world
     implementations in the years since the RFC was published to deviate
     from these requirements to avoid breaking basic functionality.  This
     document updates RFC 3396 to be more flexible regarding when DHCP
     agents are required to concatenate options to reflect deployement
     experiences.

  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 4 September 2025.

  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.



  Jensen & Justel         Expires 4 September 2025                [Page 1]


  Internet-Draft  DHCP Option Concatenation Considerations      March 2025


     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
     2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
     3.  Previous Definition of Concatenation  . . . . . . . . . . . .   3
     4.  Implementation Challenges . . . . . . . . . . . . . . . . . .   3
     5.  What Concatenation Intends to Achieve . . . . . . . . . . . .   4
     6.  Changes to How Options are Split  . . . . . . . . . . . . . .   4
     7.  Changes to How Options are Concatenated . . . . . . . . . . .   4
       7.1.  Duplicates of Options with Defined Concatenation
             Behavior  . . . . . . . . . . . . . . . . . . . . . . . .   4
       7.2.  Duplicates of Fixed-length Options  . . . . . . . . . . .   5
       7.3.  Duplicates of Multiple-of-fixed-length Options  . . . . .   5
       7.4.  Duplicates of Arbitrary-length Options  . . . . . . . . .   5
     8.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
     9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
     10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
       10.1.  Normative References . . . . . . . . . . . . . . . . . .   6
       10.2.  Informative References . . . . . . . . . . . . . . . . .   6
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   7
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

  1.  Introduction

     [RFC3396] defines how DHCP agents are to split and concatenate option
     data within an DHCP message.  This has proven to be valuable as more
     DHCP options are defined that require support for concatenation as
     their data can exceed the 255 octet limit for options.  Examples
     include [RFC4702], [RFC6731] (as a MAY), [RFC7291], [RFC8572],
     [RFC8973], and [RFC9463].

     However, the way that [RFC3396] defined concatenation is not the way
     it is supported by major DHCP agent implementations today.
     Additionally, [RFC3396] allows for non-sensical deployments, such as
     handling multiple Lease Times, because it requires concatenations
     whenever any option is duplicated.  As a result, new or existing
     implementors of DHCP will find real-world behavior differs from the
     documented standard.







  Jensen & Justel         Expires 4 September 2025                [Page 2]


  Internet-Draft  DHCP Option Concatenation Considerations      March 2025


     This document updates [RFC3396] to clarify how option concatenation
     works in practice along with why it needs to differ from the previous
     standard.  It is not intended to invent new DHCP mechanisms; rather,
     it clarifies with the benefit of hindsight how DHCP behaves in
     practice and what implementors need to account for.

  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.

  3.  Previous Definition of Concatenation

     [RFC3396] defines the terms "concatenation-requiring" and "non-
     concatenation-requiring" to describe DHCP Options.  While at multiple
     points in the document it requires implementors to handle
     concatenation of Options defined as concatenation-requiring, it also
     contains the following text which effectively requires implementors
     to handle concatenation of either Option type:

     "However, an implementation which supports any concatenation-
     requiring option MUST be capable of concatenating received options
     for both concatenation-requiring and non-concatenation-requiring
     options."

  4.  Implementation Challenges

     In combination with the only permitted use of duplicate instances of
     an option type in the same DHCP message being option data splitting
     that then requires concatenation, this means that there is no way to
     recover from real-world DHCP deployment mistakes that can otherwise
     be handled under Jon Postel's Robustness Principle [RFC791].

     For example, if a DHCP server sends two instances of an option type
     with fixed length, such as Option 51 (IP Address Lease Time)
     [RFC2132], concatenating these into an eight-octet payload will
     result in a protocol violation: Option 51 has to be four octets long
     exactly.  In common deployments of DHCP agents today, we observe that
     this situation is handled by choosing one of the option instances
     that has the correct length to accept as the Option 51 value and
     ignoring the other instances.  If implementations decided instead to
     strictly adhere to always concatenating multiple instances of the
     same option type, this would entirely block IPv4 network connectivity
     for the network stack.




  Jensen & Justel         Expires 4 September 2025                [Page 3]


  Internet-Draft  DHCP Option Concatenation Considerations      March 2025


  5.  What Concatenation Intends to Achieve

     DHCP option concatenation is intended to allow option data to exceed
     the 255 octet limit imposed by its single-octet length field.  This
     can also be used for splitting options across DHCP message section
     boundaries when the Overload Option indicates that the sname field,
     file field, or both also contain option data.

  6.  Changes to How Options are Split

     To support the intention of option concatenation without causing the
     challenges described in (Section 4), this document updates [RFC3396]
     to limit concatenation to concatenation-requiring options.  DHCP
     agents SHOULD NOT provide multiple instances of an option type unless
     that option type is defined as concatenation-requiring.  To split
     non-concatenation-requiring options is out-of-spec behavior that
     leads to implementation-specific message processing.

  7.  Changes to How Options are Concatenated

     When DHCP agents receive messages with split options that are
     concatenation- required options, they MUST concatenate the duplicate
     concatenation-required options as described in [RFC3396].

     If DHCP agents sending messages never split non-concatenation-
     requiring options, no further guidance would be needed.  However,
     real-world deployments have seen out-of-spec behavior that clients
     may wish to be defensive against and liberal in parsing.  Therefore,
     when DHCP agents receive messages with split options that are not
     concatenation-requiring options, they MAY make best-effort attempts
     to interpret the message or fail processing entirely as a protocol
     error.  This is implementation-specific, though some reasonable
     suggestions are broken down in this section based on four types of
     situations involving non-concatenation- requiring options still being
     split (even though they should not be).

  7.1.  Duplicates of Options with Defined Concatenation Behavior

     Some non-concatenation-requiring options may still define how they
     are to be processed when DHCP agents receive multiple instances of
     the option type.  In this case, DHCP agents SHOULD follow the
     guidance defined by the option's standard.









  Jensen & Justel         Expires 4 September 2025                [Page 4]


  Internet-Draft  DHCP Option Concatenation Considerations      March 2025


  7.2.  Duplicates of Fixed-length Options

     Fixed-length options are options that only allow a single length
     value, such as Option 51 Lease Time which can only be four octets
     long.  DHCP agents receiving messages with more than one instance of
     fixed-length non-concatenation-requiring options MAY choose to
     attempt processing one of the instances if it has the correct length.

  7.3.  Duplicates of Multiple-of-fixed-length Options

     Multiple-of-fixed-length options are options that are lists of fixed-
     length elements, such as Option 6 DNS Name servers which MUST be a
     multiple of four octets long.  DHCP agents receiving messages with
     more than one instance of multiple-of-fixed-length options MAY choose
     to attempt processing one of the instances if it has a correct
     length.

     It MAY also choose to concatenate the options if the length of the
     concatenated option data is a correct length (which may indicate a
     need to split a long list because the total length is longer than 255
     octets).  DHCP agents MAY choose to only do this if the length of the
     concatenated option data is greater than 255 octets if it wants to
     reduce how permissive it is.

  7.4.  Duplicates of Arbitrary-length Options

     Arbitrary-length options are options that may have any non-zero octet
     length, such as Option 114 Captive-Portal [RFC8910].  DHCP agents
     receiving messages with more than one instance of arbitrary-length
     options MAY concatenate or choose one instance to process.  It MAY
     choose to do some validation of the content that would result from
     each approach, meaning if the data only makes sense in the context of
     the option's definition, it could use that to decide which approach
     to take.

  8.  Security Considerations

     This document changes the conditions under which a DHCP agent accepts
     or rejects option data.  The only way this might reduce a DHCP
     agent's security posture would be if it would have previously refused
     to process data from the network that it will now process.  However,
     this was always possible for an attacker crafting DHCP messages.  Any
     attacker capable of creating a malformed message could instead craft
     a well-formed message (which would be processed in the same way
     before and after this document).  Therefore, this document does not
     introduce any additional security considerations beyond the previous
     definitions of DHCP and option concatenation.




  Jensen & Justel         Expires 4 September 2025                [Page 5]


  Internet-Draft  DHCP Option Concatenation Considerations      March 2025


  9.  IANA Considerations

     This document has no IANA actions.

  10.  References

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

     [RFC3396]  Lemon, T. and S. Cheshire, "Encoding Long Options in the
                Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396,
                DOI 10.17487/RFC3396, November 2002,
                <https://www.rfc-editor.org/rfc/rfc3396>.

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

  10.2.  Informative References

     [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
                Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2132>.

     [RFC4702]  Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host
                Configuration Protocol (DHCP) Client Fully Qualified
                Domain Name (FQDN) Option", RFC 4702,
                DOI 10.17487/RFC4702, October 2006,
                <https://www.rfc-editor.org/rfc/rfc4702>.

     [RFC6731]  Savolainen, T., Kato, J., and T. Lemon, "Improved
                Recursive DNS Server Selection for Multi-Interfaced
                Nodes", RFC 6731, DOI 10.17487/RFC6731, December 2012,
                <https://www.rfc-editor.org/rfc/rfc6731>.

     [RFC7291]  Boucadair, M., Penno, R., and D. Wing, "DHCP Options for
                the Port Control Protocol (PCP)", RFC 7291,
                DOI 10.17487/RFC7291, July 2014,
                <https://www.rfc-editor.org/rfc/rfc7291>.

     [RFC791]   Postel, J., "Internet Protocol", STD 5, RFC 791,
                DOI 10.17487/RFC0791, September 1981,
                <https://www.rfc-editor.org/rfc/rfc791>.




  Jensen & Justel         Expires 4 September 2025                [Page 6]


  Internet-Draft  DHCP Option Concatenation Considerations      March 2025


     [RFC8572]  Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero
                Touch Provisioning (SZTP)", RFC 8572,
                DOI 10.17487/RFC8572, April 2019,
                <https://www.rfc-editor.org/rfc/rfc8572>.

     [RFC8910]  Kumari, W. and E. Kline, "Captive-Portal Identification in
                DHCP and Router Advertisements (RAs)", RFC 8910,
                DOI 10.17487/RFC8910, September 2020,
                <https://www.rfc-editor.org/rfc/rfc8910>.

     [RFC8973]  Boucadair, M. and T. Reddy.K, "DDoS Open Threat Signaling
                (DOTS) Agent Discovery", RFC 8973, DOI 10.17487/RFC8973,
                January 2021, <https://www.rfc-editor.org/rfc/rfc8973>.

     [RFC9463]  Boucadair, M., Ed., Reddy.K, T., Ed., Wing, D., Cook, N.,
                and T. Jensen, "DHCP and Router Advertisement Options for
                the Discovery of Network-designated Resolvers (DNR)",
                RFC 9463, DOI 10.17487/RFC9463, November 2023,
                <https://www.rfc-editor.org/rfc/rfc9463>.

  Acknowledgments

     Thank you to Dieter Siegmund, Stuart Cheshire, and Ted Lemon for
     their comments and suggestions.

  Authors' Addresses

     Tommy Jensen
     Microsoft
     Email: tojens.ietf@gmail.com


     Milan Justel
     Microsoft
     Email: milanjustel@microsoft.com
















  Jensen & Justel         Expires 4 September 2025                [Page 7]


name: draft-cui-nmrg-llm-nm
rev: 01
title: A Framework for LLM Agent-Assisted Network Management with Human-in-the-Loop
time: 2025-10-19T00:36:24Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-22T00:36:24Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Human-agent interaction", "Autonomous netops", "ML traffic mgmt", "AI safety/alignment"]
tags: []
fetched_at: 2026-02-27T22:56:05.127614+00:00
abstract:
  This document defines an interoperable framework that facilitates
     collaborative network management between Large Language Models (LLMs)
     agents and human operators.  The proposed framework introduces an
     enhanced telemetry module, an LLM agent decision module, and
     interaction data models between human operators and LLM agent-driven
     systems, and workflows to enforce human oversight.  The approach
     ensures compatibility with existing network management systems and
     protocols while improving automation and decision-making capabilities
     in network operations.

full_text:
  Network Management                                                Y. Cui
  Internet-Draft                                       Tsinghua University
  Intended status: Informational                                   M. Xing
  Expires: 21 April 2026                                          L. Zhang
                                                   Zhongguancun Laboratory
                                                           18 October 2025


  A Framework for LLM Agent-Assisted Network Management with Human-in-the-
                                    Loop
                          draft-cui-nmrg-llm-nm-01

  Abstract

     This document defines an interoperable framework that facilitates
     collaborative network management between Large Language Models (LLMs)
     agents and human operators.  The proposed framework introduces an
     enhanced telemetry module, an LLM agent decision module, and
     interaction data models between human operators and LLM agent-driven
     systems, and workflows to enforce human oversight.  The approach
     ensures compatibility with existing network management systems and
     protocols while improving automation and decision-making capabilities
     in network operations.

  About This Document

     This note is to be removed before publishing as an RFC.

     The latest revision of this draft can be found at
     https://xmzzyo.github.io/draft_llm_nm/draft-cui-nmrg-llm-nm.html.
     Status information for this document may be found at
     https://datatracker.ietf.org/doc/draft-cui-nmrg-llm-nm/.

     Discussion of this document takes place on the Network Management
     Research Group mailing list (mailto:nmrg@irtf.org), which is archived
     at https://mailarchive.ietf.org/arch/browse/nmrg.  Subscribe at
     https://www.ietf.org/mailman/listinfo/nmrg/.

     Source for this draft and an issue tracker can be found at
     https://github.com/xmzzyo/draft_llm_nm.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.






  Cui, et al.               Expires 21 April 2026                 [Page 1]


  Internet-Draft                   LLM4Net                    October 2025


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

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Motivation  . . . . . . . . . . . . . . . . . . . . . . .   3
       1.2.  Problem Statement . . . . . . . . . . . . . . . . . . . .   3
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
       2.1.  Acronyms and Abbreviations  . . . . . . . . . . . . . . .   4
     3.  Framework Overview  . . . . . . . . . . . . . . . . . . . . .   4
       3.1.  Enhanced Telemetry Module . . . . . . . . . . . . . . . .   5
       3.2.  LLM Agent Decision Module . . . . . . . . . . . . . . . .   5
         3.2.1.  RAG Module  . . . . . . . . . . . . . . . . . . . . .   6
         3.2.2.  Task Agent Module . . . . . . . . . . . . . . . . . .   6
         3.2.3.  Task Agent Communication Module . . . . . . . . . . .   7
         3.2.4.  Task Agent Management Module  . . . . . . . . . . . .   8
       3.3.  Config Verification Module  . . . . . . . . . . . . . . .  10
         3.3.1.  Syntax Validation Module  . . . . . . . . . . . . . .  10
         3.3.2.  Access Control Module . . . . . . . . . . . . . . . .  10
         3.3.3.  Feedback Module . . . . . . . . . . . . . . . . . . .  11
       3.4.  Operator Audit Module . . . . . . . . . . . . . . . . . .  11
     4.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .  13
       4.1.  DDoS Intelligent Defense  . . . . . . . . . . . . . . . .  13
       4.2.  Traffic Scheduling and Optimization . . . . . . . . . . .  15
     5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
     7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  17



  Cui, et al.               Expires 21 April 2026                 [Page 2]


  Internet-Draft                   LLM4Net                    October 2025


       7.1.  Normative References  . . . . . . . . . . . . . . . . . .  17
       7.2.  Informative References  . . . . . . . . . . . . . . . . .  17
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  18
     Appendix  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  18
       Appendix A.1 Data Model . . . . . . . . . . . . . . . . . . . .  18
         LLM Response Data Model . . . . . . . . . . . . . . . . . . .  18
         Human Audit Data Model  . . . . . . . . . . . . . . . . . . .  19
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20

  1.  Introduction

  1.1.  Motivation

     Traditional network automation systems often face challenges in
     handling unanticipated scenarios and managing complex multi-domain
     data dependencies.  Large Language Models (LLMs) offer advanced
     multimodal data comprehension, adaptive reasoning, and generalization
     capabilities, making them a promising tool for network management and
     autonomous network[TM-IG1230].  However, full automation remains
     impractical due to risks such as model hallucination, operational
     errors, and a lack of accountability in decision-making[Huang25].
     This document proposes a structured framework that integrates LLMs
     into network management through human-in-the-loop collaboration,
     leveraging their strengths while ensuring oversight, reliability, and
     operational safety.

  1.2.  Problem Statement

     Network management faces significant challenges, including the
     complexity of multi-vendor configurations, the real-time correlation
     of heterogeneous telemetry data, and the need for rapid responses to
     dynamic security threats.  LLMs offer a promising approach to
     addressing these challenges through their advanced multimodal data
     understanding and adaptive reasoning capabilities.  However, the
     direct application of LLMs in network management introduces several
     technical considerations.  These include the need for semantic
     enrichment of network telemetry to enhance LLM comprehension, a
     decision execution mechanism with confidence-based escalation, and
     auditability of LLM-generated decisions through provenance tracking.
     Addressing these requirements is critical to integrating LLM agents
     effectively into network management workflows while maintaining
     reliability, transparency, and interoperability.









  Cui, et al.               Expires 21 April 2026                 [Page 3]


  Internet-Draft                   LLM4Net                    October 2025


  2.  Terminology

  2.1.  Acronyms and Abbreviations

     *  LLM: Large Language Model

     *  RAG: Retrieve Augmented Generation

     *  MCP: Model Context Protocol

     *  A2A: Agent-to-Agent Protocol

  3.  Framework Overview

     +-------------------------------------------------------------+
     |         LLM-Agent Assisted Network Management System        |
     +-------------------------------------------------------------+
     |+---------------LLM Agent Decision Module-------------------+|
     ||                                                           ||
     ||               +----Task Agent Module---+  +-------------+ ||
     ||               | +---------------------+|  | Task Agent  <-----+
     ||               | |      MCP & A2A      ||<-> Mgt Module  | ||  |
     ||               | +---------------------+|  +-------------+ ||  |
     ||               | +------+  +----------+ |  |Syntax Verify| ||  |
     ||               | |Prompt|  |Fine-Tuned| <->|     Module  | ||  |
     ||               | | Lib  |  |Weight Lib| |  +-------------+ ||  |
     || +----------+  | +------+  +----------+ |  +--------------+||  |
     || |RAG Module|<-> +--------------------+ |  |Access Control|||  |
     || +-----^----+  | |Foundation Model Lib| -->|    Module    |||  |
     ||       |       | +--------------------+ |  +-------|------+||  |
     ||       |       +----^---------------^---+          |       ||  |
     |+-------|------------|---------------|--------------|-------+|  |
     |+-------v------------v----+ +--------v--------------v-------+|  |
     ||Enhanced Telemetry Module| |   Operator Audit Module       ||  |
     |+-----------^-------------+ +--------------|-------------^--+|  |
     +------------|------------------------------|-------------|---+  |
                  |                              |       +-----v---+  |
                  |                              |       |Operator <--+
                  |                              |       +---------+
     +------------v------------------------------v------------------+
     |               Original Network Management System             |
     +------------------------------^-------------------------------+
                                    |
     +------------------------------v-------------------------------+
     |                       Physical Network                       |
     +--------------------------------------------------------------+

     Figure 1: The LLM-Assisted Network Management Framework



  Cui, et al.               Expires 21 April 2026                 [Page 4]


  Internet-Draft                   LLM4Net                    October 2025


     The proposed framework is shown in Figure 1, highlighting the key
     components of LLM agent-assisted network management.  The human
     operator can generate a specific task agent, e.g., fault analysis or
     topology optimization, using the task agent management module by
     specifying foundation model, prompt, and adaptation fine-tuned
     parameters[Hu22].  The enhanced telemetry module improves the
     semantics of raw telemetry data from original network management
     system, providing supplementary information to the LLM agent decision
     module for more informed decision-making.  After the decision-making,
     the generated configuration parameters are validated against the YANG
     model and enforced with access control rules.  The operator audit
     module provides a structured mechanism for human oversight of LLM-
     generated configurations, and the configuration can be issued to the
     original network management system for deployment once the operator
     approves.

  3.1.  Enhanced Telemetry Module

     The Enhanced Telemetry Module improves the semantics of raw telemetry
     data, providing supplementary information to the LLM agent decision
     module for more informed decision-making.  Telemetry data retrieved
     from network devices via NETCONF[RFC6241], e.g., in XML format, often
     lacks field descriptions, structured metadata, and vendor-specific
     details.  Since this information is not included in the pre-trained
     knowledge of LLMs, it can lead to misinterpretation and erroneous
     reasoning.  To address this limitation, an external knowledge base
     should be introduced to store YANG model schema, device manuals, and
     other relevant documentation.  The Enhanced Telemetry Module
     functions as middleware between the network management system and the
     external knowledge base.  Through its southbound interface, it
     retrieves NETCONF data from the NETCONF client of existing network
     management system.  Through its northbound interface, the module
     queries the external knowledge base for the corresponding YANG model
     or device manual.  To enhance semantic richness, the Enhanced
     Telemetry Module processes the retrieved data by simplifying
     formatted content (e.g., removing redundant or closing XML tags) and
     appending XML path and description information from the YANG tree to
     the relevant fields.  This approach ensures that the LLM has access
     to structured, contextually enriched data, improving its ability to
     analyze and reason about network telemetry.

  3.2.  LLM Agent Decision Module









  Cui, et al.               Expires 21 April 2026                 [Page 5]


  Internet-Draft                   LLM4Net                    October 2025


  3.2.1.  RAG Module

     The pre-trained LLM may not encompass specific task requirements or
     vendor-specific knowledge.  To address this kind of limitation, the
     Retrieve-Augmented Generation (RAG)[Lewis20] approach is widely used.
     This module retrieves relevant information from operator-defined
     sources, such as device documentation and expert knowledge, and
     integrates it with the Enhanced Telemetry Module to obtain YANG model
     schema.  The retrieved textual data is stored in a database, either
     as raw text or in a vectorized format for efficient search and
     retrieval.  For a given task context, the module retrieves relevant
     knowledge from the database and incorporates it into the input
     context, improving the understanding and response accuracy of LLM.

  3.2.2.  Task Agent Module

     To execute a specific task, such as traffic analysis, traffic
     optimization, or fault remediation, a corresponding task agent must
     be created.  A task agent consists of a selected LLM foundation
     model, an associated prompt, and fine-tuned weights.

     *  Foundation Model Library.  Operators must select an appropriate
        foundation model based on the specific task requirements.
        Examples include general-purpose models such as GPT-4, LLaMA, and
        DeepSeek, as well as domain-specific models fine-tuned on private
        datasets.  Since foundation models are trained on different
        datasets using varying methodologies, their performance may differ
        across tasks.

     *  Fine-Tuned Weight Library.  For domain-specific applications,
        fine-tuned weights can be applied on top of a foundation model to
        efficiently adapt it to private datasets.  One commonly used
        approach is to store the fine-tuned weights as the difference
        between the original foundation model and the adapted model, which
        can largely reduce storage requirements.  The Fine-Tuned Weights
        Module supports the selection and loading of an appropriate
        foundation model along with the corresponding fine-tuned weights,
        based on the selection of operators.  This ensures flexibility in
        leveraging both general-purpose and domain-specific knowledge
        while maintaining computational efficiency.











  Cui, et al.               Expires 21 April 2026                 [Page 6]


  Internet-Draft                   LLM4Net                    October 2025


     *  Prompt Library.  For each task, it is essential to accurately
        define the task description, the format of its inputs and outputs.
        These definitions are stored in a structured prompt library.  When
        an operator instantiates a task, the corresponding prompt,
        including placeholders for contextual information, is
        automatically retrieved. operator inputs and device data are then
        incorporated into the prompt at the designated placeholders,
        ensuring a structured and consistent interaction with the language
        model.

  3.2.3.  Task Agent Communication Module

     Task agent can interact with external tools (e.g., Python scripts,
     Batfish or ILP solver) to acquire additional knowledge and perform
     specific actions.  The Model Context Prtocol (MCP)[mcp] enables task
     agents to securely and efficiently interact with external tools and
     services.  MCP defines a standardized interface for tool invocation,
     data exchange, and state synchronization between the agent and
     external systems.  MCP consists of two primary components:

     *  MCP Client: Embedded within the task agent, the MCP client is
        responsible for:

        -  Serializing agent-generated tool invocation requests into
           structured MCP messages.

        -  Managing authentication and session tokens for secure tool
           access.

        -  Handling timeouts, retries, and error propagation from tool
           responses.

        -  Injecting tool outputs back into the agent context as
           structured observations.

     *  MCP Server: Hosted alongside or within external tools, the MCP
        server:

        -  Exposes a well-defined set of capabilities via a manifest
           (e.g., tool_name, tool_description, input_schema,
           output_schema, authentication_method).

        -  Validates incoming MCP requests against the tool’s schema and
           permissions.

        -  Executes the requested operation and returns structured results
           in a deterministic format.




  Cui, et al.               Expires 21 April 2026                 [Page 7]


  Internet-Draft                   LLM4Net                    October 2025


        -  Supports streaming for long-running operations (e.g., iterative
           optimization or real-time telemetry polling).

     In many complex scenarios, multiple task agents may collaborate to
     achieve a shared network management objective.  The Agent-to-Agent
     Protocol (A2A)[a2a] is a coordination protocol that enables multiple
     task agents to exchange information, delegate subtasks, negotiate
     resource usage, and synchronize execution states in a distributed
     network management environment.  A2A ensures semantic
     interoperability, temporal consistency, and conflict avoidance across
     heterogeneous agents.  Key design principles of A2A include:

     *  Decentralized orchestration: No central controller is required;
        agents coordinate peer-to-peer using shared intents and
        commitments.

     *  Intent-based messaging: Communication is driven by high-level
        intents (e.g., “optimize latency for flow X”) rather than low-
        level commands, allowing flexibility in implementation.

     *  State-aware handoffs: Agents share partial execution states (e.g.,
        intermediate results, constraints, confidence scores) to enable
        context-preserving collaboration.

     Additionally, A2A integrates with the Task Agent Management Module to
     dynamically spawn or terminate agents based on collaboration needs,
     ensuring scalability and resource efficiency.

  3.2.4.  Task Agent Management Module

     The Task Agent Management Module is responsible for the creation,
     update, and deletion of task agents.  This module ensures that each
     agent is appropriately configured to align with the intended network
     management objective.

     The agent lifecycle operations are defined as follows:

     1.  Creation of Task Agents.  A task agent is instantiated in
         response to an operator request, an automated policy trigger, or
         a higher-level orchestration workflow.  The creation process
         involves the following steps:

         *  Intent Parsing: The module parses the high-level intent (e.g.,
            “remediate BGP flapping on router R5”) to identify the
            required task type, target network scope, and performance
            constraints.





  Cui, et al.               Expires 21 April 2026                 [Page 8]


  Internet-Draft                   LLM4Net                    October 2025


         *  Agent Template Selection: Based on the parsed intent, the
            module selects a pre-registered agent template from the Prompt
            Library.

         *  Resource Allocation: The module allocates necessary compute
            resources (CPU/GPU, memory) and instantiates the LLM runtime
            environment.

         *  Context Initialization: The agent is initialized with: Network
            context (e.g., device inventory, topology from Enhanced
            Telemetry), security credentials, and session ID and logging
            context for auditability.

         *  Registration: The newly created agent is registered with its
            metadata, status (“initializing”), and heartbeat endpoint.

     2.  Update of Task Agents.  Task agents may require updates due to
         changing network conditions, model improvements, or revised
         operator policies.  Updates should be performed in a non-
         disruptive manner whenever possible:

         *  Configuration Update: Operators or automated controllers may
            modify agent parameters (e.g., optimization thresholds, output
            verbosity).

         *  Model or Weight Swapping: If a newer fine-tuned weight version
            becomes available, the module can hot-swap the adapter weights
            while preserving the agent’s execution state, provided the
            base foundation model remains compatible.

         *  State Preservation: During updates, the module snapshots the
            agent’s working memory (e.g., conversation history,
            intermediate plans) and restores it post-update to maintain
            task continuity.

     3.  Deletion of Task Agents.  Task agents are terminated when their
         assigned task completes, when an unrecoverable error occurs, or
         upon an explicit teardown request.  The deletion process ensures
         proper resource reclamation and audit compliance:

         *  Graceful Shutdown: The module issues a termination signal,
            allowing the agent to complete any pending operations (e.g.,
            commit configuration changes, MCP calls, A2A communications).

         *  State Archival: The final agent state, including input
            context, generated actions, and performance metrics, is
            serialized and stored in the Audit Log for replayability and
            compliance.



  Cui, et al.               Expires 21 April 2026                 [Page 9]


  Internet-Draft                   LLM4Net                    October 2025


         *  Resource Deallocation: Compute resources (GPU memory, threads)
            are released, and MCP sessions are invalidated.

         *  Deregistration: The agent entry is removed, and its lifecycle
            event is logged.

     By providing structured, auditable, and policy-governed lifecycle
     management, the Task Agent Management Module enables scalable and
     trustworthy deployment of LLM Agent-driven network automation.

  3.3.  Config Verification Module

  3.3.1.  Syntax Validation Module

     To ensure correctness and policy compliance, LLM-generated
     configurations must pass the YANG schema validation steps before
     being queued for human approval.  This module ensures that only
     syntactically correct configurations are presented for operator
     review, thereby reducing errors and enhancing network reliability.

  3.3.2.  Access Control Module

     Although the Configuration Verify Module can guarantee the syntactic
     correction, LLMs may generate unintended or potentially harmful
     operations on critical network devices, it is essential for operators
     to enforce clear permission boundaries for LLM task agent to ensure
     security and operational integrity.  The Network Configuration Access
     Control Model defined in [RFC8341] provides a framework for
     specifying access permissions, which can be used to grant access to
     LLM task agents.  This data model includes the concepts of users,
     groups, access operation types, and action types, which can be
     applied as follows:

     *  User and Group: Each task agent should be registered as a specific
        user, representing an entity with defined access permissions for
        particular devices.  These permissions control the types of
        operations the LLM is authorized to perform.  A task agent (i.e.,
        user) is identified by a unique string within the system.  Access
        control can also be applied at the group level, where a group
        consists of zero or more members, and a task agent can belong to
        multiple groups.

     *  Access Operation Types: These define the types of operations
        permitted, including create, read, update, delete, and execute.
        Each task agent may support different sets of operations depending
        on its assigned permissions.





  Cui, et al.               Expires 21 April 2026                [Page 10]


  Internet-Draft                   LLM4Net                    October 2025


     *  Action Types: These specify whether a given operation is permitted
        or denied.  This mechanism determines whether an LLM request to
        perform an operation is allowed based on predefined access control
        rules.

     *  Rule List: A rule governs access control by specifying the content
        and operations a task agent is authorized to handle within the
        system.

     This module must enforce explicit restrictions on the actions an LLM
     is permitted to perform, ensuring that network configurations remain
     secure and compliant with operational policies.

  3.3.3.  Feedback Module

     As the generated configuration might not be always aligned with YANG
     model schema, access control, or bussiness constrains, they need
     further modification to meet the multi-dimensional requirements.  The
     Feedback Module is used to provide semantic-rich feedback (e.g.,
     represented in structure text) and hints to LLM agent to improve the
     generated configuration.

  3.4.  Operator Audit Module

     The Operator Audit Module provides a structured mechanism for human
     oversight of LLM-generated configurations before deployment.  The
     output from the LLM Decision Module should include both the generated
     configuration parameters and an associated confidence score.  The
     configuration parameters are validated for compliance with the YANG
     model and are subject to Access Control Rules enforcement.  The
     confidence score, e.g., ranging from 0 to 100, serves as a reference
     for operators to assess the reliability of the generated
     configuration.  Each audit process must track the input context
     (e.g., input data, RAG query content, model selection, configuration
     files) and the corresponding output results.  The auditing steps are
     as follows:

     *  Result Verification: The operator verifies the LLM-generated
        output to ensure alignment with business objectives and policy
        requirements.

     *  Compliance Check: The operator ensures that the LLM output adheres
        to regulatory standards and legal requirements.

     *  Security Verification: The operator examines the output for
        potential security risks, such as misconfigurations or
        vulnerabilities.




  Cui, et al.               Expires 21 April 2026                [Page 11]


  Internet-Draft                   LLM4Net                    October 2025


     *  Suggestions and Corrections: If issues are identified, the
        operator documents the findings and proposes corrective actions.

     Upon completing the audit, the system maintains an audit decision
     record to ensure traceability of operator actions.  The audit record
     includes the following information:

     *  Timestamp of the audit action

     *  LLM Task Agent ID associated with the action

     *  Operator decisions, including approval, rejection, modification,
        or pending status

     *  Executed command reflecting the final action taken

     *  Operation type (e.g., configuration update, deletion, or
        execution)

     This structured approach ensures that all LLM-generated
     configurations undergo rigorous human review, maintaining operational
     accountability, and security.

     The Operator Audit Module is enhanced with Explainability
     functionality to improve transparency and trust in LLM-assisted
     decision-making.  This enhancement ensures that operators can
     understand the reasoning behind LLM-generated configurations, verify
     their reliability, and take corrective actions when necessary.

     To achieve Explainability, the module provides a structured breakdown
     of the decision-making process by capturing key influencing factors,
     justification logs, and confidence scores.  Each LLM-generated
     configuration must include a detailed rationale explaining why a
     particular decision was made.  For example, if the system recommends
     increasing bandwidth allocation, the decision log should indicate
     whether this was due to high latency detected in telemetry, SLA
     thresholds being exceeded, or other contributing factors.

     Additionally, the audit process incorporates counterfactual analysis,
     allowing operators to assess alternative outcomes.  For instance, the
     system may indicate that if no action is taken, packet loss is
     expected to increase by 20% in the next ten minutes.  This capability
     enhances operational decision-making by providing a comparative
     assessment of different actions.

     To further ensure reliability, the module includes a mechanism to
     detect potential biases or hallucinations in LLM-generated outputs.
     If an LLM agent decision is based on incomplete or uncertain data,



  Cui, et al.               Expires 21 April 2026                [Page 12]


  Internet-Draft                   LLM4Net                    October 2025


     the system flags it accordingly, allowing operators to make informed
     judgments.  For example, if real-time telemetry data is insufficient,
     the system may indicate that the confidence in a particular
     recommendation is low.

     By integrating these Explainability features, the Operator Audit
     Module strengthens human oversight, ensuring that LLM-generated
     configurations align with business policies, security requirements,
     and regulatory standards.  This structured approach enhances
     accountability and mitigates risks associated with automated
     decision-making.

  4.  Use Cases

  4.1.  DDoS Intelligent Defense

     Distributed Denial of Service (DDoS) attacks remain a critical
     operational threat.  While conventional systems use rate-limiting and
     signature matching, they often fail to adapt in real-time or generate
     fine-grained filtering rules based on multi-dimensional telemetry
     data.

     This use case demonstrates how the LLM agent-assisted framework
     enables intelligent filtering rule generation and secure deployment
     with human oversight.

     1.  *Telemetry Collection and Semantic Enrichment* The Enhanced
         Telemetry Module retrieves real-time traffic statistics and
         interface metrics from network devices using NETCONF.  These raw
         telemetry data are semantically enriched by referencing YANG
         models and device-specific documentation to generate a context-
         rich dataset suitable for LLM processing.

     2.  *DDoS Filtering Task Instantiation* The operator initiates a
         ddos-mitigation task.  The Task Agent Module selects a security-
         specialized foundation model and task-specific prompt.

         It first analyzes the following conclusions: - Interface
         GigabitEthernet0/1 receiving sustained traffic > 100,000 pps -
         95% of incoming packets are TCP SYN - Top source prefixes
         identified as: IP1/24, IP2/24

         The RAG Module supplements the analysis with: - Cisco ACL syntax
         documentation - Prior incident response templates

     3.  *LLM-Generated Firewall Configuration Output* The LLM agent
         reasons that a TCP SYN flood is underway and generates the
         following ACL-based filtering policy:



  Cui, et al.               Expires 21 April 2026                [Page 13]


  Internet-Draft                   LLM4Net                    October 2025


     ip access-list extended BLOCK-DDOS
     deny tcp IP1 0.0.0.255 any
     deny tcp IP2 0.0.0.255 any
     permit ip any any

     interface GigabitEthernet0/1
     ip access-group BLOCK-DDOS in

     This configuration includes both source-based filtering and a global
     SYN rate-limiter.  It is passed to the Config Verify Module for
     syntax validation and to the Access Control Module for permission
     checks.

     1.  *Operator Audit and Decision* The Operator Audit Module provides
         the following metadata:

     *  *Task Agent ID*: ddos-mitigation-task-01

     *  *Confidence Score*: 85/100

     *  *RAG Context*: Cisco IOS ACL Syntax, Internal Threat List v5

     *  *Input Summary*:

        -  Affected Interface: GigabitEthernet0/1

        -  Malicious Sources: IP1/24, IP2/24

     The human operator performs the audit with the following steps:

     *  *Result Verification*: ACL syntax matches Cisco IOS 15.6
        standards.

     *  *Compliance Check*: Confirmed that both prefixes appear in the
        enterprise blacklist.

     *  *Security Review*: Low false-positive risk for blanket deny of SYN
        traffic from identified prefixes.

     *  *Audit Record*:

        -  Timestamp: 2025-07-16T17:03:00Z

        -  Decision: _Approved_

        -  Action: Apply via NMS interface





  Cui, et al.               Expires 21 April 2026                [Page 14]


  Internet-Draft                   LLM4Net                    October 2025


        -  Operator Note: “Confirmed match with active threat list.
           Monitor for collateral traffic drops.”

     The configuration is deployed through the network management system,
     completing the defense workflow with human oversight and
     traceability.

     This simplified case shows how the LLM agent can assist in quickly
     generating actionable filtering rules in response to DDoS patterns,
     while adhering to operational safeguards.

  4.2.  Traffic Scheduling and Optimization

     In large-scale networks, dynamic traffic scheduling is required to
     adapt to fluctuating loads, ensure QoS, and meet SLA requirements.
     Traditional methods may lack responsiveness or cross-domain
     visibility.

     The proposed framework enables intelligent, context-aware traffic
     scheduling through LLM agent-based reasoning.  The following
     illustrates the process:

     1.  *Telemetry Data Acquisition* The Enhanced Telemetry Module
         gathers link utilization, queue occupancy, and delay metrics from
         multiple routers.  The semantic enrichment process tags each
         metric with human-readable labels from the YANG model, including
         path topology and policy tags (e.g., gold/silver/bronze service
         classes).

     2.  *Optimization Task Execution* An operator initiates a traffic
         scheduling task.  The Task Agent Module selects a foundation
         model fine-tuned on traffic engineering datasets and uses a
         structured prompt to describe current constraints: high
         utilization on core links L1-L3, SLA violations for gold-class
         VoIP traffic.

     3.  *Sample Configuration Output* The LLM agent suggests adjusting
         RSVP-TE path metrics to reroute gold traffic via underutilized
         backup paths:












  Cui, et al.               Expires 21 April 2026                [Page 15]


  Internet-Draft                   LLM4Net                    October 2025


     policy-options {
         policy-statement reroute-gold {
             term gold-traffic {
                 from {
                     community gold-voip;
                 }
                 then {
                     metric 10;
                     next-hop [IP];
                 }
             }
         }
     }
     protocols {
         rsvp {
             interface ge-0/0/0 {
                 bandwidth 500m;
             }
         }
     }

     This configuration is syntax-validated and checked against the Access
     Control Module to ensure that traffic engineering policy updates are
     permitted for this task agent.

     1.  *Operator Audit and Decision* The Operator Audit Module presents:

     *  *Confidence Score*: 91/100

     *  *Audit Metadata*:

        -  Task Agent: traffic-opt-te-v2

        -  Input Context: “Link L1 (95% utilization), gold-voip SLA
           latency breach”

        -  Recommendation: “Increase TE path metric to reroute VoIP via L2
           backup path”

     The operator reviews:

     *  *Result Verification*: Simulates expected path shift via NMS.

     *  *Compliance Check*: Confirms SLA routing rules permit TE
        adjustment.

     *  *Security Review*: Confirms backup link L2 is secure and isolated.




  Cui, et al.               Expires 21 April 2026                [Page 16]


  Internet-Draft                   LLM4Net                    October 2025


     *  *Final Action*: _Approved with modification_: “Set bandwidth cap
        to 400m on backup to avoid overuse.”

     The revised configuration is stored and forwarded to the network
     management system for application.

     This use case illustrates how the framework enables LLM agents to
     propose adaptive, policy-compliant traffic engineering strategies
     while maintaining operator control, traceability, and auditability.

  5.  IANA Considerations

     This document includes no request to IANA.

  6.  Security Considerations

     *  Model Hallucination: A key challenge is that, without proper
        constraints, the LLM agent may produce malformed or invalid
        configurations.  This issue can be mitigated using techniques such
        as Constrained Decoding, which enforces syntactic correctness by
        modeling the configuration syntax and restricting the output to
        conform to predefined rules during the generation process.

     *  Training Data Poisoning: LLMs can be trained on malicious or
        biased data, potentially leading to unintended behavior or
        security vulnerabilities.  To mitigate this risk, LLMs should be
        trained on curated, high-quality datasets with rigorous validation
        and filtering processes.  Periodic retraining and adversarial
        testing should also be conducted to detect and correct anomalies
        before deployment.

  7.  References

  7.1.  Normative References

     [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
                and A. Bierman, Ed., "Network Configuration Protocol
                (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
                <https://www.rfc-editor.org/rfc/rfc6241>.

     [RFC8341]  Bierman, A. and M. Bjorklund, "Network Configuration
                Access Control Model", STD 91, RFC 8341,
                DOI 10.17487/RFC8341, March 2018,
                <https://www.rfc-editor.org/rfc/rfc8341>.

  7.2.  Informative References





  Cui, et al.               Expires 21 April 2026                [Page 17]


  Internet-Draft                   LLM4Net                    October 2025


     [a2a]      "Announcing the Agent2Agent Protocol (A2A)", July 2025,
                <https://developers.googleblog.com/en/a2a-a-new-era-of-
                agent-interoperability/>.

     [Hu22]     Hu, E. J., Shen, Y., Wallis, P., Allen-Zhu, Z., Li, Y.,
                Wang, S., Wang, L., and W. Chen, "LoRA Low-Rank Adaptation
                of Large Language Models", n.d..

     [Huang25]  Huang,, L., Yu, W., Ma, W., Zhong, W., Feng, Z., Wang, H.,
                Chen, Q., Peng, W., Feng, X., Qin, B., and T. Liu, "A
                Survey on Hallucination in Large Language Models
                Principles, Taxonomy, Challenges, and Open Questions",
                n.d..

     [Lewis20]  Lewis, P., Perez, E., Piktus, A., Petroni, F., Karpukhin,
                V., Goyal, N., Küttler, H., Lewis, M., Yih, W.-t.,
                Rocktäschel, T., and S. Riede, "Retrieval-augmented
                generation for knowledge-intensive NLP tasks", n.d..

     [mcp]      "Model Context Protocol", July 2025,
                <https://modelcontextprotocol.io/introduction>.

     [TM-IG1230]
                McDonnell, K., Machwe, A., Milham, D., O’Sullivan, J.,
                Niemöller, J., Varvello, L. F., Devadatta, V., Lei, W.,
                Xu, W., Yuan, X., and Y. Stein, "Autonomous Networks
                Technical Architecture", February 2023.

  Acknowledgments

     We thanks Shailesh Prabhu from Nokia for his contributions to this
     document.

  Appendix

  Appendix A.1 Data Model

     This section defines the essential data models for LLM agent-assisted
     network management, including the LLM agent decision response and
     human audit records.

  LLM Response Data Model

     The LLM agent decision module should respond with the generated
     configuration parameters along with an associated confidence score.
     If the LLM is unable to generate a valid configuration, it should
     return an error message accompanied by an explanation of the issue.




  Cui, et al.               Expires 21 April 2026                [Page 18]


  Internet-Draft                   LLM4Net                    October 2025


     module: llm-response-module
       +--rw llm-response
          +--rw config?         string
          +--rw confidence?     uint64
          +--rw error-reason?   enumeration

     The LLM response YANG model is structured as follows:

     module llm-response-module {
       namespace "urn:ietf:params:xml:ns:yang:ietf-nmrg-llmn4et";
       prefix llmresponse;
       container llm-response {
         leaf config {
           type string;
         }
         leaf confidence {
           type uint64;
         }
         leaf error-reason {
           type enumeration {
             enum unsupported-task;
             enum unsupported-vendor;
           }
         }
       }
     }

  Human Audit Data Model

     This data model defines the structure for human audit operations and
     record-keeping.  It facilitates collaborative decision-making by
     allowing LLMs to generate actionable insights while ensuring that
     human operators retain final operational authority.

     module: human-audit-module
       +--rw human-audit
          +--rw task-id?      string
          +--rw generated-config?   string
          +--rw confidence?         int64
          +--rw human-actions
             +--rw operator?          string
             +--rw action?            enumeration
             +--rw modified-config?   string
             +--rw timestamp?         yang:date-and-time

     The human audit YANG model is structured as follows:





  Cui, et al.               Expires 21 April 2026                [Page 19]


  Internet-Draft                   LLM4Net                    October 2025


     module human-audit-module {
       namespace "urn:ietf:params:xml:ns:yang:ietf-nmrg-llmn4et";
       prefix llmaudit;
       import ietf-yang-types { prefix yang; }

       container human-audit {
         leaf task-id {
           type string;
           }
         leaf generated-config {
           type string;
           }
         leaf confidence {
           type int64;
           }
         container human-actions {
           leaf operator {
             type string;
             }
           leaf action {
             type enumeration {
               enum approve;
               enum modify;
               enum reject;
               }
             }
           leaf modified-config {
             type string;
             }
           leaf timestamp {
             type yang:date-and-time;
             }
         }
       }
     }

  Authors' Addresses

     Yong Cui
     Tsinghua University
     Beijing, 100084
     China
     Email: cuiyong@tsinghua.edu.cn
     URI:   http://www.cuiyong.net/







  Cui, et al.               Expires 21 April 2026                [Page 20]


  Internet-Draft                   LLM4Net                    October 2025


     Mingzhe Xing
     Zhongguancun Laboratory
     Beijing, 100094
     China
     Email: xingmz@zgclab.edu.cn


     Lei Zhang
     Zhongguancun Laboratory
     Beijing, 100094
     China
     Email: zhanglei@zgclab.edu.cn







































  Cui, et al.               Expires 21 April 2026                [Page 21]


name: draft-eckert-anima-acp-free-ani
rev: 01
title: ACP free "Automation Network Infrastructure" for simple in-network automation (aNI)
time: 2025-10-20T18:51:47Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-23T18:51:47Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Autonomous netops", "Agent identity/auth", "A2A protocols", "Agent discovery/reg"]
tags: []
fetched_at: 2026-02-27T22:56:05.127618+00:00
abstract:
  This document describes how to to build the software infrastructure
     for distributed automation agents using a lightweight variation of
     the "Autonomic Networking Infrastructure" (ANI), by using the
     existing ANI domain keying material (certificates and trust anchors)
     as well as the protocols GRASP and BRSKI protocols, but eliminating
     the expensive to implement "Autonomic Control Plane" (ACP) and adding
     proxying "Autonomic Software Agents" (ASA) instead.

     The resulting infrastructure is called "automation Network
     Infrastructure" and can be implemented solely as application level
     software components on routers, switches or co-located managemenet
     devices, avoiding the need to change any router or switches
     forwarding or control-plane protocols.

     The aNI achieves mosts of the benefits of the ANI but foregoes the
     ability to easily make pre-existing, insecure control-plane protocols
     secure or provide all the same protection against operator or SDN
     controller misconfigurations that the ACP provides.

full_text:
  ANIMA                                                     T. Eckert, Ed.
  Internet-Draft                                Futurewei Technologies USA
  Intended status: Informational                                    B. Liu
  Expires: 23 April 2026                               Huawei Technologies
                                                           20 October 2025


     ACP free "Automation Network Infrastructure" for simple in-network
                              automation (aNI)
                     draft-eckert-anima-acp-free-ani-01

  Abstract

     This document describes how to to build the software infrastructure
     for distributed automation agents using a lightweight variation of
     the "Autonomic Networking Infrastructure" (ANI), by using the
     existing ANI domain keying material (certificates and trust anchors)
     as well as the protocols GRASP and BRSKI protocols, but eliminating
     the expensive to implement "Autonomic Control Plane" (ACP) and adding
     proxying "Autonomic Software Agents" (ASA) instead.

     The resulting infrastructure is called "automation Network
     Infrastructure" and can be implemented solely as application level
     software components on routers, switches or co-located managemenet
     devices, avoiding the need to change any router or switches
     forwarding or control-plane protocols.

     The aNI achieves mosts of the benefits of the ANI but foregoes the
     ability to easily make pre-existing, insecure control-plane protocols
     secure or provide all the same protection against operator or SDN
     controller misconfigurations that the ACP provides.

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



  Eckert & Liu              Expires 23 April 2026                 [Page 1]


  Internet-Draft                ACP free aNI                  October 2025


  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
     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.  Background  . . . . . . . . . . . . . . . . . . . . . . .   3
       1.2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   4
       1.3.  Architecture Example  . . . . . . . . . . . . . . . . . .   5
     2.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   7
       2.1.  Credentuals and mutual trust  . . . . . . . . . . . . . .   7
       2.2.  Area segmented connectivity . . . . . . . . . . . . . . .   8
       2.3.  End-to-end transport protocols  . . . . . . . . . . . . .   9
       2.4.  GRASP security and transport substrate  . . . . . . . . .   9
       2.5.  Distributed ASA coordination via GRASP  . . . . . . . . .  10
       2.6.  Inter-area communications . . . . . . . . . . . . . . . .  11
         2.6.1.  Inter-area information flooding . . . . . . . . . . .  13
         2.6.2.  Loop prevention in inter-area GRASP flooding  . . . .  13
         2.6.3.  Inter-area GRASP policy filtering . . . . . . . . . .  13
         2.6.4.  Inter-area service announcements  . . . . . . . . . .  13
         2.6.5.  inter-area transport proxy ASA  . . . . . . . . . . .  14
       2.7.  Pledge Bootstrap  . . . . . . . . . . . . . . . . . . . .  14
         2.7.1.  Unsecured pledges bringup . . . . . . . . . . . . . .  15
         2.7.2.  BRSKI pledges . . . . . . . . . . . . . . . . . . . .  16
         2.7.3.  aNI bootstrap . . . . . . . . . . . . . . . . . . . .  16
       2.8.  Inter-domain aNI communications . . . . . . . . . . . . .  16
       2.9.  Using aNI domain credentials  . . . . . . . . . . . . . .  17
       2.10. Using federated aNI credentials . . . . . . . . . . . . .  17
       2.11. Using WebPKI certificates . . . . . . . . . . . . . . . .  17
     3.  Summary . . . . . . . . . . . . . . . . . . . . . . . . . . .  18
     4.  Security considerations . . . . . . . . . . . . . . . . . . .  19
       4.1.  Proxying and Security . . . . . . . . . . . . . . . . . .  19
       4.2.  Infrastructure security . . . . . . . . . . . . . . . . .  19
     5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  20
       5.1.  Normative References  . . . . . . . . . . . . . . . . . .  20
       5.2.  Informative References  . . . . . . . . . . . . . . . . .  20
     Appendix A.  Changelog  . . . . . . . . . . . . . . . . . . . . .  21



  Eckert & Liu              Expires 23 April 2026                 [Page 2]


  Internet-Draft                ACP free aNI                  October 2025


       A.1.  draft-eckert-anima-acp-free-ani-01  . . . . . . . . . . .  21
       A.2.  draft-eckert-anima-acp-free-ani-00  . . . . . . . . . . .  21
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  21

  1.  Introduction

  1.1.  Background

     [RFC8993] describes the reference model for Autonomic Networking
     which consists of a so-called "Autonomic Network Infrastructure"
     (ANI) and in-network (devices) software agents called "Autonomic
     Service Agents" (ASA).

     ASA can be imagined as simple as scripts in programming languages
     such as python or javascript developed by bendors, integrators or
     operators.  They are primarily intended to run on network devices
     such as router or switches, or on control equipment that is also
     decentrally deployed, such as management servers in network equipment
     locations often called point of presence (PoP).  These agents can
     operate alone or in support of centralized network management systems
     including controller or orchestrators.

     One of the core components of that ANI is the so-called "Autonomic
     Control Plane" (ACP, [RFC8994]), a set of functionalities
     establishing an autonomously (zero-touch) created and maintained VRF
     across all network that is primarily intended to provide always-on
     network reachability even in the absence of any operator or
     management established provisioning of the nodes.  The ACP then
     allows operators, centralized management software or ASA to
     communicate across it to manage the network and for example provision
     both the basic network addressing and routing (so-called data-plane)
     or specific subscriber services or to perform monitoring actions/
     automations.  See also [RFC8368].

     Unfortunately, implementing an ACP in network devices, especially
     those with legacy operating system software infrastructures can be a
     challenging exercise, and as of today, no widely adopted production
     implementations on commercial routers exist.

     Without an ANI, it is challenging to build simple automation agents
     running on (or near to) network devices because they are missing
     functionalities not ubiquitously found in networks today: credentials
     for secure communications with mutual trust, connectivity and
     discovery of other agents, defining new protocols for communication
     between agents and ability to communicate when the network or
     specific nodes are not yet configured for correct end-to-end
     reachability or when that reachability is broken.




  Eckert & Liu              Expires 23 April 2026                 [Page 3]


  Internet-Draft                ACP free aNI                  October 2025


     This document describes the mechanisms how these support functions
     can be supported for ASA and via ASA.  The resulting design is called
     by this document the "automation Network Infrastructure" (aNI).
     Lowercase 'a' is used to distinguish it from the ANI which does
     include an ACP.

     Like the ANI, the aNI is defined so that it does not introduce
     dependencies against external, centralized components, such as
     orchestrators or management controllers.  Like the ANI the aNI can
     therefore support those centralized components.

  1.2.  Overview

     This document introduces the concepts and components of an ACP-free
     automation Network Infrastructure (aNI), which leverages the
     components developed for the ANI except for its ACP.  The ACP is
     replaced by the assumed to be pre-established data-plane of the
     network, and as necessary by proxy ASA.

     Unlike the ANI with ACP, this aNI solution can easily be introduced
     into existing networks simply though the development of control-plane
     programs, for example developed in scripting languages such as python
     or javascript (whatever can best run on routers).  The aNI does not
     require any changes to routers forwarding planes and does not expect
     more than basic IPv4 and/or IPv6 end-to-end connectivity across
     segments of the network.

     In summary, the aNI differs from the ANI as follows:

     *  The networks existing and assumed to be pre-configured IPv4 or
        IPv6 connectivitiy (called data-plane) is used to provide end-to-
        end connectivity for GRASP or other protocols used to build ASA.
        Unlike the ACP, IPv4 is a fully permitted option, especially
        because large and complex industrial networks will continue to
        depend on it because it has some significant simplicity benefits
        over IPv6 in options such as [RFC1819] addressing.  Nevertheless,
        for any new deployments where there is no clear benefit of IPv4
        over IPv6, IPv6 is recommended.

     *  Discovery between ASA and between ASA and central network
        management components utilizes GRASP in the same ways as it does
        with ACP.  It requires on every network node a GRASP ASA, which is
        a lightweight (potentially scripted in python) user-level process
        that forwards GRASP discovery messages hop-by-hop.  This GRASP ASA
        can automatically be started and requires no configuration.  The
        hop-by-hop connections between these GRASP ASA is TLS.





  Eckert & Liu              Expires 23 April 2026                 [Page 4]


  Internet-Draft                ACP free aNI                  October 2025


     *  Mutual trust for end-to-end GRASP connections between ASA, and
        between GRASP agents, but also for any other existing protocols
        that may be used is based on the domain certificate model of
        [RFC8994]: Each node is identified by a certificate which also
        identifies the (aNI) domain and also indicates the primary network
        layer address of the node which is used for aNI communications.
        Like the ANI, the aNI can therefore operate without any
        dependencies against DNS.

     *  The aNI encourages re-use of any existing protocols such as HTTPS
        or others, that can help to avoid re-coding any already working
        ASA functionality.  GRASP is recommended whenever new designs
        could be easier than with potentially more complex frameworks that
        exist for HTTPS or CoAP(s).  Combinations of existing protocols
        with GRASP is also a recommended option, for example to use GRASP
        to automate existing protocols by amending announcement and
        discovery via GRASP and therefore eliminating manual or SDN
        controller based provisioning steps.

     *  All signaling protocols that are considered to be part of the aNI
        MUST use transport layer encryption of at least the security
        provided by TLS1.3.  If there are any existing or new protocols
        that do not meet this expectation, they are simply not considered
        to be part of the aNI.  For example existing routing protocols do
        typically not confirm to this level of security.  They can
        continue to operate unaffected from aNI.  They just do not conform
        to the security level of the aNI.

     *  Enrollment of security credentials for new network rollouts is
        recommended to use BRSKI ([RFC8995]) or any specified variation
        thereof, depending on the operational requirements of the network
        enrollment process.  In existing and pre-configured networks,
        alternatives such as netconf zero-touch with certificate
        enrollment may be viable alternatives, but are not equally
        comprehensively document as a solution.

     *  To support automation in the presence of missing end-to-end
        connectivity between all necessary nodes including new to-be-
        provisioned "pledges", proxies are used.  These proxies likely are
        a combination of generic transport proxies (e.g.: HTTP proxies) or
        service specific proxies (ASA with proxy functionality) depending
        on requirements.

  1.3.  Architecture Example

     The following Figure 1 summaries the archticture components.  These
     are all introduced in more details in the following architecture
     section.



  Eckert & Liu              Expires 23 April 2026                 [Page 5]


  Internet-Draft                ACP free aNI                  October 2025


                                    inter-area
                                    GRASP and
     ASAs      ASAs       ASAs      Transport    ASAs      ASAs        ASAs
                                    Proxy ASA
                                      /  \
     GRAS      GRASP      GRASP    GRASP GRASP  GRASP      GRASP       GRASP
     Coord.    Coord.    Coord.   Coord.  Coord. Coord.    Coord.    Coord.
     ASA        ASA        ASA      ASA1 ASA2    ASA        ASA        ASA
         \     /    \     /    \     |    |     /   \      /    \     /
   +------+   +------+   +------+   +------+   +------+   +------+   +------+
   |Router|---|Router|---|Router|-.-|NAT/FW|-.-|Router|---|Router|---|Router|
   |  1   |   |  2   |   |  3   |   |      |   |  4   |   |  5   |   |  6   |
   | with |   | with |   | with |   | with |   | with |   | with |   | with |
   |domain|   |domain|   |domain|   |domain|   |domain|   |domain|   |domain|
   | cert |   | cert |   | cert |   | cert |   | cert |   | cert |   | cert |
   +------+   +------+   +------+   +------+   +------+   +------+   +------+

     |<----------------------------->|   |<----------------------------->|
         GRASP-NA subdomain 1                  GRASP-NA subdomain 2
       forwarding of GRASP discovery        forwarding of GRASP discovery
         between nodes with same              between nodes with same
        end-to-end connectivity                 end-to-end connectivity
          example: IPv4 only                     example: IPv6 only
   |<----------------------------------------------------------------------->|
                  aNI domain (mutually trusted aNI certificates) ~~~~

                    Figure 1: aNI Architecture example

     The example architecture picture outlines the most relevant aspects
     of an aNI that where introduced in the overview section above and
     where they are the same or differ from the ANI with ACP.

     *  An aNI domain is the set of all nodes using the same aNI domain
        credentials (certificates and trust anchors).  These are using the
        same concept as ACP certificates/trust anchors.

     *  Enrollment of keying materials can use any protocol but prefers
        BRSKI (as in ACP).

     *  Addressing can use IPv4 and/or IPv6 and is solely the data-plane
        of the existing network.

     *  aNI domains may be subdivided into areas connected by inter-area
        nodes, as shown in the picture a NAT/FW.  Inside each area
        unrestricted connectivity between ASA is expected, across areas it
        is not.





  Eckert & Liu              Expires 23 April 2026                 [Page 6]


  Internet-Draft                ACP free aNI                  October 2025


     *  Inside each area, GRASP coordination agents enable distribution of
        information and service discovery.  This is the equivalent of
        GRASP inside the ACP ([RFC8994]).

     *  Between areas, forwarding of GRASP messages is managed by inter-
        area GRASP proxy ASA as well as existing specialized forwarding
        such as NAT and Firewall forwarding, or additional user-level
        transport proxy ASA.  The latter are generalizing the concept of
        BRSKI or HTTP proxies.

  2.  Architecture

  2.1.  Credentuals and mutual trust

     aNI relies on the same domain trust model as the ANI.  All nodes in
     an aNI domain are expected to have an aNI certificate and trust
     anchor(s) that allow to verify and authenticate the aNI certificates
     of other domain members.

     aNI certificates carry an aNI node name attributes, which differs
     from acp-node-names ([RFC8994], section 6.2.2) as follows:

     *  The address part can either be an IPv6 address or an IPv4 address.
        (ABNF TBD).  The aNI address of a node is a data-plane address
        that is known to be permanently assigned to the node, routable and
        reachable across a segment of the aNI domain.  There is no new
        address assignment with ULA addresses as in the ACP.

     *  This document does not discuss the more complex additional options
        such as extensions or routing subdomains, but syntactically they
        are possible as they are for ACP certificates.

     *  Encoding into the X.509 aNI domain certificate is via a new
        "OTHER-NAME" attribute to allow distinguishing it from ACP
        addresses.  A node can therefore have a single certificate with
        both an aNI name element and (potentially later) an ACP name
        element without conflicts between them.

     Enrollment of these certificates is, as in [RFC8994] by arbitrary
     methods, preferrably BRSKI.  BRSKI details for aNI are discussed
     further domain in this document.










  Eckert & Liu              Expires 23 April 2026                 [Page 7]


  Internet-Draft                ACP free aNI                  October 2025


  2.2.  Area segmented connectivity

     aNI domains may not have transparent end-to-end connectivity across
     all nodes.  Instead, thay may be partitioned by nodes implementing
     functionality such as NAT or Firewall which provide only partial
     connectivity.  Or they may be partitioned without any connectivity
     because of different VRFs.  Or they may the partitioned by different
     network layers.  One part of the network may only use IPv4, another
     only IPv6.

     An aNI connectivity area is a contiguous set of nodes between which
     the data-plane provides in the absence of errors transparent end-to-
     end connectivity for all the traffic desired for the aNI.  This
     primarily involves traffic between ASA, but also traffic considered
     to be used in conjunction with ASA or aNI, such as traffic between
     central management nodes (controller/orchestrators), servers (NTP,
     DHCP, ...) and other required sockets on nodes.  This means that
     there may be filtering and limitations of traffic at the edge or
     inside such aNI areas, for example to prohibit traffic between these
     nodes and nodes outside the area (such as subscriber nodes).

     Note that these requirements should allow to add the aNI without
     change of any existing data-plane setup in most existing networks
     (private or service provider), and that many of them do not even need
     to consider multiple aNI connectivity areas.

     Note that that incorrect configuration of filtering of filtering will
     cause errors in the aNI in the same way as it does cause errors for
     any other management traffic.  The aNI does not - unlike the ACP -
     protect against such misconfiguration.

             connectivity area 1 ASA's           connectivity area 1 ASA's
         |<..............................>|  |<..............................>|

         ASAs      ASAs       ASAs      ASA  ASA      ASAs      ASAs        ASAs
          |          |          |        |    |        |          |          |
          |          |          |        |    |        |          |          |
       +------+   +------+   +------+   +------+   +------+   +------+   +------+
       |Router|---|Router|---|Router|-.-|NAT/FW|-.-|Router|---|Router|---|Router|
       |  1   |   |  2   |   |  3   |   |      |   |  4   |   |  5   |   |  6   |
       | with |   | with |   | with |   | with |   | with |   | with |   | with |
       |domain|   |domain|   |domain|   |domain|   |domain|   |domain|   |domain|
       | cert |   | cert |   | cert |   | cert |   | cert |   | cert |   | cert |
       +------+   +------+   +------+   +------+   +------+   +------+   +------+

       |<----------------------------------------------------------------------->|
                      aNI domain (mutually trusted aNI certificates)




  Eckert & Liu              Expires 23 April 2026                 [Page 8]


  Internet-Draft                ACP free aNI                  October 2025


                      Figure 2: aNI domain and areas

     Figure 1 shows a simple example of a single aNI domain with two
     connectivity areas, for example because of a NAT/FW node separating
     the two areas.  In the most simple case, an ASA connects only into a
     single area and sends/receives traffic only within a single area.
     There is no connectivity between ASA across the two areas in this
     example.

  2.3.  End-to-end transport protocols

     End-to-end connections considered to be part of the aNI MUST use a
     transport layer protocol with at least the level of encryption/
     security as TLS1.3.  Compared to the ACP this means that it is not
     possible to simply use existing, non-end-to-end transport layer
     encrypted protocols such as (non-TLS version of) DHCP, DNS, NTP, SNMP
     or other common (and older) management protocols.  If and where TLS/
     DTLS (or QUIC) variations to the protocols exist, they of course are
     applicable to the aNI.

     Connunication SHOULD use existing protocols and extend them as
     necessary instead of re-inventing new protocols unnecessary.  New
     protocol development for purposes for which no suitable existing
     protocols are available SHOULD use GRASP.  This applies to peer-to-
     peer and client-server connectivity between ASA or any other traffic
     considered to be part of the aNI.

  2.4.  GRASP security and transport substrate

     [RFC8990] requires that GRASP relies on a "security and transport"
     substrate, which in [RFC8994] is the ACP, TLS >= 1.2 and ACP domain
     certificates for mutual authentication.

     In the aNI, the "security and transport" substrate is the data-plane
     for connectivity, meaning the pre-existing IPv4 and/or IPv6
     connectivity, TLS >= 1.3 for any GRASP connection (except for link-
     local DULL GRASP for link-local discovery), and aNI domain
     certificates for mutual authentication.  The security considerations
     effectively ae the same as for GRASP across an ACP, but end-to-end
     (unicast) GRASP connections depend on proper functioning of data-
     plane routing.  Workarounds for this are descussed later in this
     document.









  Eckert & Liu              Expires 23 April 2026                 [Page 9]


  Internet-Draft                ACP free aNI                  October 2025


  2.5.  Distributed ASA coordination via GRASP

     ASA need to be able to self coordinate and orchestrate.  Responders
     need to be able to announce themselves to be discovered and selected
     by responders.  ASA may have other information that needs to be
     disseminated to multiple interested ASA across the domain.

     GRASP supports these operations through Discovery and Flood messages
     which are flooded hop-by-hop through the network by GRASP
     coordination agents.  Loops are prevented by sequence number
     duplicate elimination on reception, so that these agents donot
     require any routing information.  These age that can easily be
     implemented, for example as lightweight python scripts.

     The procedures for GRASP coordination agents are the same as
     described in [RFC8994].  Nodes discover their neighbors on interfaces
     via DULL GRASP, and they build TLS1.3 connections to their neighbors,
     mutually authenticating each others by their aNI certificates.  DULL
     GRASP uses a new port number (IANA assignment TBD) to distinguish it
     from DULL GRASP for the ACP.  Therefore, GRASP in the aNI can co-
     exist with GRASP in an ACP, hence a migration from an aNI to a full
     ANI with ACP is easily possible.

     aNI nodes MUST support a GRASP coordination ASA.  They MAY support
     other methods for coordination and orchestration including service
     announcement discovery and selection, such as DNS, but this
     specification does not specify any way how to automatically establish
     a sufficient DNS infrastructure and hence also no functionality that
     depends on DNS.  Instead, DNS-SD compatible service announcement,
     discovery and selecction is suggested to rely on GRASP as described
     in [I-D.eckert-anima-grasp-dnssd].




















  Eckert & Liu              Expires 23 April 2026                [Page 10]


  Internet-Draft                ACP free aNI                  October 2025


             connectivity area 1 ASA's           connectivity area 2 ASA's
         |<..............................>|  |<..............................>|

         ASAs      ASAs       ASAs      ASA  ASA      ASAs      ASAs        ASAs
          |          |          |        |    |        |          |          |
          |          |          |        |    |        |          |          |
         GRAS      GRASP      GRASP    GRASP GRASP  GRASP      GRASP       GRASP
         Coord.    Coord.    Coord.  Coord.  Coord. Coord.     Coord.      Coord.
         ASA        ASA        ASA      ASA1 ASA2    ASA        ASA        ASA
             \     /    \     /    \     |    |     /   \      /    \     /
       +------+   +------+   +------+   +------+   +------+   +------+   +------+
       |Router|---|Router|---|Router|-.-|NAT/FW|-.-|Router|---|Router|---|Router|
       |  1   |   |  2   |   |  3   |   |      |   |  4   |   |  5   |   |  6   |
       | with |   | with |   | with |   | with |   | with |   | with |   | with |
       |domain|   |domain|   |domain|   |domain|   |domain|   |domain|   |domain|
       | cert |   | cert |   | cert |   | cert |   | cert |   | cert |   | cert |
       +------+   +------+   +------+   +------+   +------+   +------+   +------+

         |<----------------------------->|   |<----------------------------->|
               connectivity  area 1                 connectivity  area 2
           forwarding of GRASP messages       forwarding of GRASP messages
             between nodes with same              between nodes with same
            end-to-end connectivity               end-to-end connectivity
              example: IPv4 only                     example: IPv6 only
       |<----------------------------------------------------------------------->|
                      aNI domain (mutually trusted aNI certificates)

                   Figure 3: GRASP connectivity agents

     Figure 2 above shows the GRASP coordination ASA added to the prior
     example.  GRASP agents need to be able to determine all interfaces
     that belong to the same area and forward messages only between those
     interfaces.  If the node has interfaces in multiple areas, a separate
     instance of forwarding of GRASP messages needs to be run for each
     area.  In the example, this is shown for the NAT/FW node, which has
     interfaces in two areas.

     Note that ASA only need to rely on the GRASP coordination agent for
     sending and receiving of GRASP coordination messages.  GRASP
     "unicast" traffic to other nodes can simply use direct TLS
     connections to the nodes ASA.

  2.6.  Inter-area communications

     This section explains how to implement inter-area ASA communications
     using the model shown in Figure 4.





  Eckert & Liu              Expires 23 April 2026                [Page 11]


  Internet-Draft                ACP free aNI                  October 2025


             connectivity area 1                 connectivity area 2
         |<..............................>|  |<..............................>|

       Initiator                         GRASP                           Responder
         ASA1                    inter-area proxy ASA [1]                   ASA6
          |                          and optional                            |
          |                  inter-area transport ASA [2]                    |
          |                              |    |                              |
         GRAS      GRASP      GRASP    GRASP GRASP  GRASP      GRASP       GRASP
         Coord.    Coord.    Coord.  Coord.  Coord. Coord.     Coord.      Coord.
             \     /    \     /    \     |    |     /   \      /    \     /
       +------+   +------+   +------+   +------+   +------+   +------+   +------+
       |Router|---|Router|---|Router|-.-|NAT/FW|-.-|Router|---|Router|---|Router|
       |  1   |   |      |   |      |   |Fwd[3]|   |      |   |      |   |  6   |
       ........   ........   ........   ........   ........   ........   ........

       |<----------------------------------------------------------------------->|
                      aNI domain (mutually trusted aNI certificates)

                   Figure 4: Inter Area communications

     A responder ASA6 on Router 6 in area 2 intends to provide services
     also to be consumable by an Initiator ASA1 on Router 1 in area 1.

     Direct inter-area network layer connectivity from ASA1 to ASA6 may be
     possible in some cases, such as when area 1 is on the inside of a NAT
     and area 2 is on its outside.  However, ASA1 would have no way to
     even discover the availability of ASA6 without the introduction of
     the elements described in this section, because no GRASP messages are
     forwarded by the GRASP coordination ASA across area boundaries.
     Likewise in the opposite case, when ASA6 is on the inside, and ASA1
     is on the outside, not only does a connection require likely special
     setups, but it is also a matter of additional policy if that type of
     communication is even desired.  Likewise are the conditions
     different, when the impeding element is a Firewall or the areas are
     different VRF.

     The three type of components of the solution are called the GRASP
     inter-area proxy ASA [1], optional inter-area transport ASA [2] and
     Forwarding functionality [3] in the forwarding plane of the inter-
     area node.










  Eckert & Liu              Expires 23 April 2026                [Page 12]


  Internet-Draft                ACP free aNI                  October 2025


  2.6.1.  Inter-area information flooding

     The most simple example of inter-area forwarding is that of GRASP
     Flood messages used for information distribution.  All information is
     contained in the GRASP Flood message and thus no dependend inter-area
     communications is expected.  Examples of such information
     distribution could be simple router configurations for common
     functions.  Nevertheless, forwarding of such information betwween
     areas does very likely need to be policy filtered if not policy
     modified.  This is a job of specific GRASP inter-area proxy ASA.

  2.6.2.  Loop prevention in inter-area GRASP flooding

     In any case where GRASP inter-area proxy ASA flood GRASP messages
     across area boundaries, care must be taken to avoid looping messages.
     This specifically means that the GRASP signaling elemtn that is used
     to detect looping messages must not be changed when passing GRASP
     messages to another area, and the identifier in it needs to be unique
     across areas.

  2.6.3.  Inter-area GRASP policy filtering

     Inter-area flooding of GRASP messages should support policy filtering
     independent of the below described mechanisms to ensure the necessary
     connectivity.  This policy filtering may be derived automatically
     from specific subset of the Objective namespace or other novel GRASP
     signaling elements.

  2.6.4.  Inter-area service announcements

     As described in this sections introduction, in many cases a GRASP
     Flood Message may be a service announcement for one or more responder
     sockets of the announcer, or a third-party node (in case the
     announcement is not directly from the responder ASA).

     In this case, there is the expectation that nodes receiving this
     announcement may want to initiate connections to those responder
     sockets.  The inter-area forwarding ASA does thus need to understand
     if or how those responder sockets can be connected to from the area
     into which it forwards the GRASP Flood message.

     In the aforementioned outside-to-inside flooding across a NAT inter-
     area node, the GRASP inter-area proxy ASA does not need to change
     anything in the GRASP Flood message if inside and outside use the
     same IP address family.






  Eckert & Liu              Expires 23 April 2026                [Page 13]


  Internet-Draft                ACP free aNI                  October 2025


     If instead the desired reachability is from outside to inside, or if
     the address families differ, then it is typically necessary to set up
     specific NAT/PAT between inside and outside to enable the
     communication, and to also change the announced service address in
     the announced GRASP Flood to the other area.

     The use of GRASP in all these cases does cleanly resolve the problem
     that such communication setups are facing when the service
     announcement and discovery are not readily available in-band on the
     inter-area nodes, which today is almost always the case.

     In one example, ASA6 is on the inside, uses an RFC1918 addres, but
     its service should be available on the outside.  The GRASP inter-area
     proxy ASA learns about the service and establishes the necessary PAT,
     mapping a port available on the outside to that inside service, and
     accordingly adjusts the GRASP announcement before it passes it to the
     outside area towards ASA1.  When ASA1 then connects, it effectively
     connects to the outside address of the inter-area node, where the
     existing NAT forwarding plane connects it to the inside RFC1918
     address and server port for ASA6.

  2.6.5.  inter-area transport proxy ASA

     Instead of relying on such pre-existing/configurable forwarding
     plajne connectivity, such inter-area connectivity can and depending
     on use case must be implemented at user-level by so-called inter-
     arrea transport proxy ASA.  These are typically what in BRSKI (and
     HTTP) terms are called connection or stateful proxies, but they could
     equally be stateless proxies if this is ensured to be supported by
     the responders.

     (stateful) BRSKI proxies simply act on one side as TCP responders,
     recreating a new TCP connection on the other side as initiators and
     then forwarding traffic bidirectionally across that proxies
     connection.  HTTP proxies operate as HTTP message proxies, but can
     also be turned into TCP connection proxies through the HTTP CONNECT
     method.

  2.7.  Pledge Bootstrap

     With ANI, new nodes (pledges) for a domain are bootstrapped by
     provisioning them first with domain credentials via BRSKI and then
     provisioning them with any desirable protocols via the ACP.








  Eckert & Liu              Expires 23 April 2026                [Page 14]


  Internet-Draft                ACP free aNI                  October 2025


     With aNI, these pledges do not have end-to-end data-plane
     connectivity after BRSKI enrollment.  They still will likely only
     have link-local connectivity.  While automatic DHCP or IPv4 SLAAC
     connectivity may be something a data-plane provides for end-user
     nodes, this is typicaly not the case for router in the domain that
     are newly added (or replaced).

     For this reason, the aNI requires some form of proxy-connectivity ASA
     setup for such newly enrolled network nodes on a link-local connected
     aNI domain node, for example the same node that was providing the
     BRSKI proxy ASA.  This of course is only necessary if those new nodes
     are assumed to be remotely configured/provisioned instead of being
     able to fully self-provision through appropriate autonomous service
     agents.

  2.7.1.  Unsecured pledges bringup

     If new devices need to be brought into a domain that does not have
     BRSKI or another stand-alone mechanism to provision domain
     credentials, then a bootstrap proxy agent on a neighboring domain
     node can provide connectivity to such a pledge.  This ASA would
     involve the following aspects:

     *  The ASA is capable to discover the presence of such pledges
        through any pre-existing protocol on the pledge.  This can include
        LLDP, or simply the signaling elements that may be provided by by
        the pledge in DHCP requests and help to identify it.  Use of such
        pre-existing mechanisms would allow to avoid expecting any changes
        to pledges software in factory-fresh condition.  This is
        especially valuable on pledges that allow to later install
        additional softeware easily, such as ASA, e.g.: after enrolment.

     *  The bootstrap proxy agent on this neighboring node indicates the
        presence of such a new pledge through an appropriate new-pledge-
        announcement protocol to an enrollment service that may run on a
        central management node.  For example that server announces via
        GRASP its availaility and the bootstrap proxy agent signals
        presence of new plege(s) to that GRASP discovered server.













  Eckert & Liu              Expires 23 April 2026                [Page 15]


  Internet-Draft                ACP free aNI                  October 2025


     *  The bootstrap proxy agent implements or orchestrates a transport
        proxy that allows the enrollment servers to connect to sockets on
        the pledge via it. known or assumed to allow remote configuration.
        For example, the transport proxy could be a simple HTTPS server
        implementing only the CONNECT method to such ports on directly
        connected pledges.  The prior step GRASP signaling would inform
        the management node of the discovered (link-local) addresses and
        port(s) on those pledges through appropriate URLs.  Once the
        management station connects to the bootstrap proxy agent and
        issues the HTTP CONNECT, it has a transparent TCP connection to
        the plege.

  2.7.2.  BRSKI pledges

     If the pledge can already be enrolled with BRSKI or an equivalently
     secure alternative protocol into the aNI domain, there are a range of
     more options, but it may be a good start to simply use the same
     mechanisms as for an unsecured pledge except for the following.

     Any connections into the pledge after being enrolled via BRSKI SHOULD
     only be via TLS 1.3 or better and use the aNI domain credentials for
     authentication.  Ideally, no insecure ports should need to be open on
     such a to-be-provisioned node.

  2.7.3.  aNI bootstrap

     Whether a new, to-be-provisioned node uses BRSKI or not, any aNI
     functionality such as the GRASP coordination agent or any other ASA
     SHOULD be enabled through the provisioning system only after the
     required data-plane connectivity has been provisioned.

     This is beneficial, so that the GRASP coordination agent can
     determine the necessary information about which interface belongs to
     which area from the data-plane configuration.  In the most easy
     provisioning option, the data-plane configuration explicitly labels
     interfaces or addresses with aNI area numbers, so that the GRASP
     coordination agent has this information readily available.
     Otherwise, areas have to be determined by examining VRF membership
     and NAT inside/outside of interfaces/addresses, to automatically
     determine which area they should be assigned to.

  2.8.  Inter-domain aNI communications

     Many use cases require communications between ASA that are not in the
     same automation domain.  This section discusses options how to
     support this.





  Eckert & Liu              Expires 23 April 2026                [Page 16]


  Internet-Draft                ACP free aNI                  October 2025


  2.9.  Using aNI domain credentials

     Secure communication via TLS 1.3 or any other equal or better
     strength transport protocol with mutual certificate authentication
     with a peer in a different aNI domain requires mutual trust in the
     other domains aNI certificates.  If for example the domain of a peer1
     is peer1domain.example.com, then secure transport connections to
     peer1 needs a prior provisioning of the trust anchors for
     peer1domain.example.com on the local node.

     aNI certificates and trust-anchors, just like ACP certificates and
     trust anchors are not required to be WebPKI certificates, so no trust
     or enrolment into WebPKI systems is required.  This allows aNI to
     contually operate without any Internet connectivity.  It also
     eliminates any challenges that would otherwise easily be introduced
     with the desire for the certificate to contain private information
     such as the aNI domain information field.  Equally, enrollment and
     renewal of certificates is easily and automated with BRSKI or other
     protocol alternatives.

     In return to these benefits of private aNI certificates, it is
     necessary to provision mapping information between a trusted remote
     aNI domain trust anchors and that domains domain name.

  2.10.  Using federated aNI credentials

     To avoid configuring the above described aNI credential to domain
     mapping, typical deployhment cases such as service provider to
     customer interdomain connections, or collaborating service provider
     connections could rely on a common trust anchor and shared private
     (e.g.: BRSKI based certificate enrollment) system.  With such a
     setup, the single root trust anchor of that federation would allow to
     authenticate all federation member certificates, whereas the trust
     anchor of each domains aNI is an intermediate trust anchor, allowing
     all intradomain security to be managed in the same way as without a
     federation.

  2.11.  Using WebPKI certificates

     If using WebPKI certificates, including enrollment and renewal, is
     feasible, including the typical necessity of Internet connectivity,
     then aNI nodes requiring interdomain connections could also use such
     WebPKI to communicate with each other, reducing the operational
     complexity to simply configuring which web domain a remote peer is
     expected/permitted to be from.






  Eckert & Liu              Expires 23 April 2026                [Page 17]


  Internet-Draft                ACP free aNI                  October 2025


  3.  Summary

     In-network automation through simply programmed software agents
     called ASA requires a set of underlying infrastructure functions.  In
     the ANI, [RFC8993], these are provided through the combination of
     ACP, BRSKI and GRASP.

     This document outlines how the mayority of this ANI functionality can
     be provided without the need for the expensive to implement ACP, by
     simply making ASA rely on the the already existing connectivity in
     the network, the so-called data-plane.

     The resulting infrastructure module introduced in this document is
     called aNI - automation Network Infrastructure and can be implement
     solely as application-level software running on switches, routers or
     co-located management nodes, not requiring any changes to existing
     IPv6 and/or IPv6 routing and forwarding planes, but instead relying
     solely on transport-layer security (authentication and encryption of
     signaling protocols).

     Most importantly, the aNI can also work in the presence of the wide
     range of connectivity impairing functions in networks such as
     firewalls, NATs, traffic filtering and VRFs.  In the ANI, the ACP
     provided a parallel, unfethered IPv6 connectivity to overcome such
     impairments.  In contrast, in the aNI proxy ASA are required to
     establish connectivity, ranging from simple GRASP service
     announcement proxies that provide the missing connectivity when the
     impairment is because of NAT/PAT, to actual GRASP signaling and
     transport connection proxies, when there is no connectivity possible
     otherwise.  This approach generalizes the approach already used by
     BRSKI proxies.

     The fundamental security of the aNI is the same as in the ANI: domain
     certificates with automatic enrolment via BRSKI or other protocols.
     Like proposed in the ANI, role-based extensions can help to provide
     more fine-grained authentication.















  Eckert & Liu              Expires 23 April 2026                [Page 18]


  Internet-Draft                ACP free aNI                  October 2025


     The main "shortcoming" of the aNI compared to the ANI is that it does
     not provide (in its current version) transparent end-to-end security
     for pre-existing unsecured signaling protocols such as NTP, SNMP,
     DHCP, DNS, TFTP or other commonly used protocols for the networks
     control and management plane.  This is because since the definition
     of the ACP, secure versions or variations of these protocols have
     become more commonplace, and it is thus more appropriate today to
     expect for those secure evolutions to be used instead of investing
     large amounts of efforts to layer security underneath old protocol
     options. aNI domain certificates enable the seamless security for any
     protocol with TLS 1.3 or better transport layer security options -
     including of course also datagram protocols with DTLS 1.3.

  4.  Security considerations

  4.1.  Proxying and Security

     Providing remote access to not configured or incorrectly configured
     nodes constitutes a significant security challenge because those
     nodes are most often vulerable to attacks, with typical security
     issues such as open ports with default passwords.

     All proxying of connections towards such nodes described in this
     document is designed such that it can only be initiated from trusted
     nodes with aNI domain certificates - with the assumnption that ithis
     is a sufficient level of security to ensure that the initator is not
     malicious.  If this level of security is deemed insufficient, then
     more fine-grained role based authentication can be added to aNI
     domain certificates as already outline for ANI domain certificates in
     [RFC8994], limiting use of such connection proxies to more
     trustworthy nodes such as management stations.

  4.2.  Infrastructure security

     By not building an ACP, the aNI does not have the same level of
     infrastructure security as an ANI.  Specifically attackers that gain
     access to physical links between nodes can inject packets and attempt
     to attack any weak (responder) sockets of network equipment.  The ACP
     prohibits this because it carries all control plane traffic across
     encrypted point-to-point tunnels.  Nevertheless, the aNI does expect
     that all control plane considered to be part of the aNI is protected
     by certifcate based transport layer security, so it does conform to
     todays best established standards for end-to-end security and extends
     it into the hop-by-hop infrastructure.

     To compensate for this lack of infrastructure security, it is
     recommended to not only deploy the "clamshell security" model common
     in service provider networks, but to also design ASA that automate



  Eckert & Liu              Expires 23 April 2026                [Page 19]


  Internet-Draft                ACP free aNI                  October 2025


     its establishment: Network connectivity to and from IPv4/IPv6
     addresses used between nodes of the aNI SHOULD be filtered on the
     edge of an aNI domain in the forwarding plane (with destination IPv4/
     IPv6 address ACL) so that attackers without access to a physcial link
     between aNI node can not inject the above described attacks.

  5.  References

  5.1.  Normative References

     [RFC1819]  Delgrossi, L., Ed. and L. Berger, Ed., "Internet Stream
                Protocol Version 2 (ST2) Protocol Specification - Version
                ST2+", RFC 1819, DOI 10.17487/RFC1819, August 1995,
                <https://www.rfc-editor.org/rfc/rfc1819>.

     [RFC8368]  Eckert, T., Ed. and M. Behringer, "Using an Autonomic
                Control Plane for Stable Connectivity of Network
                Operations, Administration, and Maintenance (OAM)",
                RFC 8368, DOI 10.17487/RFC8368, May 2018,
                <https://www.rfc-editor.org/rfc/rfc8368>.

     [RFC8990]  Bormann, C., Carpenter, B., Ed., and B. Liu, Ed., "GeneRic
                Autonomic Signaling Protocol (GRASP)", RFC 8990,
                DOI 10.17487/RFC8990, May 2021,
                <https://www.rfc-editor.org/rfc/rfc8990>.

     [RFC8993]  Behringer, M., Ed., Carpenter, B., Eckert, T., Ciavaglia,
                L., and J. Nobre, "A Reference Model for Autonomic
                Networking", RFC 8993, DOI 10.17487/RFC8993, May 2021,
                <https://www.rfc-editor.org/rfc/rfc8993>.

     [RFC8994]  Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, "An
                Autonomic Control Plane (ACP)", RFC 8994,
                DOI 10.17487/RFC8994, May 2021,
                <https://www.rfc-editor.org/rfc/rfc8994>.

     [RFC8995]  Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
                and K. Watsen, "Bootstrapping Remote Secure Key
                Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
                May 2021, <https://www.rfc-editor.org/rfc/rfc8995>.

  5.2.  Informative References









  Eckert & Liu              Expires 23 April 2026                [Page 20]


  Internet-Draft                ACP free aNI                  October 2025


     [I-D.eckert-anima-grasp-dnssd]
                Eckert, T. T., Boucadair, M., Jacquenet, C., and M. H.
                Behringer, "DNS-SD Compatible Service Discovery in GeneRic
                Autonomic Signaling Protocol (GRASP)", Work in Progress,
                Internet-Draft, draft-eckert-anima-grasp-dnssd-08, 7 July
                2025, <https://datatracker.ietf.org/doc/html/draft-eckert-
                anima-grasp-dnssd-08>.

  Appendix A.  Changelog

  A.1.  draft-eckert-anima-acp-free-ani-01

     refresh

  A.2.  draft-eckert-anima-acp-free-ani-00

     Initial version

  Authors' Addresses

     Toerless Eckert (editor)
     Futurewei Technologies USA
     United States of America
     Email: tte@cs.fau.de


     Bing Liu
     Huawei Technologies
     P.R. China
     Email: leo.liubing@huawei.com





















  Eckert & Liu              Expires 23 April 2026                [Page 21]


name: draft-meunier-webbotauth-registry
rev: 01
title: Registry and Signature Agent card for Web bot auth
time: 2025-10-20T12:52:39Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-23T12:52:39Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "Agent discovery/reg", "Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:05.127621+00:00
abstract:
  This document describes a JSON based format for clients using
     [DIRECTORY] to advertise information about themselves.

     This document describes a JSON-based "Signature Agent Card" format
     for signature agent using [DIRECTORY] to advertise metadata about
     themselve.  This includes identity, purpose, rate expectations, and
     cryptographic keys.  It also establishes an IANA registry for
     Signature Agent Card parameters, enabling extensible and
     interoperable discovery of agent information.

full_text:
  Web Bot Auth                                                M. Guerreiro
  Internet-Draft                                                Cloudflare
  Intended status: Informational                                U. Kirazci
  Expires: 23 April 2026                                            Amazon
                                                                T. Meunier
                                                                Cloudflare
                                                           20 October 2025


             Registry and Signature Agent card for Web bot auth
                    draft-meunier-webbotauth-registry-01

  Abstract

     This document describes a JSON based format for clients using
     [DIRECTORY] to advertise information about themselves.

     This document describes a JSON-based "Signature Agent Card" format
     for signature agent using [DIRECTORY] to advertise metadata about
     themselve.  This includes identity, purpose, rate expectations, and
     cryptographic keys.  It also establishes an IANA registry for
     Signature Agent Card parameters, enabling extensible and
     interoperable discovery of agent information.

  About This Document

     This note is to be removed before publishing as an RFC.

     The latest revision of this draft can be found at
     https://thibmeu.github.io/http-message-signatures-directory/draft-
     meunier-webbotauth-registry.html.  Status information for this
     document may be found at https://datatracker.ietf.org/doc/draft-
     meunier-webbotauth-registry/.

     Discussion of this document takes place on the Web Bot Auth Working
     Group mailing list (mailto:web-bot-auth@ietf.org), which is archived
     at https://mailarchive.ietf.org/arch/browse/web-bot-auth/.  Subscribe
     at https://www.ietf.org/mailman/listinfo/web-bot-auth/.

     Source for this draft and an issue tracker can be found at
     https://github.com/thibmeu/http-message-signatures-directory.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.





  Guerreiro, et al.         Expires 23 April 2026                 [Page 1]


  Internet-Draft  Registry and Signature Agent card for We    October 2025


     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 23 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
     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
     2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
     3.  Signature Agent Card  . . . . . . . . . . . . . . . . . . . .   4
       3.1.  Client Name . . . . . . . . . . . . . . . . . . . . . . .   4
       3.2.  Client URI  . . . . . . . . . . . . . . . . . . . . . . .   5
       3.3.  Contacts  . . . . . . . . . . . . . . . . . . . . . . . .   5
       3.4.  Logo URI  . . . . . . . . . . . . . . . . . . . . . . . .   5
       3.5.  Expected user agent . . . . . . . . . . . . . . . . . . .   5
       3.6.  robots.txt product token  . . . . . . . . . . . . . . . .   6
       3.7.  robots.txt compliance . . . . . . . . . . . . . . . . . .   6
       3.8.  Trigger . . . . . . . . . . . . . . . . . . . . . . . . .   6
       3.9.  Purpose . . . . . . . . . . . . . . . . . . . . . . . . .   6
       3.10. Targeted content  . . . . . . . . . . . . . . . . . . . .   6
       3.11. Rate control  . . . . . . . . . . . . . . . . . . . . . .   7
       3.12. Rate expectation  . . . . . . . . . . . . . . . . . . . .   7
       3.13. Known URLs  . . . . . . . . . . . . . . . . . . . . . . .   7
       3.14. Keys  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     4.  Discovery . . . . . . . . . . . . . . . . . . . . . . . . . .   8
       4.1.  Formal Syntax . . . . . . . . . . . . . . . . . . . . . .   9
       4.2.  Out-of-band communication between client and origin . . .   9



  Guerreiro, et al.         Expires 23 April 2026                 [Page 2]


  Internet-Draft  Registry and Signature Agent card for We    October 2025


       4.3.  Public list . . . . . . . . . . . . . . . . . . . . . . .   9
       4.4.  Signature-Agent header  . . . . . . . . . . . . . . . . .  10
     5.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
     6.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  10
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
       7.1.  Registration template . . . . . . . . . . . . . . . . . .  10
         7.1.1.  Initial Registry content  . . . . . . . . . . . . . .  11
     8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
       8.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
       8.2.  Informative References  . . . . . . . . . . . . . . . . .  16
     Appendix A.  Test Vectors . . . . . . . . . . . . . . . . . . . .  17
     Appendix B.  Implementations  . . . . . . . . . . . . . . . . . .  17
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  17
     Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . . .  17
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

  1.  Introduction

     Signature Agents are entities that originate or forward signed HTTP
     requests on behalf of users or services.  They include bots
     developers, platforms providers, and other intermediaries using
     [DIRECTORY].  These agents often need to identify themselves, and
     establish trust with origin servers.

     Today, the mechanisms for doing so are inconsistent: some rely on
     User-Agent strings (e.g. MyCompanyBot/1.0), others on IP address
     lists hosted on file servers (e.g. badbots.com), and still others on
     out-of-band definitions (e.g. documentation on docs.example.com/
     mybot).  This diversity makes it difficult for operators and origin
     servers to reliably discover and share a Signature Agent’s purpose,
     contact information, or rate expectations.  Existing discovery
     mechanisms, such as [OPENID-CONNECT-DISCOVERY], do not have the
     necessary granularity, and pursue different goals.

     This document introduces a JSON-based "Signature Agent Card" format
     for Signature Agents, to be published in registries and discovered by
     servers.  It also creates a new IANA registry of "Signature Agent
     Card Parameters" to ensure extensibility and consistency of future
     attributes.

  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.




  Guerreiro, et al.         Expires 23 April 2026                 [Page 3]


  Internet-Draft  Registry and Signature Agent card for We    October 2025


  3.  Signature Agent Card

     Signature-Agent header is defined in Section 4.1 of [DIRECTORY].
     This section describes Signature Agent Card, a JSON object containing
     parameters describing the Signature Agent.

  {
    "client_name": "Example Bot",
    "client_uri": "https://example.com/bot/about.html",
    "logo_uri": "https://example.com/",
    "contacts": ["mailto:bot-support@example.com"],
    "expected-user-agent": "Mozilla/5.0 ExampleBot",
    "rfc9309-product-token": "ExampleBot",
    "rfc9309-compliance": ["User-Agent", "Allow", "Disallow", "Content-Usage"],
    "trigger": "fetcher",
    "purpose": "tdm",
    "targeted-content": "Cat pictures",
    "rate-control": "429",
    "rate-expectation": "avg=10rps;max=100rps",
    "known-urls": ["/", "/robots.txt", "*.png"],
    "keys": [{
      "kty": "OKP",
      "crv": "Ed25519",
      "kid": "NFcWBst6DXG-N35nHdzMrioWntdzNZghQSkjHNMMSjw",
      "x": "JrQLj5P_89iXES9-vFgrIy29clF9CC_oPPsw3c5D0bs",
      "use": "sig",
      "nbf": 1712793600,
      "exp": 1715385600
    }]
  }

     Unless otherwise specified, all parameters in this document are
     OPTIONAL.  There MUST be at least one parameter set.

     Parameters for which the value is unknown MUST be ignored.  All
     string values are UTF-8.

  3.1.  Client Name

     The client_name parameter provides a friendly identifier for the
     Signature Agent.

     Example

     *  ExampleBot

     *  My remote browser company




  Guerreiro, et al.         Expires 23 April 2026                 [Page 4]


  Internet-Draft  Registry and Signature Agent card for We    October 2025


  3.2.  Client URI

     The client_uri parameter provides inline content or a web page
     describing the bot: e.g. what does it do, how it handles data it
     fetches.

     Only http, https or data:text/plain are allowed.

     Example

     *  https://example.com/bot/about.html

     *  data:text/plain,The Example bot is about providing an example.

  3.3.  Contacts

     The contacts parameter provides reliable communication channels in
     URI forms.  Typically, this is an email address.

     Example

     *  ["mailto:bot-support@example.com"]

     *  ["https://example.com/contact"]

  3.4.  Logo URI

     The logo_uri parameter provides an image reference for visual
     identification.

     TODO: Recommendation for size and format, if there is a clear
     consensus or reference we can point to.

     Example

     *  data:image/svg+xml;base64,deadbeef

     *  https://example.com/logo.png

  3.5.  Expected user agent

     The expected-user-agent parameter specifies one or more User-Agent
     strings as defined in Section 10.1.5 of [HTTP] or prefix matches.
     Prefixes MAY use * as a wildcard.

     Example

     *  Mozilla/5.0 ExampleBot



  Guerreiro, et al.         Expires 23 April 2026                 [Page 5]


  Internet-Draft  Registry and Signature Agent card for We    October 2025


  3.6.  robots.txt product token

     The rfc9309-product-token parameter specifies the product token used
     for robots.txt directives per Section 2.2.1 of [ROBOTSTXT].

     Example

     *  ExampleBot

  3.7.  robots.txt compliance

     The rfc9309-compliance parameter lists directives from robots.txt
     that the agent implements.

     Example

     *  ["User-Agent", "Disallow"]

     *  ["User-Agent", "Disallow", "CrawlDelay"]

  3.8.  Trigger

     The trigger parameter indicates the operational mode of the agent.

     Valid values:

     1.  fetcher - request initiated by the user

     2.  crawler - autonomous scanning

  3.9.  Purpose

     The purpose parameter describes the intended use of collected data.
     Values SHOULD be drawn from a controlled vocabulary, such as
     [AIPREF-VOCAB].

     Example

     *  search

     *  tdm

  3.10.  Targeted content

     The targeted-content parameter specifies the type of data the agent
     seeks.  Its format is arbitrary UTF-8 encoded string.

     Example



  Guerreiro, et al.         Expires 23 April 2026                 [Page 6]


  Internet-Draft  Registry and Signature Agent card for We    October 2025


     *  SEO analysis

     *  Vulnerability scanning

     *  Ads verification

  3.11.  Rate control

     The rate-control parameter indicates how origins can influence the
     agent’s request rate.

     TODO: specify a format

     Example

     *  CrawlDelay in robots.txt (non-standard)

     *  Custom tool

     *  429 + [RATELIMIT-HEADER]

  3.12.  Rate expectation

     The rate-expectation parameter specifies anticipated request volume
     or burstiness.

     TODO: consider a format such as avg=10rps;max=100rps

     Example

     *  500 rps

     *  Spikes during reindexing

  3.13.  Known URLs

     The known-urls parameter lists predictable endpoints accessed by the
     agent.

     These URLs may be absolute URLs like https://example.com/index.html.
     They could be relative path like /ads.txt.  Or they can use * as
     wildcard such as *.png.

     Example

     *  ["/"]

     *  ["/ads.txt"]



  Guerreiro, et al.         Expires 23 April 2026                 [Page 7]


  Internet-Draft  Registry and Signature Agent card for We    October 2025


     *  ["/favicon.ico"]

     *  ["/index.html"]

  3.14.  Keys

     The keys parameter contains a JWKS as defined in Section 5 of [JWK].

     If keys is present, it is RECOMMENDED that the card is signed using
     [HTTP-MESSAGE-SIGNATURES].  Content-Digest header MUST be included in
     the covered components.

     TODO: describe signature, CWS keys.

     Example

     *  https://example.com/.well-known/http-message-signatures-directory

     *  JWKS-directory

  4.  Discovery

     A registry is a list of URLs, each refering to a signature agent
     card.

     The URI scheme MUST be one of:

     *  https (RECOMMENDED): Points to an HTTPS resource serving a
        signature agent card

     *  http: Points to an HTTP resource serving a signature agent card

     *  data: Contains an inline signature agent card

     Example

     # An example list of bots
     https://bot1.example.com/.well-known/signature-agent-card
     https://crawler2.example.com/.well-known/signature-agent-card

     # Now the list of platforms
     https://zerotrust-gateway.example.com/.well-known/signature-agent-card

     # Below is an inlined card with the data URL scheme
     data:application/json;,... # Invalid, not defined






  Guerreiro, et al.         Expires 23 April 2026                 [Page 8]


  Internet-Draft  Registry and Signature Agent card for We    October 2025


  4.1.  Formal Syntax

     Below is an Augmented Backus-Naur Form (ABNF) description, as
     described in [ABNF].

     The below definition imports http-URI and https-URI from [HTTP], and
     dataurl from [DATAURL].

     registry = *(cardendpointline / emptyline)
     cardendpointline = (
         http-URI /       ; As defined in Section 4.2.1 of RFC 9110
         https-URI /      ; As defined in Section 4.2.2 of RFC 9110
         dataurl          ; As defined in Section 3 of RFC 2397
     ) EOL


     comment = "#" *(UTF8-char-noctl / WS / "#")
     emptyline = EOL
     EOL = *WS [comment] NL ; end-of-line may have
                            ; optional trailing comment
     NL = %x0D / %x0A / %x0D.0A
     WS = %x20 / %x09

     ; UTF8 derived from RFC 3629, but excluding control characters

     UTF8-char-noctl = UTF8-1-noctl / UTF8-2 / UTF8-3 / UTF8-4
     UTF8-1-noctl = %x21 / %x22 / %x24-7F ; excluding control, space, "#"
     UTF8-2 = %xC2-DF UTF8-tail
     UTF8-3 = %xE0 %xA0-BF UTF8-tail / %xE1-EC 2UTF8-tail /
              %xED %x80-9F UTF8-tail / %xEE-EF 2UTF8-tail
     UTF8-4 = %xF0 %x90-BF 2UTF8-tail / %xF1-F3 3UTF8-tail /
              %xF4 %x80-8F 2UTF8-tail

     UTF8-tail = %x80-BF

  4.2.  Out-of-band communication between client and origin

     A signature agent MAY submit their signature agent card to an origin,
     or the origin MAY manually add them to their local registry.

  4.3.  Public list

     A registry MAY be provided via a GitHub repository, a public file
     server, or a dedicated endpoint.

     The registry SHOULD be served over HTTPS.





  Guerreiro, et al.         Expires 23 April 2026                 [Page 9]


  Internet-Draft  Registry and Signature Agent card for We    October 2025


     A client application SHOULD validate the directory format and reject
     malformed entries.

  4.4.  Signature-Agent header

     Signature Agent Card format defined in Section 3 extends the format
     of Signature-Agent header as defined in Section 4.1 of [DIRECTORY].

     When used for HTTP Message Signatures, and hosted on a well-known
     URL, Signature Agent Card MAY be discovered via a Signature-Agent
     header.

  5.  Security Considerations

     Malicious actors may put properties which are not theirs in the
     registry.  If signatures are present, clients MUST verify them.
     Clients SHOULD reject cards with invalid signatures.

  6.  Privacy Considerations

     TODO

  7.  IANA Considerations

  7.1.  Registration template

     New registrations need to list the following attributes:

     *Parameter Name:*  The name requested (e.g. "useragent").  This name
        is case sensitive.  Names may not match other registered names in
        a case-insensitive manner unless the Designated Experts state that
        there is a compelling reason to allow an exception
     *Parameter Description:*  Brief description of the Header Parameter
     *Change Controller:*  For Standards Track RFCs, list the "IESG".  For
        others, give the name of the responsible party.  Other details
        (e.g., postal address, email address, home page URI) may also be
        included.
     *Reference:*  Where this parameter is defined
     *Notes:*  Any notes associated with the entry

     New entries in this registry are subject to the Specification
     Required registration policy ([RFC8126], Section 4.6).  Designated
     experts need to ensure that the token type is defined to be used for
     both token issuance and redemption.  Additionally, the experts can
     reject registrations on the basis that they do not meet the security
     and privacy requirements defined in TODO.





  Guerreiro, et al.         Expires 23 April 2026                [Page 10]


  Internet-Draft  Registry and Signature Agent card for We    October 2025


  7.1.1.  Initial Registry content

     This section registers the Signature Agent Card Parameter names
     defined in Section 3 in this registry.

  7.1.1.1.  Client Name Parameter

     *Parameter Name:*  client_name

     *Parameter Description:*  A friendly name for your signature agent.

     *Change Controller:*  IETF

     *Reference:*  Section 3.1

     *Notes:*  N/A

  7.1.1.2.  Client URI Parameter

     *Parameter Name:*  client_uri

     *Parameter Description:*  Describes what the bot does inline with
        data URI or with an HTTP link to an external resource

     *Change Controller:*  IETF

     *Reference:*  Section 3.2

     *Notes:*  N/A

  7.1.1.3.  Logo URI Parameter

     *Parameter Name:*  logo_uri

     *Parameter Description:*  Image for a quick visual identification

     *Change Controller:*  IETF

     *Reference:*  Section 3.4

     *Notes:*  N/A

  7.1.1.4.  Contacts Parameter

     *Parameter Name:*  contacts

     *Parameter Description:*  An array of URI with a reliable
        communication channel; typically email addresses



  Guerreiro, et al.         Expires 23 April 2026                [Page 11]


  Internet-Draft  Registry and Signature Agent card for We    October 2025


     *Change Controller:*  IETF

     *Reference:*  Section 3.3

     *Notes:*  N/A

  7.1.1.5.  Expected User Agent Parameter

     *Parameter Name:*  expected-user-agent

     *Parameter Description:*  String or fragment patterns

     *Change Controller:*  IETF

     *Reference:*  Section 3.5

     *Notes:*  N/A

  7.1.1.6.  RFC9309 Product Token Parameter

     *Parameter Name:*  rfc9309-product-token

     *Parameter Description:*  Robots.txt product token your signature-
        agent satisfies.

     *Change Controller:*  IETF

     *Reference:*  Section 3.6

     *Notes:*  N/A

  7.1.1.7.  RFC9309 Compliance Parameter

     *Parameter Name:*  rfc9309-compliance

     *Parameter Description:*  Does your signature-agent respect
        robots.txt.

     *Change Controller:*  IETF

     *Reference:*  Section 3.7

     *Notes:*  N/A

  7.1.1.8.  Trigger Parameter

     *Parameter Name:*  trigger




  Guerreiro, et al.         Expires 23 April 2026                [Page 12]


  Internet-Draft  Registry and Signature Agent card for We    October 2025


     *Parameter Description:*  Fetcher/Crawler

     *Change Controller:*  IETF

     *Reference:*  Section 3.8

     *Notes:*  N/A

  7.1.1.9.  Purpose Parameter

     *Parameter Name:*  purpose

     *Parameter Description:*  Intended use for the collected data

     *Change Controller:*  IETF

     *Reference:*  Section 3.9

     *Notes:*  N/A

  7.1.1.10.  Targeted Content Parameter

     *Parameter Name:*  targeted-content

     *Parameter Description:*  Type of data your agent seeks

     *Change Controller:*  IETF

     *Reference:*  Section 3.10

     *Notes:*  N/A

  7.1.1.11.  Rate control Parameter

     *Parameter Name:*  rate-control

     *Parameter Description:*  How can an origin control your crawl rate

     *Change Controller:*  IETF

     *Reference:*  Section 3.11

     *Notes:*  N/A

  7.1.1.12.  Rate expectation Parameter

     *Parameter Name:*  rate-expectation




  Guerreiro, et al.         Expires 23 April 2026                [Page 13]


  Internet-Draft  Registry and Signature Agent card for We    October 2025


     *Parameter Description:*  Expected traffic and intensity

     *Change Controller:*  IETF

     *Reference:*  Section 3.12

     *Notes:*  N/A

  7.1.1.13.  Known URLs Parameter

     *Parameter Name:*  known-urls

     *Parameter Description:*  Predictable endpoint accessed

     *Change Controller:*  IETF

     *Reference:*  Section 3.13

     *Notes:*  N/A

  7.1.1.14.  Keys Parameter

     *Parameter Name:*  keys

     *Parameter Description:*  JWKS Endpoint

     *Change Controller:*  IETF

     *Reference:*  Section 3.14

     *Notes:*  N/A

  8.  References

  8.1.  Normative References

     [ABNF]     Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
                Specifications: ABNF", STD 68, RFC 5234,
                DOI 10.17487/RFC5234, January 2008,
                <https://www.rfc-editor.org/rfc/rfc5234>.

     [AIPREF-VOCAB]
                Keller, P. and M. Thomson, "A Vocabulary For Expressing AI
                Usage Preferences", Work in Progress, Internet-Draft,
                draft-ietf-aipref-vocab-03, 4 September 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-aipref-
                vocab-03>.




  Guerreiro, et al.         Expires 23 April 2026                [Page 14]


  Internet-Draft  Registry and Signature Agent card for We    October 2025


     [DIRECTORY]
                Meunier, T., "HTTP Message Signatures Directory", Work in
                Progress, Internet-Draft, draft-meunier-http-message-
                signatures-directory-04, 20 October 2025,
                <https://datatracker.ietf.org/doc/html/draft-meunier-http-
                message-signatures-directory-04>.

     [HTTP]     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>.

     [HTTP-CACHE]
                Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
                Ed., "HTTP Caching", STD 98, RFC 9111,
                DOI 10.17487/RFC9111, June 2022,
                <https://www.rfc-editor.org/rfc/rfc9111>.

     [HTTP-MESSAGE-SIGNATURES]
                Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP
                Message Signatures", RFC 9421, DOI 10.17487/RFC9421,
                February 2024, <https://www.rfc-editor.org/rfc/rfc9421>.

     [HTTP-MORE-STATUS-CODE]
                Nottingham, M. and R. Fielding, "Additional HTTP Status
                Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012,
                <https://www.rfc-editor.org/rfc/rfc6585>.

     [JWK]      Jones, M., "JSON Web Key (JWK)", RFC 7517,
                DOI 10.17487/RFC7517, May 2015,
                <https://www.rfc-editor.org/rfc/rfc7517>.

     [JWK-OKP]  Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH)
                and Signatures in JSON Object Signing and Encryption
                (JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017,
                <https://www.rfc-editor.org/rfc/rfc8037>.

     [JWK-THUMBPRINT]
                Jones, M. and N. Sakimura, "JSON Web Key (JWK)
                Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September
                2015, <https://www.rfc-editor.org/rfc/rfc7638>.

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





  Guerreiro, et al.         Expires 23 April 2026                [Page 15]


  Internet-Draft  Registry and Signature Agent card for We    October 2025


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

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

  8.2.  Informative References

     [DATAURL]  Masinter, L., "The "data" URL scheme", RFC 2397,
                DOI 10.17487/RFC2397, August 1998,
                <https://www.rfc-editor.org/rfc/rfc2397>.

     [OAUTH-BEARER]
                Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
                Framework: Bearer Token Usage", RFC 6750,
                DOI 10.17487/RFC6750, October 2012,
                <https://www.rfc-editor.org/rfc/rfc6750>.

     [OPENID-CONNECT-DISCOVERY]
                "OpenID Connect Discovery 1.0", n.d.,
                <https://openid.net/specs/openid-connect-discovery-
                1_0.html>.

     [RATELIMIT-HEADER]
                Polli, R., Ruiz, A. M., and D. Miller, "RateLimit header
                fields for HTTP", Work in Progress, Internet-Draft, draft-
                ietf-httpapi-ratelimit-headers-10, 27 September 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-
                ratelimit-headers-10>.

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

     [ROBOTSTXT]
                Koster, M., Illyes, G., Zeller, H., and L. Sassman,
                "Robots Exclusion Protocol", RFC 9309,
                DOI 10.17487/RFC9309, September 2022,
                <https://www.rfc-editor.org/rfc/rfc9309>.

     [UTF8]     Yergeau, F., "UTF-8, a transformation format of ISO
                10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
                2003, <https://www.rfc-editor.org/rfc/rfc3629>.





  Guerreiro, et al.         Expires 23 April 2026                [Page 16]


  Internet-Draft  Registry and Signature Agent card for We    October 2025


  Appendix A.  Test Vectors

     TODO

  Appendix B.  Implementations

     TODO

  Acknowledgments

     TODO

     The editor would also like to thank the following individuals (listed
     in alphabetical order) for feedback, insight, and implementation of
     this document -

  Changelog

     v01

     *  Add contributors

     *  Aligning registry draft with oauth dynamic client registration
        iana registry

     *  Add an about-url field

     *  Add ABNF for discovery of signature-agent card (registry)

     *  Add precisions about known URLs

     *  Add placeholder for image size

     v00

     *  Initial draft

  Authors' Addresses

     Maxime Guerreiro
     Cloudflare
     Email: maxime.guerreiro@gmail.com


     Ulas Kirazci
     Amazon
     Email: ulaskira@amazon.com




  Guerreiro, et al.         Expires 23 April 2026                [Page 17]


  Internet-Draft  Registry and Signature Agent card for We    October 2025


     Thibault Meunier
     Cloudflare
     Email: ot-ietf@thibault.uk
















































  Guerreiro, et al.         Expires 23 April 2026                [Page 18]


name: draft-rosenberg-aiproto-cheq
rev: 00
title: CHEQ: A Protocol for Confirmation AI Agent Decisions with Human in the Loop (HITL)
time: 2025-10-20T02:19:41Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-23T02:19:41Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Human-agent interaction", "AI safety/alignment", "A2A protocols"]
tags: []
fetched_at: 2026-02-27T22:56:05.127624+00:00
abstract:
  This document proposes Confirmation with Human in the Loop (HITL)
     Exchange of Quotations (CHEQ).  CHEQ allows humans to confirm
     decisions and actions proposed by AI Agents prior to those decisions
     being acted upon.  It also allows humans to provide information
     required for tool invocation, without disclosing that information to
     the AI agent, protecting their privacy.  CHEQ aims to guarantee that
     AI Agent hallucinations cannot result in unwanted actions by the
     human on whose behalf they are made.  CHEQ can be integrated into
     protocols like the Model Context Protocol (MCP), the Agent-to-Agent
     (A2A) protocol, and the Normalized API for AI Agent Calling Tools
     (N-ACT) protocol.  It makes use of a signed object which can be
     carried in those protocols.

full_text:
  Network Working Group                                       J. Rosenberg
  Internet-Draft                                                     Five9
  Intended status: Informational                                  P. White
  Expires: 22 April 2026                                           Bitwave
                                                               C. Jennings
                                                                     Cisco
                                                           19 October 2025


   CHEQ: A Protocol for Confirmation AI Agent Decisions with Human in the
                                Loop (HITL)
                      draft-rosenberg-aiproto-cheq-00

  Abstract

     This document proposes Confirmation with Human in the Loop (HITL)
     Exchange of Quotations (CHEQ).  CHEQ allows humans to confirm
     decisions and actions proposed by AI Agents prior to those decisions
     being acted upon.  It also allows humans to provide information
     required for tool invocation, without disclosing that information to
     the AI agent, protecting their privacy.  CHEQ aims to guarantee that
     AI Agent hallucinations cannot result in unwanted actions by the
     human on whose behalf they are made.  CHEQ can be integrated into
     protocols like the Model Context Protocol (MCP), the Agent-to-Agent
     (A2A) protocol, and the Normalized API for AI Agent Calling Tools
     (N-ACT) protocol.  It makes use of a signed object which can be
     carried in those protocols.

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







  Rosenberg, et al.         Expires 22 April 2026                 [Page 1]


  Internet-Draft                    CHEQ                      October 2025


  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
     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
     2.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Architectural Framework . . . . . . . . . . . . . . . . . . .   4
     4.  Overview of Operation . . . . . . . . . . . . . . . . . . . .   6
       4.1.  Triggering Confirmation . . . . . . . . . . . . . . . . .   7
       4.2.  Performing Confirmation . . . . . . . . . . . . . . . . .   9
       4.3.  Finalizing  . . . . . . . . . . . . . . . . . . . . . . .  11
     5.  Using CHEQ for Data Privacy . . . . . . . . . . . . . . . . .  12
     6.  Usage with MCP and A2A and N-ACT  . . . . . . . . . . . . . .  13
     7.  Usage with Voice Interfaces . . . . . . . . . . . . . . . . .  13
     8.  Detailed Protocol Specification . . . . . . . . . . . . . . .  13
       8.1.  URI Pack Syntax and Semantics . . . . . . . . . . . . . .  13
       8.2.  CHEQ Object Syntax and Semantics  . . . . . . . . . . . .  13
       8.3.  CHEQ Protocol Details . . . . . . . . . . . . . . . . . .  14
     9.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .  14
     10. Informative References  . . . . . . . . . . . . . . . . . . .  14
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

  1.  Introduction

     AI Agents are applications built using Large Language Models (LLMs).
     AI Agents typically operate on behalf of some human or organization,
     and are capable of taking actions through the invocation of
     functions, also known as tools.  [I-D.rosenberg-ai-protocols]
     provides an overview of protocols and use cases for AI Agents.  It
     identifies a critical unmet need in the current protocol landscape -
     human confirmation.

     Consider the following use case: a user is chatting with a travel
     agent AI Agent.  This AI Agent helps users search for travel
     destinations based on preferences, compare flight and hotel costs,
     make bookings and adjust plans.  The user is discussing with the AI



  Rosenberg, et al.         Expires 22 April 2026                 [Page 2]


  Internet-Draft                    CHEQ                      October 2025


     Agent whether to take business or coach.  There is a long back and
     forth conversation about this.  Finally the user says, "go ahead and
     book it".  The AI Agent misinterprets the conversation, and chooses
     business class, despite the user's desire for coach.  It invokes a
     tool call on the flight system, acting on behalf of the user, and
     books the expensive flight that the user cannot afford.

     A more troubling use case is when a user interacts with a banking AI
     Agent, and requests transfer of funds.  To facilitate the tranfer,
     the user provides the AI agent with their account information.  The
     LLM hallucinates the account number, and results in funds being
     deposited into the wrong account.  This use case is doubly
     troublesome - not only has the user lost money, but they have leaked
     sensitive information (their account number) to an LLM.

     This document proposes a new protocol, called "Confirmation with
     Human in the Loop (HITL) Exchange of Quotations" - or CHEQ for short.
     The CHEQ protocol defines an object - the CHEQ - which memorializes a
     decision made by a human, and provides a cryptographic signature of
     it by an identity provides which authenticates the user.  It also
     defines a new protocol that allows for an API server to request
     information collection and/or confirmation outside of the scope of
     the LLM.

     Since CHEQ primarily involves the exchange of URLs within existing
     protocols, it is relatively easily embedded into emerging AI
     protocols, include the Model Context Protocol (MCP)
     (https://modelcontextprotocol.io/introduction
     (https://modelcontextprotocol.io/introduction)) which is being driven
     by Anthropic, the Agent2Agent (A2A) Protocol, driven by Google
     (https://google.github.io/A2A/#/documentation?id=agent2agent-
     protocol-a2a (https://google.github.io/
     A2A/#/documentation?id=agent2agent-protocol-a2a)) and now under
     governance of the Linux Foundation, or the Normalized API for AI
     Agent Calling Tools (N-ACT) [I-D.rosenberg-aiproto-nact].  CHEQ is
     specifically designed to fit into the elicitation model under
     consideration with MCP.

  2.  Requirements

     The requirements driving this protocol are as follows:

     *  The protocol must enable a human being to provide confirmation of
        an action that an AI Agent wishes to take

     *  The protocol must not depend on the LLM itself, so that it is not
        subject to LLM accuracy for proper operation




  Rosenberg, et al.         Expires 22 April 2026                 [Page 3]


  Internet-Draft                    CHEQ                      October 2025


     *  The protocol must provide cryptographic assurances that the human
        being approves the action

     *  The protocol must support a wide variety of actions, such as API
        invocations, workflows, batch operations, and so on.  It must not
        be specific to any particular API or API function

     *  The protocol must work with existing user authentication
        techniques

     *  The protocol must protect against AI agents replaying past
        confirmations

     *  The protocol must enable non-repudiation of confirmations made by
        a human being, so that a resource server has evidence that a user
        provided confirmation

     *  The protocol must enable resource servers to collect information
        from users needed to complete a tool call, without disclosing that
        information to an LLM (privacy)

     *  It must be possible to memorialize confirmations into an object,
        so that they can be exchanged between systems, along with the
        cryptographic content needed to validate user confirmation.  This
        is essential for non-repudiation

     *  It must be possible for the end user to clearly know that the
        confirmation step is outside of the scope of the LLM, to provide
        confidence to them that they are in fact performing confirmation
        that is not subject to LLM hallucination

     *  It must be possible for the user confirmation to be performed by
        trusted third parties, separate from the organization owning the
        resource server.  This is a potentially controversial requirement.
        It stems from the desire to put control in the hands of end users
        in selecting a provider that they trust to confirm actions that AI
        Agents are taking on their behalf.

     *  The protocol must be easily integrated with MCP, A2A, N-ACT and
        similar tool call protocols

  3.  Architectural Framework









  Rosenberg, et al.         Expires 22 April 2026                 [Page 4]


  Internet-Draft                    CHEQ                      October 2025


            +---------------------------------------+
            |                                       |
            |                                       |
     +------+-------+      +----------+       +-----v----+
     |              |      |          |       |          |
     | Confirmation |      | AI Agent +------>| Resource |
     | Server       |      |          |       | Server   |
     |              |      +----------+       |          |
     +--------------+           ^             +----------+
            ^                   |
            |              +----+-----+
            |              |          |
            +--------------+ User     |
                           | App      |
                           +----------+
                                ^
                                |
                           +----+-----+
                           |          |
                           | User     |
                           |          |
                           +----------+

                     Figure 1: CHEQ Architecture Framework

     The end user engages with an AI Agent via a User App. Often the user
     app is a browser application.  It could also be a thick desktop
     application.  The AI Agent typically runs on a server, though it
     could be running inside of the user app.  The AI agent includes an
     LLM along with an executor.  The executor formulates the inputs to
     the LLM, and processes its output.  The executor invokes APIs at the
     request of the LLM.  It does that by invoking the API on a resource
     server.  Such invocation could be via MCP, or could be direct API
     invocation.

     CHEQ introduces a new server, the Confirmation Server.  The
     Confirmation Server is responsible for rendering the information to
     be confirmed to the user, collecting their confirmation, and
     memorializing it by signing an object (the CHEQ object, which can
     then be passed back to the resource server.

     The confirmation server is a highly trusted entity in this system.
     The user trusts it to perform the confirmation operation.  We
     anticipate that users may desire to have this function centralized
     across many different API services, so that users have a single point
     of accountability and audit of decisions that have been confirmed.
     As an example, a trusted third party - something like Lets Encrypt -
     might run such a service, which users could adopt.



  Rosenberg, et al.         Expires 22 April 2026                 [Page 5]


  Internet-Draft                    CHEQ                      October 2025


     We also anticipate a common deployment model is that each resource
     provider has the confirmation server for its services, integrated
     into the resource server.

     CHEQ makes several key assumptions about the trust relationships in
     the system:

     1.  The user is known to both the resource service, and to the
         confirmtion service.

     2.  The user is capable of directly authenticating itself to the
         confirmation service, and therefore has a relationship with it,
         having an account of some sorts on it.

     3.  The resource service knows of, and trusts the confirmation
         service to perform confirmation.  The resource service can obtain
         an OAuth token, most likely via a client credential grant, on the
         resource service, in order to use the CHEQ protocol.

     The CHEQ protocol is relatively simple, with two parts.  The first is
     a means to convey the URIs from the API server to the AI agent and
     User application.  The second is protocol for the confirmation server
     to talk to the API server.  This second part is not needed when they
     are the same.

  4.  Overview of Operation

     The sequence diagram for the protocol is shown here:























  Rosenberg, et al.         Expires 22 April 2026                 [Page 6]


  Internet-Draft                    CHEQ                      October 2025


  participant user as "End User"
  participant exec as "AI Agent - Executor"
  participant llm as "AI Agent - LLM"
  participant confirm as "Confirmation Server"
  participant api as "API Server"

  user->exec: "please book flight "
  exec->llm: add user msg to context\nrun inference
  llm->exec: tool call\nAPI=book\nflight=UA1234\ndate=8 August 2025, 12:20 EDT
  exec->api: POST airline/book?{details}
  api->exec: 202 Accepted\nJSON w. resource URI, confirmation URI, result URI
  note right of exec: remember result URI
  exec->user: pass URIs to browser
  user->confirm: POST confirmation URI?resource URI
  user->confirm: login
  confirm->api: retrieve CHEQ object
  api->confirm: CHEQ object
  confirm->user: render information to confirm
  user->confirm: click confirmation button
  note right of confirm: sign cheq
  confirm->api: send signed cheq
  api->confirm: success
  confirm->user: confirmed

  note right of exec: polling
  exec->api: retrieve result from result URI
  api->exec: final result
  exec->llm: add result to context
  llm->exec: send msg\n"congrats your flight is booked"

                   Figure 2: Sequence Diagram for CHEQ

     There are three parts of the flow: trigger confirmation, performing
     confirmation, and finalizing.

  4.1.  Triggering Confirmation

     When an AI Agent makes a decision to perform a tool call of some
     sort, it uses MCP, N-ACT, or directly invokes the API on the server
     that provides the tool (which is what is shown in the diagram for
     ease of understanding).  For example, it might invoke a REST API for
     performing a flight booking on an airline.  The AI Agent will have
     some form of OAuth [I-D.ietf-oauth-v2-1] token, either granted by the
     user or perhaps associated with a service account.

     The server recognizes the invocation as being associated with an AI
     Agent.  It can do this using a number of different techniques,
     including the client ID associated with the access token, the source



  Rosenberg, et al.         Expires 22 April 2026                 [Page 7]


  Internet-Draft                    CHEQ                      October 2025


     IP address, or the service account used by the AI Agent.  Future
     solutions that formalize the authentication and identification of AI
     Agents, such as [I-D.meunier-web-bot-auth-architecture], can provide
     more robust ways to identify that the request is an AI Agent
     operating on a user's behalf.

     The resource server - the airline here - would be configured with
     policies that specify which API requests, when invoked by an AI
     Agent, require human confirmation.  That configuration could be
     provided ahead of time by the end user through the web site of the
     resource owner, or through policies defined by the provider
     themselves.  For example, the airline website might serve a UI which
     has radio buttons indicating that flight booking for flights over
     $100 require confirmation.  There are no new protocols required to do
     this.  CHEQ only requires that such policies have been configured
     ahead of time.

     The resource server would also be configured - by the end user or
     through its own administration - on what confirmation server it uses.
     This could be itself, or it could be a third party server.

     If the policy indicates that the resource server requires human
     confirmation, and the request is being made by an AI Agent, it
     responds with a 202 Accepted response.  This indicates that the
     server requires confirmation to complete the request.  The response
     includes a body, which we call the URI package, defined by this
     specification.  It includes three URIs which need to be conveyed
     between components.  The URIs are:

     1.  The confirmation server URI.  This is a raw URI, without any
         parameters.  The confirmation server must be one that the end
         user has a relationship with.  For example, if LetsEncrypt were
         to run a confirmation server, this might be
         https://confirmation.letsencrypt.org
         (https://confirmation.letsencrypt.org).  This is the URI that the
         user application will invoke in a browser to request user
         confirmation.

     2.  The resource URI.  This URI is minted by the resource server.
         This URI is used for the CHEQ protocol communication from the
         confirmation server to the resource server, as defined by this
         protocol.  The URI should reference the specific transaction
         which is being confirmed.  The resource server can embed that
         information into the URI however it likes.







  Rosenberg, et al.         Expires 22 April 2026                 [Page 8]


  Internet-Draft                    CHEQ                      October 2025


     3.  The result URI.  This URI is also minted by the resource server.
         It is used by the AI agent to obtain the final results of the API
         transaction.  It would also embed a transaction identifier so the
         resource server knows how to return the right response.

     The URI pack looks like this:

  {
     "confirmation uri" : "https://confirmation.letsencrypt.org",
     "resource uri" : "https://api.airline.com/confirmations/8asdjd8g9g0as",
     "result uri" : "https://api.airline.com/results/nn88kak0s0d8jj39sla"

  }

                        Figure 3: URI Pack Example

     The URI pack is passed to the AI agent (which extracts the result URI
     in particular) and then to the user application.  The means for such
     conveyance are flexible, and not constrained by this spec.  If there
     is an MCP server between the resource server and the AI Agent, the
     MCP server might perform a special form of elicitation, passing these
     parameters.  This would perhaps require an MCP extension.
     Alternatively, it can be added to N-ACT via an extension to that
     protocol.

  4.2.  Performing Confirmation

     Once the URI pack arrives at the user application, the user
     application extracts the confirmation URI, and performs a POST to the
     confirmation server, passing the resource URI as a parameter afer
     URI-encoding it.  The confirmation server needs this URI.

     The confirmation server first ensures that the end user is
     authenticated.

     The CHEQ protocol assumes that the confirmation server has a security
     relationship with the end user, such that the user is able to
     authenticate itself to the server.  The means for such authentication
     is outside of the scope of CHEQ, and any existing technqiues will
     suffice.  FUrthermore, CHEQ does not attempt to verify that the user
     is actually a human being.  It assumes that the authentication
     process is sufficient to demonstrate that the user is who they say
     they are.  If the user is not logged in, the confirmation server
     would request a login process.  The confirmation server does not need
     to be the login server.






  Rosenberg, et al.         Expires 22 April 2026                 [Page 9]


  Internet-Draft                    CHEQ                      October 2025


     The confirmation server will receive the resource URI in the POST
     from the user application.  It will use that URI, which points to the
     resource server, and invoke the retrieve cheq function on the
     resource server:

     GET {resource-server}/cheq

     It will authenticate using whatever service account it has with the
     resource provider.  The response comes back, and it contains a CHEQ
     object.  This object contains the information to be verified with the
     user.  The CHEQ object is signed by the resource provider, so it
     cannot be tampered with.

     The CHEQ includes the API being invoked (e.g., book flight), the
     input parameters (eg., the flight number and date), facts (e.g., the
     price of the flight) and explanatory information meant for human
     consumption (e.g "this is the overnight flight from Newark to
     Madrid").

     The following is an example of what the CHEQ looks like:

  {
     "version" : 1.0,
     "operation" : "https://airline.com/api/v1/book-flight",
     "operation name" : "Book airline",

     "inputs" : {
        "parameters" : [
           {
              "parameter name" : "flight number",
              "parameter description" : "The overnight flight from EWR to MAD",
              "parameter value" : "UA23"
           },
           {
              "parameter name" : "flight date",
              "parameter value" : "8 August 2025, 12:20 EDT"
           },
           {
              "parameter name" : "flight cost",
              "parameter value" : "$1200 USD"
           },

        ]

     },

     "date" : "July 23, 2025, 11:59 UTC",
  }



  Rosenberg, et al.         Expires 22 April 2026                [Page 10]


  Internet-Draft                    CHEQ                      October 2025


                          Figure 4: CHEQ Object

     In the CHEQ object, the parameter values are the actual values which
     will show up in the API invocations.  The names and descriptions are
     used to provide information to the end user.  THey represent
     important information that helps the user decide whether to confirm
     or not, and because they factor into decision making, also need to be
     memorialized into the object and its signatures.

     The names and descriptions need to be provided in the language
     preferred by the end user.  Because the resource server knows the end
     user, it can use whatever its default language is for that user.

     The confirmation server renders a confirmation UI to the user.  The
     user can decide to accept or reject it.  If the user accepts, the
     confirmation server adds its own signature (signature details and
     multi-signature syntax TBD).  Else, the user rejects it.

     Based on the user decision, the confirmation server does one of two
     things.  If the user accepted, the newly signed CHEQ is posted to the
     resource server:

     POST {resource URI}?accept {body contains signed CHEQ}

     Else, if the user rejected it:

     POST {resource URI}?reject

     The resource server then updates the state of the resource
     accordingly.

  4.3.  Finalizing

     The final step of the process is conveyance of the final result to
     the AI agent.

     The AI Agent will poll the resource server for updates.
     Alternatively, if MCP is used, the MCP server will poll for updates,
     and then provide an update to the AI Agent once the finalized result
     is obtained.  If N-ACT is being used, it can be extended to add
     support for this API.

     Once the resource server has receive the acceptance (or rejection),
     it can respond to request from the AI Agent with the result, and the
     AI agent can proceed.






  Rosenberg, et al.         Expires 22 April 2026                [Page 11]


  Internet-Draft                    CHEQ                      October 2025


  5.  Using CHEQ for Data Privacy

     The CHEQ protocol has an important property that the confirmation
     process happens outside of the scope of the LLM.  This enables CHEQ
     to be used in cases where the user does not wish to provide sensitive
     information to the AI Agent.

     In these cases, the confirmation server function is subsumed into the
     resource server.

     Consider the following example.  Instead of a flight booking, the
     user is using an AI Agent to transfer funds between bank accounts.
     This requires highly sensitive information - most notably the origin
     and destination account numbers.  The user does not wish to expose
     this information to the AI Agent, and specificaly, to the underlying
     LLM.

     To address this, the banking service can implement an API for
     transferrig funds, which is meant specifically for usage with CHEQ.
     This API would not take the parameters normally required for a
     transfer - no account numbers, no dollar amounts.  Instead, the API
     is just "transfer funds".  This API can be turned into a tool by the
     MCP server, which the AI Agent can decide to invoke.  When it is
     invoked, the banking server immediately responds with the 202 and
     passes the URI package.  In this use case, the confirmation server is
     the same as the resource server.  When the user application connects
     to the resource server to perform the confirmation, the resulting UI
     can be used for the actual data collection.  Once the data is
     collected, the AI Agent gets the results - merely that the data was
     transferred.  In this application of the CHEQ protocol, only the URI
     pack is ever sent on the wire.  The CHEQ object never needs to be
     generated, because the resource and confirmation server are the same.
     Indeed, the CHEQ would have contained sensitive information (the
     account numbers).

     In this case, we have enabled AI agents to work with users on complex
     tasks which require data collection that can be hidden from the AI
     Agent, achieving data privacy.

     The decision on which APIs require private data, and require CHEQ to
     be used, is made by the resource service.










  Rosenberg, et al.         Expires 22 April 2026                [Page 12]


  Internet-Draft                    CHEQ                      October 2025


  6.  Usage with MCP and A2A and N-ACT

     CHEQ can easily be integrated into MCP, so that an MCP server sits
     between the AI Agent and the resource server in the diagram above.
     It requires an extension to the elicitation specifications, enabling
     the URI pack to be transferred from the resource server, through MCP,
     to the AI Agent.

     In a similar way, CHEQ can be integrated into A2A.  If Agent 1
     connects to Agent 2, and Agent 2 wishes to request user confirmation,
     Agent 2 can take the URI pack, pass it backwards through A2A to agent
     1, which passes it to its user.

     CHEQ can also easily be added to N-ACT, by adding it directly to that
     protocol.

  7.  Usage with Voice Interfaces

     Modern AI Agents can also make use of voice interfaces towards the
     user.  The CHEQ protocol works equally well in this case, with a
     slightly different flow.

     Consider the User Application in this case as a voice gateway,
     receiving the voice traffic from the user and integrating it into the
     AI Agent.  This function may be co-located with the AI Agent, or it
     could be a separate component that (for example) is doing speech to
     text and speech synthesis in front of a text-based AI Agent.

     In either case, when the user application receives the URI pack,
     instead of passing this onto the user's web browser, it would connect
     to the confirmation server and retrieve a "raw" version of the CHEQ,
     read it out over voice, gain user appoval via voice, and then post
     that to the confirmation server.  This does require the confirmation
     server to support a flow which is amenable to rendering as voice, not
     HTML.

  8.  Detailed Protocol Specification

  8.1.  URI Pack Syntax and Semantics

     Details to be filled in.

  8.2.  CHEQ Object Syntax and Semantics

     Details to be filled in






  Rosenberg, et al.         Expires 22 April 2026                [Page 13]


  Internet-Draft                    CHEQ                      October 2025


  8.3.  CHEQ Protocol Details

     Details to be filled in

  9.  Conclusions

     The CHEQ protocol provides a way for end users to confirm actions
     taken by AI Agents.  It does so outside of the LLM and AI Agent
     itself, eliminating any risk of the LLM hallucinating a tool call
     that the user does not desire.  The usage of out-of-band UI also
     provides a technique for data privacy, enabling AI agents to perform
     sensitive operations (like banking transfers) where the user does not
     wish to provide the sensitive information to the AI Agent.

  10.  Informative References

     [I-D.ietf-oauth-v2-1]
                Hardt, D., Parecki, A., and T. Lodderstedt, "The OAuth 2.1
                Authorization Framework", Work in Progress, Internet-
                Draft, draft-ietf-oauth-v2-1-14, 20 October 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
                v2-1-14>.

     [I-D.meunier-web-bot-auth-architecture]
                Meunier, T., "HTTP Message Signatures for automated
                traffic Architecture", Work in Progress, Internet-Draft,
                draft-meunier-web-bot-auth-architecture-03, 29 August
                2025, <https://datatracker.ietf.org/doc/html/draft-
                meunier-web-bot-auth-architecture-03>.

     [I-D.rosenberg-ai-protocols]
                Rosenberg, J. and C. F. Jennings, "Framework, Use Cases
                and Requirements for AI Agent Protocols", Work in
                Progress, Internet-Draft, draft-rosenberg-ai-protocols-00,
                5 May 2025, <https://datatracker.ietf.org/doc/html/draft-
                rosenberg-ai-protocols-00>.

     [I-D.rosenberg-aiproto-nact]
                Rosenberg, J. and P. White, "Normalized API for AI Agents
                Calling Tools (N-ACT)", Work in Progress, Internet-Draft,
                draft-rosenberg-aiproto-nact-00, 19 October 2025,
                <https://datatracker.ietf.org/doc/html/draft-rosenberg-
                aiproto-nact-00>.

  Authors' Addresses

     Jonathan Rosenberg
     Five9



  Rosenberg, et al.         Expires 22 April 2026                [Page 14]


  Internet-Draft                    CHEQ                      October 2025


     Email: jdrosen@jdrosen.net


     Pat White
     Bitwave
     Email: pat.white@traego.com


     Cullen Jennings
     Cisco
     Email: fluffy@cisco.com








































  Rosenberg, et al.         Expires 22 April 2026                [Page 15]


name: draft-ietf-dnsop-ds-automation
rev: 04
title: Operational Recommendations for DS Automation
time: 2026-02-27T11:48:18Z
group_uri: /api/v1/group/group/1452/
expires: 2026-08-17T12:02:44Z
shepherd: /api/v1/person/email/shuque@gmail.com/
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/", "/api/v1/doc/state/43/"]
categories: ["Other AI/agent"]
tags: []
fetched_at: 2026-02-27T22:56:05.127628+00:00
abstract:
  Enabling support for automatic acceptance of DS parameters from the
     Child DNS operator (via RFCs 7344, 8078, 9615) requires the parental
     agent, often a registry or registrar, to make a number of technical
     decisions around acceptance checks, error and sucess reporting, and
     multi-party issues such as concurrent updates.  This document
     describes how these points are best addressed in practice.

full_text:
  DNSOP Working Group                                             S. Sheng
  Internet-Draft                                                          
  Intended status: Best Current Practice                      P. Thomassen
  Expires: 17 August 2026                                            deSEC
                                                          13 February 2026


               Operational Recommendations for DS Automation
                     draft-ietf-dnsop-ds-automation-04

  Abstract

     Enabling support for automatic acceptance of DS parameters from the
     Child DNS operator (via RFCs 7344, 8078, 9615) requires the parental
     agent, often a registry or registrar, to make a number of technical
     decisions around acceptance checks, error and sucess reporting, and
     multi-party issues such as concurrent updates.  This document
     describes how these points are best addressed in practice.

  Discussion Venues

     This note is to be removed before publishing as an RFC.

     Discussion of this document takes place on the Domain Name System
     Operations Working Group mailing list (dnsop@ietf.org), which is
     archived at https://mailarchive.ietf.org/arch/browse/dnsop/.

     Source for this draft and an issue tracker can be found at
     https://github.com/peterthomassen/draft-shetho-dnsop-ds-automation.

  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 17 August 2026.





  Sheng & Thomassen        Expires 17 August 2026                 [Page 1]


  Internet-Draft                DS Automation                February 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.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Requirements Notation . . . . . . . . . . . . . . . . . .   4
     2.  Acceptance Checks and Safety Measures . . . . . . . . . . . .   4
       2.1.  Recommendations . . . . . . . . . . . . . . . . . . . . .   4
       2.2.  Analysis  . . . . . . . . . . . . . . . . . . . . . . . .   5
         2.2.1.  Continuity of Resolution  . . . . . . . . . . . . . .   5
         2.2.2.  TTLs and Caching  . . . . . . . . . . . . . . . . . .   6
         2.2.3.  CDS vs. CDNSKEY . . . . . . . . . . . . . . . . . . .   6
     3.  Reporting and Transparency  . . . . . . . . . . . . . . . . .   7
       3.1.  Recommendations . . . . . . . . . . . . . . . . . . . . .   8
       3.2.  Analysis  . . . . . . . . . . . . . . . . . . . . . . . .   8
     4.  Registration Locks  . . . . . . . . . . . . . . . . . . . . .  10
       4.1.  Recommendations . . . . . . . . . . . . . . . . . . . . .  10
       4.2.  Analysis  . . . . . . . . . . . . . . . . . . . . . . . .  11
         4.2.1.  Registrar vs. Registry Lock . . . . . . . . . . . . .  11
         4.2.2.  Detailed Rationale  . . . . . . . . . . . . . . . . .  12
     5.  Multiple Submitting Parties . . . . . . . . . . . . . . . . .  13
       5.1.  Recommendations . . . . . . . . . . . . . . . . . . . . .  13
       5.2.  Analysis  . . . . . . . . . . . . . . . . . . . . . . . .  14
         5.2.1.  Necessity of Non-automatic Updates  . . . . . . . . .  14
         5.2.2.  Impact of Non-automatic Updates: When to Suspend
                 Automation  . . . . . . . . . . . . . . . . . . . . .  15
         5.2.3.  Concurrent Automatic Updates  . . . . . . . . . . . .  16
     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
     8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  17
     9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
       9.1.  Normative References  . . . . . . . . . . . . . . . . . .  17
       9.2.  Informative References  . . . . . . . . . . . . . . . . .  19
     Appendix A.  Terminology  . . . . . . . . . . . . . . . . . . . .  20
     Appendix B.  Recommendations Overview . . . . . . . . . . . . . .  21
       B.1.  Acceptance Checks and Safety Measures . . . . . . . . . .  21



  Sheng & Thomassen        Expires 17 August 2026                 [Page 2]


  Internet-Draft                DS Automation                February 2026


       B.2.  Reporting and Transparency  . . . . . . . . . . . . . . .  22
       B.3.  Registration Locks  . . . . . . . . . . . . . . . . . . .  22
       B.4.  Multiple Submitting Parties . . . . . . . . . . . . . . .  22
     Appendix C.  Change History (to be removed before publication)  .  23
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  24

  1.  Introduction

     [RFC7344], [RFC8078], [RFC9615] automate DNSSEC delegation trust
     maintenance by having the child publish CDS and/or CDNSKEY records
     which indicate the delegation's desired DNSSEC parameters ("DS
     automation").

     Parental Agents using these protocols have to make a number of
     technical decisions relating to issues of acceptance checks, timing,
     error reporting, locks, etc.  Additionally, when using the RRR model
     (as is common amongst top-level domains), both the registrar and the
     registry can effect parent-side changes to the delegation.  In such a
     situation, additional opportunities for implementation differences
     arise.

     Not all existing DS automation deployments have made the same choices
     with respect to these questions, leading to somewhat inconsistent
     behavior.  From the perspective of a domain holder with domain names
     under various TLDs, this may be unexpected and confusing.

     New deployments of DS automation therefore SHOULD follow the
     recommendations set out in this document, both to achieve a more
     uniform treatment across suffixes — minimizing user surprise — and to
     prevent disruption of DNS and DNSSEC functionality.  The
     recommendations are intended to provide baseline safety and
     uniformity of behavior across parents.  Registries with additional
     requirements on DS update checks MAY implement any additional checks
     in line with local policy.

     In the following sections, operational questions are first raised and
     answered with the corresponding recommendations.  Each section is
     concluded with an analysis of its recommendations, and related
     considerations.  A combined view of the recommendations from all
     sections is given in Appendix B.

     Readers are expected to be familiar with DNSSEC
     [RFC9364][RFC9615][RFC9859].  For terminology, see Appendix A.








  Sheng & Thomassen        Expires 17 August 2026                 [Page 3]


  Internet-Draft                DS Automation                February 2026


  1.1.  Requirements Notation

     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.  Acceptance Checks and Safety Measures

     This section provides recommendations to address the following
     questions:

     *  What kind of acceptance checks should be performed on DS
        parameters?

     *  Should these checks be performed upon acceptance, or also
        continually when in place?

     *  How do TTLs and caching impact DS provisioning?  How important is
        timing in a child key change?

     *  Are parameters for DS automation best conveyed as CDNSKEY or CDS
        records, or both?

  2.1.  Recommendations

     1.  Entities performing automated DS maintenance SHOULD verify

         a.  the unambigious intent of each DS update request as per
             [I-D.ietf-dnsop-cds-consistency], by checking its consistency
             both

             *  between any published CDS and CDNSKEY records, and

             *  across all authoritative nameservers in the delegation,

             and

         b.  that the resulting DS record set would allow continued DNSSEC
             validation if deployed,

         and cancel the update if the verifications do not succeed.








  Sheng & Thomassen        Expires 17 August 2026                 [Page 4]


  Internet-Draft                DS Automation                February 2026


     2.  Parent-side entities (such as registries) SHOULD reduce a DS
         record set's TTL to a value between 5–15 minutes when the set of
         records is changed, and restore the normal TTL value at a later
         occasion (but not before the previous DS RRset's TTL has
         expired).

     3.  DNS operators SHOULD publish both CDNSKEY records as well as CDS
         records, and follow best practice for the choice of hash digest
         type [DS-IANA].

  2.2.  Analysis

  2.2.1.  Continuity of Resolution

     To maintain the basic resolution function, it is important to avoid
     the deployment of flawed DS record sets in the parent zone.  It is
     therefore desirable for the Parent to verify that the DS record set
     resulting from an automated (or even manual) update does not break
     DNSSEC validation if deployed, and otherwise cancel the update.

     This is best done by

     1.  verifying that consistent CDS/CDNSKEY responses are served by all
         of the delegation's nameservers [I-D.ietf-dnsop-cds-consistency];

     2.  verifying that the resulting DS RRset does not break the
         delegation if applied ([RFC7344], Section 4.1), i.e., that it
         provides at least one valid path for validators to use
         ([RFC6840], Section 5.11).  This is the case if the child's
         DNSKEY RRset has a valid RRSIG signature from a key that is
         referenced by at least one DS record, with the digest type and
         signing algorithm values designated as "RECOMMENDED" or "MUST" in
         the "Use for DNSSEC Validation" columns of the relevant IANA
         registries ([DS-IANA] and [DNSKEY-IANA]).  (These checks need not
         be enforced when provisioning DS records manually in order to
         enable the use other digest types or algorithms for potentially
         non-interoperable purposes.)

     Even without an update being requested, Parents MAY occasionally
     check whether the current DS contents would still be acceptable if
     they were newly submitted in CDS/CDNSKEY form (see Section 2).  Any
     failures — such as a missing DNSKEY due to improper rollover timing
     ([RFC6781], Section 4.1), or changed algorithm requirements — MAY be
     communicated in line with Section 3.  The existing DS record set MUST
     NOT be altered or removed as a result of such checks.






  Sheng & Thomassen        Expires 17 August 2026                 [Page 5]


  Internet-Draft                DS Automation                February 2026


  2.2.2.  TTLs and Caching

     To further reduce the impact of any misconfigured DS record set — be
     it from automated or from manual provisioning — the option to quickly
     roll back the delegation's DNSSEC parameters is of great importance.
     This is achieved by setting a comparatively low TTL on the DS record
     set in the parent domain, at the cost of reduced resiliency against
     nameserver unreachability due to the earlier expiration of cached
     records.  The availability risk can be mitigated by limiting such
     TTLs to a brief time period after a change to the DS configuration,
     during which rollbacks are most likely to occur.

     Registries therefore should significantly lower the DS RRset's TTL
     for some time following an update.  Pragmatic values for the reduced
     TTL value range between 5–15 minutes.  Such low TTLs might be
     expected to cause increased load on the corresponding authoritative
     nameservers; however, recent research has demonstrated them to have
     negligible impact on the overall load of a registry's authoritative
     nameserver infrastructure [LowTTL].

     The reduction should be in effect at least for a couple of days and
     until the previous DS record set has expired from caches, that is,
     the period during which the low-TTL is applied typically will
     significantly exceed the normal TTL value.  When using EPP, the
     server MAY advertise its TTL policy via the domain <info> command
     described in [RFC9803], Section 2.1.1.2.

     While this approach enables quick rollbacks, timing of the desired DS
     update process itself is largely governed by the previous DS RRset's
     TTL, and therefore does not generally benefit from an overall speed-
     up.  Note also that nothing is gained from first lowering the TTL of
     the old DS RRset: such an additional step would, in fact, require
     another wait period while resolver caches adjust.  For the sake of
     completeless, there likewise is no point to increasing any DS TTL
     values beyond their normal value.

  2.2.3.  CDS vs. CDNSKEY

     DS records can be generated from information provided either in DS
     format (CDS) or in DNSKEY format (CDNSKEY).  While the format of CDS
     records is identical to that of DS records (so the record data be
     taken verbatim), generation of a DS record from CDNSKEY information
     involves computing a hash.

     Whether a Parent processes CDS or CDNSKEY records depends on their
     preference:





  Sheng & Thomassen        Expires 17 August 2026                 [Page 6]


  Internet-Draft                DS Automation                February 2026


     *  Processing (and storing) CDNSKEY information allows the Parent to
        control the choice of hash algorithms.  The Parent may then
        unilaterally regenerate DS records with a different choice of hash
        algorithm(s) whenever deemed appropriate.

     *  Processing CDS information allows the Child DNS operator to
        control the hash digest type used in DS records, enabling the
        Child DNS operator to deploy (for example) experimental hash
        digests and removing the need for registry-side changes when
        additional digest types become available.

     The need to make a choice in the face of this dichotomy is not
     specific to DS automation: even when DNSSEC parameters are relayed to
     the Parent through conventional channels, the Parent has to make some
     choice about which format(s) to accept.

     As there exists no protocol for Child DNS Operators to discover a
     Parent's input format preference, it seems best for interoperability
     to publish both CDNSKEY as well as CDS records, in line with
     [RFC7344], Section 5.  The choice of hash digest type should follow
     current best practice [DS-IANA].

     Publishing the same information in two different formats is not
     ideal.  Still, it is much less complex and costly than burdening the
     Child DNS operator with discovering each Parent's current policy;
     also, it is very easily automated.  Operators should ensure that
     published RRsets are consistent with each other.

     If both RRsets are published, Parents are expected to verify
     consistency between them [I-D.ietf-dnsop-cds-consistency], as
     determined by matching CDS and CDNSKEY records using hash digest
     algorithms whose support is mandatory [DS-IANA].  (Consistency of CDS
     records with optional or unsupported hash digest types need not be
     enforced.)

     By rejecting the DS update if RRsets are found to be inconsistent,
     Child DNS operators are held responsible when publishing
     contradictory information.  Note that this does not imply a
     restriction to the hash digest types found in the CDS RRset: if no
     inconsistencies are found, the parent can publish DS records with
     whatever digest type(s) it prefers.

  3.  Reporting and Transparency

     This section provides recommendations to address the following
     question:





  Sheng & Thomassen        Expires 17 August 2026                 [Page 7]


  Internet-Draft                DS Automation                February 2026


     *  Should a failed (or even successful) DS update trigger a
        notification to anyone?

  3.1.  Recommendations

     1.  For certain DS updates (see analysis (Section 3.2)) and for DS
         deactivation, relevant points of contact known to the zone
         operator SHOULD be notified.

     2.  For error conditions, the child DNS operator and the domain's
         technical contact (if applicable) SHOULD be notified first.  The
         registrant SHOULD NOT be notified unless the problem persists for
         a prolonged amount of time (e.g., three days).

     3.  Child DNS operators SHOULD be notified using a report query
         [RFC9567] to the agent domain as described in ([RFC9859],
         Section 4).  Notifications to humans (domain holder) will be
         performed in accordance with the communication preferences
         established with the parent-side entity (registry or registrar).
         The same condition SHOULD NOT be reported unnecessarily
         frequently to the same recipient.

     4.  In the RRR model, registries performing DS automation SHOULD
         inform the registrar of any DS record changes via the EPP Change
         Poll Extension [RFC8590] or a similar channel.

     5.  The currently active DS configuration SHOULD be made accessible
         to the registrant (or their designated party) through the
         customer portal available for domain management.  The DS update
         history MAY be made available in the same way.

  3.2.  Analysis

     When accepting or rejecting a DS update, it cannot be assumed that
     relevant parties are aware of what's happening.  For example, a
     registrar may not know when an automatic DS update is performed by
     the registry.  Similarly, a Child DNS operator may not be aware when
     their CDS/CDNSKEY RRsets are out of sync across nameservers, thus
     being ignored.

     To help involved parties act appropriately and in a timely manner,
     entities performing automated DS maintenance should report on
     conditions they encounter.  The following success situations may be
     of particular interest:

     1.  A DS RRset has been provisioned

         a.  manually;



  Sheng & Thomassen        Expires 17 August 2026                 [Page 8]


  Internet-Draft                DS Automation                February 2026


         b.  due to commencing DS automation (either via DNSSEC
             bootstrapping, or for the first time after a manual change;
             see Section 5);

         c.  automatically, as an update to an existing DS RRset that had
             itself been automatically provisioned.

     2.  The DS RRset has been removed

         a.  manually;

         b.  automatically, using a delete signal ([RFC8078], Section 4).

     In addition, there are error conditions worthy of being reported:

     3.  A pending DS update cannot be applied due to an error condition.
         There are various scenarios where an automated DS update might
         have been requested, but can't be fulfilled.  These include:

         a.  The new DS record set would break validation/resolution or is
             not acceptable to the Parent for some other reason (see
             Section 2).

         b.  A lock prevents DS automation (see Section 4).

     4.  No DS update is due, but it was determined that the Child zone is
         no longer compatible with the existing DS record set (e.g., DS
         RRset only references non-existing keys).

     For these reportworthy cases, the entity performing DS automation
     would be justified to attempt communicating the situation.  Potential
     recipients are:

     *  Child DNS operator, preferably by making a report query [RFC9567]
        to the agent domain listed in the EDNS0 Report-Channel option of
        the DS update notification that triggered the DS update
        ([RFC9859], Section 4), or else via email to the address contained
        in the child zone's SOA RNAME field (see Sections 3.3.13 and 8 of
        [RFC1035]);

     *  Registrar (if DS automation is performed by the registry);

     *  Registrant (domain holder; in non-technical language, such as
        "DNSSEC security for your domain has been enabled and will be
        maintained automatically") or technical contact, in accordance
        with the communication preferences established with the parent-
        side entity.




  Sheng & Thomassen        Expires 17 August 2026                 [Page 9]


  Internet-Draft                DS Automation                February 2026


     For manual updates (case 1a), commencing DS automation (case 1b), and
     deactivating DNSSEC (case 2), it seems worthwhile to notify both the
     domain's technical contact (if applicable) and the registrant.  This
     will typically lead to one notification during normal operation of a
     domain.  (Case 1c, the regular operation of automation, is not an
     interesting condition to report to a human.)

     For error conditions (cases 3 and 4), the registrant need not always
     be involved.  It seems advisable to first notify the domain's
     technical contact and the DNS operator serving the affected Child
     zone, and only if the problem persists for a prolonged amount of time
     (e.g., three days), notify the registrant.

     When the RRR model is used and the registry performs DS automation,
     the registrar should always stay informed of any DS record changes,
     e.g., via the EPP Change Poll Extension [RFC8590].

     The same condition SHOULD NOT be reported unnecessarily frequently to
     the same recipient (e.g., no more than twice in a row).  For example,
     when CDS and CDNSKEY records are inconsistent and prevent DS
     initialization, the registrant may be notified twice.  Additional
     notifications may be sent with some back-off mechanism (in increasing
     intervals).

     The current DS configuration SHOULD be made accessible to the
     registrant (or their designated party) through the customer portal
     available for domain management.  Ideally, the history of DS updates
     would also be available.  However, due to the associated state
     requirements and the lack of direct operational impact,
     implementation of this is OPTIONAL.

  4.  Registration Locks

     This section provides recommendations to address the following
     question:

     *  How does DS automation interact with other registration state
        parameters, such as registration locks?

  4.1.  Recommendations

     1.  To secure ongoing operations, automated DS maintenance SHOULD NOT
         be suspended based on a registrar update lock alone (such as EPP
         status clientUpdateProhibited).

     2.  When performed by the registry, automated DS maintenance SHOULD
         NOT be suspended based on a registry update lock alone (such as
         EPP status serverUpdateProhibited).



  Sheng & Thomassen        Expires 17 August 2026                [Page 10]


  Internet-Draft                DS Automation                February 2026


  4.2.  Analysis

     Registries and registrars can set various types of locks for domain
     registrations, usually upon the registrant's request.  An overview of
     standardized locks using EPP, for example, is given in Section 2.3 of
     [RFC5731].  Some registries may offer additional (or other) types of
     locks whose meaning and set/unset mechanisms are defined according to
     a proprietary policy.

     While some locks clearly should have no impact on DS automation (such
     as transfer or deletion locks), other types of locks, in particular
     "update locks", deserve a closer analysis.

  4.2.1.  Registrar vs. Registry Lock

     A registrar-side update lock (such as clientUpdateProhibited in EPP)
     protects against various types of accidental or malicious change
     (like unintended changes through the registrar's customer portal).
     Its security model does not prevent the registrar's (nor the
     registry's) actions.  This is because a registrar-side lock can be
     removed by the registrar without an out-of-band interaction.

     Under such a security model, no tangible security benefit is gained
     by preventing automated DS maintenance based on a registrar lock
     alone, while preventing it would make maintenance needlessly
     difficult.  It therefore seems reasonable not to suspend automation
     when such a lock is present.

     When a registry-side update lock is in place, the registrar cannot
     apply any changes (for security or delinquency or other reasons).
     However, it does not protect against changes made by the registry
     itself.  This is exemplified by the serverUpdateProhibited EPP
     status, which demands only that the registrar's "[r]equests to update
     the object [...] MUST be rejected" ([RFC5731], Section 2.3).  This
     type of lock therefore precludes DS automation by the registrar,
     while registry-side automation may continue.

     DS automation by the registry further is consistent with [RFC5731],
     Section 2.3, which explicitly notes that an EPP server (registry) may
     override status values set by an EPP client (registrar), subject to
     local server policies.  The risk that DS changes from registry-side
     DS automation might go unnoticed by the registrar is mitigated by
     sending change notifications to the registrar; see Recommendation 4
     of Section 3.







  Sheng & Thomassen        Expires 17 August 2026                [Page 11]


  Internet-Draft                DS Automation                February 2026


  4.2.2.  Detailed Rationale

     Pre-DNSSEC, it was possible for a registration to be set up once,
     then locked and left alone (no maintenance required).  With DNSSEC
     comes a change to this operational model: the configuration may have
     to be maintained in order to remain secure and operational.  For
     example, the Child DNS operator may switch to another signing
     algorithm if the previous one is no longer deemed appropriate, or
     roll its SEP key for other reasons.  Such changes entail updating the
     delegation's DS records.

     If authenticated, these operations do not qualify as accidental or
     malicious change, but as legitimate and normal activity for securing
     ongoing operation.  The CDS/CDNSKEY method provides an automatic,
     authenticated means to convey DS update requests.  The resulting DS
     update is subject to the parent's acceptance checks; in particular,
     it is not applied when it would break the delegation (see Section 2).

     Given that registrar locks protect against unintended changes (such
     as through the customer portal) while not preventing actions done by
     the registrar (or the registry) themself, such a lock is not suitable
     for defending against actions performed illegitimately by the
     registrar or registry (e.g., due to compromise).  Any attack on the
     registration data that is feasible in the presence of a registrar
     lock is also feasible regardless of whether DS maintenance is done
     automatically; in other words, DS automation is orthogonal to the
     attack vector that a registrar lock protects against.

     Considering that automated DS updates are required to be
     authenticated and validated for correctness, it thus appears that
     honoring such requests, while in the registrant's interest, comes
     with no additional associated risk.  Suspending automated DS
     maintenance therefore does not seem justified.

     Following this line of thought, some registries (e.g., .ch/.cz/.li)
     today perform automated DS maintenance even when an "update lock" is
     in place.  Registries offering proprietary locks should carefully
     consider for each lock whether its scope warrants suspension.

     In case of a domain not yet secured with DNSSEC, automatic DS
     initialization is not required to maintain ongoing operation;
     however, authenticated DNSSEC bootstrapping [RFC9615] might be
     requested.  Besides being in the interest of security, the fact that
     a Child is requesting DS initialization through an authenticated
     method expresses the registrant's intent to have the delegation
     secured.





  Sheng & Thomassen        Expires 17 August 2026                [Page 12]


  Internet-Draft                DS Automation                February 2026


     Further, some domains are equipped with an update lock by default.
     Not honoring DNSSEC bootstrapping requests then imposes an additional
     burden on the registrant, who has to unlock and relock the domain in
     order to facilitate DS provisioning after registration.  This is a
     needless cost especially for large domain portfolios.  It is also
     unexpected, as the registrant already has arranged for the necessary
     CDS/CDNSKEY records to be published.  It therefore appears that DS
     initialization and rollovers should be treated the same way with
     respect to locks.

  5.  Multiple Submitting Parties

     This section provides recommendations to address the following
     questions:

     *  How are conflicts resolved when DS parameters are accepted through
        multiple channels (e.g. via a conventional channel and via
        automation)?

     *  In case both the registry and the registrar are automating DS
        updates, how to resolve potential collisions?

  5.1.  Recommendations

     1.  Registries and registrars SHOULD provide another (e.g., manual)
         channel for DS maintenance in order to enable recovery when the
         Child has lost access to its signing key(s).  This out-of-band
         channel is also needed when a DNS operator does not support DS
         automation or refuses to cooperate.

     2.  DS update requests SHOULD be executed immediately after
         verification of their authenticity, regardless of whether they
         are received in-band or via an out-of-band channel.

     3.  When processing a CDS/CDNSKEY "delete" signal to remove the
         entire DS record set ([RFC8078], Section 4), DS automation SHOULD
         NOT be suspended.  For all other removal requests (such as when
         received via EPP or a web form), DS automation SHOULD be
         suspended until a new DS record set has been provisioned, in
         order to prevent accidental re-initialization when the registrant
         intended to disable DNSSEC.

     4.  Whenever a non-empty DS record set is provisioned, through
         whichever channel, DS automation SHOULD NOT (or no longer) be
         suspended (including after an earlier removal).






  Sheng & Thomassen        Expires 17 August 2026                [Page 13]


  Internet-Draft                DS Automation                February 2026


     5.  In the RRR model, a registry SHOULD NOT automatically initialize
         DS records when it is known that the registrar does not provide a
         way for the domain holder to later disable DNSSEC.  If the
         registrar has declared to be performing automated DS maintenance,
         the registry SHOULD publish the registrar's [RFC9859]
         notification endpoint (if applicable) and refrain from registry-
         side DS automation.

  5.2.  Analysis

     In the RRR model, there are multiple channels through which DS
     parameters can be accepted:

     *  The registry can retrieve information about an intended DS update
        automatically from the Child DNS Operator and apply the update
        directly;

     *  The registrar can retrieve the same and relay it to the registry;

     *  The registrar can obtain the information from the registrant
        through another channel (such as a non-automated "manual update"
        via webform submission), and relay it to the registry.

     There are several considerations in this context, as follows.

  5.2.1.  Necessity of Non-automatic Updates

     Under special circumstances, it may be necessary to perform a non-
     automatic DS update.  One important example is when the key used by
     for authentication of DS updates is destroyed: in this case, an
     automatic key rollover is impossible as the Child DNS operator can no
     longer authenticate the associated information.  Another example is
     when several providers are involved, but one no longer cooperates
     (e.g., when removing a provider from a multi-provider setup).
     Disabling manual DS management interfaces is therefore strongly
     discouraged.

     Similarly, when the registrar is known to not support DNSSEC (or to
     lack a DS provisioning interface), it seems adequate for registries
     to not perform automated DS maintenance, in order to prevent
     situations in which a misconfigured delegation cannot be repaired by
     the registrant.









  Sheng & Thomassen        Expires 17 August 2026                [Page 14]


  Internet-Draft                DS Automation                February 2026


  5.2.2.  Impact of Non-automatic Updates: When to Suspend Automation

     When an out-of-band (e.g., manual) DS update is performed while CDS/
     CDNSKEY records referencing the previous DS RRset's keys are present,
     the delegation's DS records may be reset to their previous state at
     the next run of the automation process.  This section discusses in
     which situations it is appropriate to suspend DS automation after
     such a non-automatic update.

     One option is to suspend DS automation after a manual DS update, but
     only until a resumption signal is observed.  In the past, it was
     proposed that seeing an updated SOA serial in the child zone may
     serve as a resumption signal.  However, as any arbitrary modification
     of zone contents — including the regular updating of DNSSEC signature
     validity timestamps — typically causes a change in SOA serial,
     resumption of DS automation after a serial change comes with a high
     risk of surprise.  Additional issues arise if nameservers have
     different serial offsets (e.g., in a multi-provider setup).  It is
     therefore advised to not follow this practice.

     Note also that "automatic rollback" due to old CDS/CDNSKEY RRsets can
     only occur if they are signed with a key authorized by one of new DS
     records.  Acceptance checks described in Section 2 further ensure
     that updates do not break validation.

     Removal of a DS record set is triggered either through a CDS/CDNSKEY
     "delete" signal observed by the party performing the automation
     ([RFC8078], Section 4), or by receiving a removal request out-of-band
     (e.g., via EPP or a web form).  In the first case, it is useful to
     keep automation active for the delegation in question, to facilitate
     later DS bootstrapping.  In the second case, it is likely that the
     registrant intends to disable DNSSEC for the domain, and DS
     automation is best suspended (until a new DS record is provisioned
     somehow).

     One may ask how a registry can know whether a removal request
     received via EPP was the result of the registrar observing a CDS/
     CDNSKEY "delete" signal.  It turns out that the registry does not
     need to know that; in fact, the advice works out nicely regardless of
     who does the automation:

     a.  Only registry: If the registry performs automation, then the
         registry will consider any request received from the registrar as
         out-of-band (in the context of this automation).  When such
         requests demand removal of the entire DS record set, the registry
         therefore should suspend automation.





  Sheng & Thomassen        Expires 17 August 2026                [Page 15]


  Internet-Draft                DS Automation                February 2026


     b.  Only registrar: The registrar can always distinguish between
         removal requests obtained from a CDS/CDNSKEY "delete" signal and
         other registrant requests, and suspend automation as appropriate.

     c.  In the (undesirable) case that both parties automate, there are
         two cases:

         *  If the registrant submits a manual removal request to the
            registrar, it is out-of-band from the registrar perspective
            (e.g., web form), and also for the registry (e.g., EPP).  As a
            consequence, both will suspend automation (which is the
            correct result).

         *  If a CDS/CDNSKEY "delete" signal causes the registrar to
            request DS removal from the registry, then the registry will
            suspend automation (because the removal request is received
            out-of-band, such as via EPP).  This is independent of whether
            the registry's automation has already seen the signal.  The
            registrar, however, will be aware of the in-band nature of the
            request and not suspend automation (which is also the correct
            result).

         As a side effect, this works towards avoiding redundant
         automation at the registry.

     All in all:

     *  It appears advisable to generally not suspend in-band DS
        automation when an out-of-band DS update has occurred.

     *  An exception from this rule is when the entire DS record set was
        removed through an out-of-band request, in which case the
        registrant likely wants to disable DNSSEC for the domain.  DS
        automation should then be suspended so that automatic re-
        initialization (bootstrapping) does not occur.

     *  In all other cases, any properly authenticated DS updates
        received, including through an automated method, are to be
        considered as the current intent of the domain holder.

  5.2.3.  Concurrent Automatic Updates

     When the RRR model is used, there is a potential for collision if
     both the registry and the registrar are automating DS provisioning by
     scanning the child for CDS/CDNSKEY records.  No disruptive
     consequences are expected if both parties perform DS automation.  An
     exception is when during a key rollover, registry and registrar see
     different versions of the Child's DS update requests, such as when



  Sheng & Thomassen        Expires 17 August 2026                [Page 16]


  Internet-Draft                DS Automation                February 2026


     CDS/CDNSKEY records are retrieved from different vantage points.
     Although unlikely due to Recommendation 1a of Section 2, this may
     lead to flapping of DS updates; however, it is not expected to be
     harmful as either DS RRset will allow for the validation function to
     continue to work, as ensured by Recommendation 1b of Section 2.  The
     effect subsides as the Child's state eventually becomes consistent
     (roughly, within the child's replication delay); any flapping until
     then will be a minor nuisance only.

     The issue disappears entirely when scanning is replaced by
     notifications that trigger DS maintenance through one party's
     designated endpoint [RFC9859], and can otherwise be mitigated if the
     registry and registrar agree that only one of them will perform
     scanning.

     As a standard aspect of key rollovers [RFC6781], the Child DNS
     operator is expected to monitor propagation of Child zone updates to
     all authoritative nameserver instances, and only proceed to the next
     step once replication has succeeded everywhere and the DS record set
     was subsequently updated (and in no case before the DS RRset's TTL
     has passed).  Any breakage resulting from improper timing on the
     Child side is outside of the Parent's sphere of influence, and thus
     cannot be handled with only parent-side changes.

  6.  IANA Considerations

     This document has no IANA actions.

  7.  Security Considerations

     This document considers security aspects throughout, and has no
     separate considerations.

  8.  Acknowledgments

     The authors would like to thank the SSAC members who wrote the
     [SAC126] report on which this document is based.

     In order of first contribution or review: Barbara Jantzen, Matt
     Pounsett, Matthijs Mekking, Ondřej Caletka, Oli Schacher, Kim Davies,
     Jim Reid, Q Misell, Scott Hollenbeck, Tamás Csillag, Philip Homburg,
     Shumon Huque, Libor Peltan, Josh Simpson, Johan Stenstam, Stefan
     Ubbink, Viktor Dukhovni, Hugo Salgado, Wes Hardaker

  9.  References

  9.1.  Normative References




  Sheng & Thomassen        Expires 17 August 2026                [Page 17]


  Internet-Draft                DS Automation                February 2026


     [DNSKEY-IANA]
                IANA, "DNS Security Algorithm Numbers", n.d.,
                <https://www.iana.org/assignments/dns-sec-alg-numbers/dns-
                sec-alg-numbers.xml#dns-sec-alg-numbers-1>.

     [DS-IANA]  IANA, "Delegation Signer (DS) Resource Record (RR) Type
                Digest Algorithms", n.d.,
                <http://www.iana.org/assignments/ds-rr-types>.

     [I-D.ietf-dnsop-cds-consistency]
                Thomassen, P., "Clarifications on CDS/CDNSKEY and CSYNC
                Consistency", Work in Progress, Internet-Draft, draft-
                ietf-dnsop-cds-consistency-11, 11 December 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-
                cds-consistency-11>.

     [RFC1035]  Mockapetris, P., "Domain names - implementation and
                specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
                November 1987, <https://www.rfc-editor.org/rfc/rfc1035>.

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

     [RFC7344]  Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
                DNSSEC Delegation Trust Maintenance", RFC 7344,
                DOI 10.17487/RFC7344, September 2014,
                <https://www.rfc-editor.org/rfc/rfc7344>.

     [RFC8078]  Gudmundsson, O. and P. Wouters, "Managing DS Records from
                the Parent via CDS/CDNSKEY", RFC 8078,
                DOI 10.17487/RFC8078, March 2017,
                <https://www.rfc-editor.org/rfc/rfc8078>.

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

     [RFC8590]  Gould, J. and K. Feher, "Change Poll Extension for the
                Extensible Provisioning Protocol (EPP)", RFC 8590,
                DOI 10.17487/RFC8590, May 2019,
                <https://www.rfc-editor.org/rfc/rfc8590>.

     [RFC9364]  Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
                RFC 9364, DOI 10.17487/RFC9364, February 2023,
                <https://www.rfc-editor.org/rfc/rfc9364>.




  Sheng & Thomassen        Expires 17 August 2026                [Page 18]


  Internet-Draft                DS Automation                February 2026


     [RFC9567]  Arends, R. and M. Larson, "DNS Error Reporting", RFC 9567,
                DOI 10.17487/RFC9567, April 2024,
                <https://www.rfc-editor.org/rfc/rfc9567>.

     [RFC9615]  Thomassen, P. and N. Wisiol, "Automatic DNSSEC
                Bootstrapping Using Authenticated Signals from the Zone's
                Operator", RFC 9615, DOI 10.17487/RFC9615, July 2024,
                <https://www.rfc-editor.org/rfc/rfc9615>.

     [RFC9859]  Stenstam, J., Thomassen, P., and J. Levine, "Generalized
                DNS Notifications", RFC 9859, DOI 10.17487/RFC9859,
                September 2025, <https://www.rfc-editor.org/rfc/rfc9859>.

  9.2.  Informative References

     [LowTTL]   Špaček, P., "DS and DNSKEY low TTL experiments", at DNS
                OARC 41, 6 September 2023, <https://indico.dns-
                oarc.net/event/47/contributions/1010/attachments/958/1811/
                DS%20and%20DNSKEY%20TTL%20experiment.pdf>.

     [RFC5730]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
                STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
                <https://www.rfc-editor.org/rfc/rfc5730>.

     [RFC5731]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
                Domain Name Mapping", STD 69, RFC 5731,
                DOI 10.17487/RFC5731, August 2009,
                <https://www.rfc-editor.org/rfc/rfc5731>.

     [RFC6781]  Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
                Operational Practices, Version 2", RFC 6781,
                DOI 10.17487/RFC6781, December 2012,
                <https://www.rfc-editor.org/rfc/rfc6781>.

     [RFC6840]  Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and
                Implementation Notes for DNS Security (DNSSEC)", RFC 6840,
                DOI 10.17487/RFC6840, February 2013,
                <https://www.rfc-editor.org/rfc/rfc6840>.

     [RFC9803]  Brown, G., "Extensible Provisioning Protocol (EPP) Mapping
                for DNS Time-to-Live (TTL) Values", RFC 9803,
                DOI 10.17487/RFC9803, June 2025,
                <https://www.rfc-editor.org/rfc/rfc9803>.








  Sheng & Thomassen        Expires 17 August 2026                [Page 19]


  Internet-Draft                DS Automation                February 2026


     [SAC126]   (SSAC), I. S. and S. A. C., "SAC126: DNSSEC Delegation
                Signer (DS) Record Automation", 12 August 2024,
                <https://itp.cdn.icann.org/en/files/security-and-
                stability-advisory-committee-ssac-reports/sac-
                126-16-08-2024-en.pdf>.

  Appendix A.  Terminology

     Unless defined in this section, the terminology in this document is
     as defined in [RFC7344].

     Child zone:  DNS zone whose delegation is in the Parent zone.

     Child (DNS operator):  DNS operator responsible for a Child zone.

     DNS operator:  The entity holding the zone's primary copy before it
        is signed.  Typically a DNS hosting provider in the domain
        holder's name, it controls the authoritative contents and
        delegations in the zone, and is thus operationally responsible for
        maintaining the "purposeful" records in the zone file (such as IP
        address, MX, or CDS/CDNSKEY records).  The parties involved in
        other functions for the zone, like signing and serving, are not
        relevant for this definition.

     Parent zone:  DNS zone that holds a delegation for a Child zone.

     Parent (DNS operator):  The DNS operator responsible for a Parent
        zone, and thus involved with the maintenance of the delegation's
        DNSSEC parameters (in particular, the acceptance of these
        parameters and the publication of corresponding DS records).

     Registrant:  The entity responsible for records associated with a
        particular domain name in a domain name registry (typically under
        a TLD such as .com or an SLD such as co.uk).  When the RRR model
        is used, the registrant maintains these records through a
        registrar who acts as an intermediary for both the registry and
        the registrant.

     Registrar:  An entity through which registrants register domain
        names; the registrar performs this service by interacting directly
        with the registry in charge of the domain's suffix.  A registrar
        may also provide other services such as DNS service or web hosting
        for the registrant.  In some cases, the registry directly offers
        registration services to the public, that is, the registry may
        also perform the registrar function.

     Registry:  The entity that controls the registry database and




  Sheng & Thomassen        Expires 17 August 2026                [Page 20]


  Internet-Draft                DS Automation                February 2026


        authoritative DNS service of domain names registered under a
        particular suffix, for example a top-level domain (TLD).  A
        registry receives requests through an interface (usually EPP
        [RFC5730]) from registrars to read, add, delete, or modify domain
        name registrations, and then makes the requested changes in the
        registry database and associated DNS zone.

     RRR Model:  The registrant-registrar-registry interaction framework,
        where registrants interact with a registrar to register and manage
        domain names, and registrars interact with the domain's registry
        for the provision and management of domain names on the
        registrant's behalf.  This model is common amongst top-level
        domains.

  Appendix B.  Recommendations Overview

     For ease of review, the recommendations from this document are
     reproduced here without further comment.  For background and
     analysis, see Sections 2–5.

  B.1.  Acceptance Checks and Safety Measures

     1.  Entities performing automated DS maintenance SHOULD verify

         a.  the unambigious intent of each DS update request as per
             [I-D.ietf-dnsop-cds-consistency], by checking its consistency
             both

             *  between any published CDS and CDNSKEY records, and

             *  across all authoritative nameservers in the delegation,

             and

         b.  that the resulting DS record set would allow continued DNSSEC
             validation if deployed,

         and cancel the update if the verifications do not succeed.

     2.  Parent-side entities (such as registries) SHOULD reduce a DS
         record set's TTL to a value between 5–15 minutes when the set of
         records is changed, and restore the normal TTL value at a later
         occasion (but not before the previous DS RRset's TTL has
         expired).

     3.  DNS operators SHOULD publish both CDNSKEY records as well as CDS
         records, and follow best practice for the choice of hash digest
         type [DS-IANA].



  Sheng & Thomassen        Expires 17 August 2026                [Page 21]


  Internet-Draft                DS Automation                February 2026


  B.2.  Reporting and Transparency

     1.  For certain DS updates (see analysis (Section 3.2)) and for DS
         deactivation, relevant points of contact known to the zone
         operator SHOULD be notified.

     2.  For error conditions, the child DNS operator and the domain's
         technical contact (if applicable) SHOULD be notified first.  The
         registrant SHOULD NOT be notified unless the problem persists for
         a prolonged amount of time (e.g., three days).

     3.  Child DNS operators SHOULD be notified using a report query
         [RFC9567] to the agent domain as described in ([RFC9859],
         Section 4).  Notifications to humans (domain holder) will be
         performed in accordance with the communication preferences
         established with the parent-side entity (registry or registrar).
         The same condition SHOULD NOT be reported unnecessarily
         frequently to the same recipient.

     4.  In the RRR model, registries performing DS automation SHOULD
         inform the registrar of any DS record changes via the EPP Change
         Poll Extension [RFC8590] or a similar channel.

     5.  The currently active DS configuration SHOULD be made accessible
         to the registrant (or their designated party) through the
         customer portal available for domain management.  The DS update
         history MAY be made available in the same way.

  B.3.  Registration Locks

     1.  To secure ongoing operations, automated DS maintenance SHOULD NOT
         be suspended based on a registrar update lock alone (such as EPP
         status clientUpdateProhibited).

     2.  When performed by the registry, automated DS maintenance SHOULD
         NOT be suspended based on a registry update lock alone (such as
         EPP status serverUpdateProhibited).

  B.4.  Multiple Submitting Parties

     1.  Registries and registrars SHOULD provide another (e.g., manual)
         channel for DS maintenance in order to enable recovery when the
         Child has lost access to its signing key(s).  This out-of-band
         channel is also needed when a DNS operator does not support DS
         automation or refuses to cooperate.






  Sheng & Thomassen        Expires 17 August 2026                [Page 22]


  Internet-Draft                DS Automation                February 2026


     2.  DS update requests SHOULD be executed immediately after
         verification of their authenticity, regardless of whether they
         are received in-band or via an out-of-band channel.

     3.  When processing a CDS/CDNSKEY "delete" signal to remove the
         entire DS record set ([RFC8078], Section 4), DS automation SHOULD
         NOT be suspended.  For all other removal requests (such as when
         received via EPP or a web form), DS automation SHOULD be
         suspended until a new DS record set has been provisioned, in
         order to prevent accidental re-initialization when the registrant
         intended to disable DNSSEC.

     4.  Whenever a non-empty DS record set is provisioned, through
         whichever channel, DS automation SHOULD NOT (or no longer) be
         suspended (including after an earlier removal).

     5.  In the RRR model, a registry SHOULD NOT automatically initialize
         DS records when it is known that the registrar does not provide a
         way for the domain holder to later disable DNSSEC.  If the
         registrar has declared to be performing automated DS maintenance,
         the registry SHOULD publish the registrar's [RFC9859]
         notification endpoint (if applicable) and refrain from registry-
         side DS automation.

  Appendix C.  Change History (to be removed before publication)

     *  draft-ietf-dnsop-ds-automation-04

        Editorial changes

     *  draft-ietf-dnsop-ds-automation-03

        Editorial changes

     *  draft-ietf-dnsop-ds-automation-02

        Add Appendix with recommendations overview

        Editorial changes

        Change type to BCP

        Fold CDS/CDNSKEY consistency requirements (Section 6) into
        Section 2 (on acceptance checks)

        Clarify continuity of validation





  Sheng & Thomassen        Expires 17 August 2026                [Page 23]


  Internet-Draft                DS Automation                February 2026


        In RRR, clarify that registries should not bootstrap if registrar
        has no deactivation interface (or if registrar does the
        automation)

        Remove Appendix C ("Approaches not pursued")

     *  draft-ietf-dnsop-ds-automation-01

        Remove Recommendation 6.1.2 which had told parents to require
        publication of both CDS and CDNSKEY

        Clarify Recommendation 5.1.3 (on suspension of automation after DS
        RRset removal) and provide extra analysis

        Providing access to DS update history is now optional

        Humans (domains holders) should be notified according to
        preferences established with registry/registrar (not necessarily
        via email)

        Remove redundant Recommendation 5.1.5 (same as 3.1.4)

        Editorial changes

     *  draft-ietf-dnsop-ds-automation-00

        Rename after adoption

     *  draft-shetho-dnsop-ds-automation-02

        Allow DS automation during registry update lock

        Editorial changes

     *  draft-shetho-dnsop-ds-automation-01

        Incorporated various review feedback (editorial + adding TODOs)

     *  draft-shetho-dnsop-ds-automation-00

        Initial public draft.

  Authors' Addresses

     Steve Sheng
     Email: steve.sheng@gmail.com





  Sheng & Thomassen        Expires 17 August 2026                [Page 24]


  Internet-Draft                DS Automation                February 2026


     Peter Thomassen
     deSEC
     Email: peter@desec.io
















































  Sheng & Thomassen        Expires 17 August 2026                [Page 25]


name: draft-ramakrishna-satp-views-addresses
rev: 06
title: Views and View Addresses for Secure Asset Transfer
time: 2025-09-15T14:01:05Z
group_uri: /api/v1/group/group/1027/
expires: 2026-03-19T14:01:05Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Data formats/interop", "Agent identity/auth"]
tags: []
fetched_at: 2026-02-27T22:56:05.127634+00:00
abstract:
  With increasing use of DLT (distributed ledger technology) systems,
     including blockchain systems and networks, for virtual assets, there
     is a need for asset-related data and metadata to traverse system
     boundaries and link their respective business workflows.  Core
     requirements for such interoperation between systems are the
     abilities of these systems to project views of their assets to
     external parties, either individual agents or other systems, and the
     abilities of those external parties to locate and address the views
     they are interested in.  A view denotes the complete or partial state
     of a virtual asset, or the output of a function computed over the
     states of one or more assets, or locks or pledges made over assets
     for internal or external parties.  Systems projecting these views
     must be able to guard them using custom access control policies, and
     external parties consuming them must be able to verify them
     independently for authenticity, finality, and freshness.  The end-to-
     end protocol that allows an external party to request a view by an
     address and a DLT system to return a view in response must be DLT-
     neutral and mask the interior particularities and complexities of the
     DLT systems.  The view generation and verification modules at the
     endpoints must obey the native consensus logic of their respective
     systems.

full_text:
  Secure Asset Transfer Protocol                            V. Ramakrishna
  Internet-Draft                                                 V. Pandit
  Intended status: Informational                              IBM Research
  Expires: 19 March 2026                                          E. Abebe
                                                                 Consensys
                                                                 S. Nishad
                                                              K. Narayanam
                                                              IBM Research
                                                         15 September 2025


             Views and View Addresses for Secure Asset Transfer
                 draft-ramakrishna-satp-views-addresses-06

  Abstract

     With increasing use of DLT (distributed ledger technology) systems,
     including blockchain systems and networks, for virtual assets, there
     is a need for asset-related data and metadata to traverse system
     boundaries and link their respective business workflows.  Core
     requirements for such interoperation between systems are the
     abilities of these systems to project views of their assets to
     external parties, either individual agents or other systems, and the
     abilities of those external parties to locate and address the views
     they are interested in.  A view denotes the complete or partial state
     of a virtual asset, or the output of a function computed over the
     states of one or more assets, or locks or pledges made over assets
     for internal or external parties.  Systems projecting these views
     must be able to guard them using custom access control policies, and
     external parties consuming them must be able to verify them
     independently for authenticity, finality, and freshness.  The end-to-
     end protocol that allows an external party to request a view by an
     address and a DLT system to return a view in response must be DLT-
     neutral and mask the interior particularities and complexities of the
     DLT systems.  The view generation and verification modules at the
     endpoints must obey the native consensus logic of their respective
     systems.

  About This Document

     This note is to be removed before publishing as an RFC.

     The latest revision of this draft can be found at https://ietf-
     satp.github.io/draft-ramakrishna-satp-views-addresses/draft-
     ramakrishna-satp-views-addresses.html.  Status information for this
     document may be found at https://datatracker.ietf.org/doc/draft-
     ramakrishna-satp-views-addresses/.




  Ramakrishna, et al.       Expires 19 March 2026                 [Page 1]


  Internet-Draft        SAT Views and View Addresses        September 2025


     Discussion of this document takes place on the Secure Asset Transfer
     Protocol Working Group mailing list (mailto:sat@ietf.org), which is
     archived at https://mailarchive.ietf.org/arch/browse/sat/.  Subscribe
     at https://www.ietf.org/mailman/listinfo/sat/.

     Source for this draft and an issue tracker can be found at
     https://github.com/ietf-satp/draft-ramakrishna-satp-views-addresses.

  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 19 March 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
     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
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.  Assumptions and Principles  . . . . . . . . . . . . . . . . .   7
     4.  Ledger State Views and Proofs . . . . . . . . . . . . . . . .   7
       4.1.  Abstraction of Distributed Ledger States  . . . . . . . .   8
       4.2.  Distributed Ledger System Views . . . . . . . . . . . . .   9
       4.3.  Simple Views  . . . . . . . . . . . . . . . . . . . . . .  11



  Ramakrishna, et al.       Expires 19 March 2026                 [Page 2]


  Internet-Draft        SAT Views and View Addresses        September 2025


       4.4.  Aggregate Views . . . . . . . . . . . . . . . . . . . . .  12
       4.5.  Complex or Processed Views  . . . . . . . . . . . . . . .  12
       4.6.  View Proofs . . . . . . . . . . . . . . . . . . . . . . .  12
     5.  Ledger State View Addresses . . . . . . . . . . . . . . . . .  13
     6.  Ledger State View Verification Policies . . . . . . . . . . .  17
     7.  Ledger State View Request . . . . . . . . . . . . . . . . . .  18
     8.  Ledger State View Access Control Policies . . . . . . . . . .  18
     9.  Related Open Issues . . . . . . . . . . . . . . . . . . . . .  19
       9.1.  Forms of proof  . . . . . . . . . . . . . . . . . . . . .  19
       9.2.  Temporal guarantees of view authenticity  . . . . . . . .  20
     10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  20
       10.1.  Normative References . . . . . . . . . . . . . . . . . .  20
       10.2.  Informative References . . . . . . . . . . . . . . . . .  21
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23

  1.  Introduction

     Blockchain systems, especially those of the permissioned variety, are
     a heterogeneous mix, fulfilling a diverse range of needs and built on
     several different DLT stacks that are not compatible with each other.
     Yet, in an interconnected world, the business processes running on
     each system cannot afford to remain isolated and the virtual assets
     they manage cannot afford to remain in siloes.  These systems must be
     interoperable so that assets can move, and their properties can be
     reflected across network boundaries, and so that business processes
     can span multiple systems.  Interoperability will, in effect, mimic a
     larger or scaled up, blockchain system composed of smaller blockchain
     systems without explicitly requiring those systems to coalesce.

     At the core of any cross-blockchain system transaction is the ability
     of a system to project a view of assets and associated data recorded
     on its ledger to external parties, be they individual agents or other
     blockchain systems.  On the reverse, a blockchain system must also
     have the ability to identify and address views of assets or
     associated data in another system, and further, to validate that view
     before its business process consumes it.  View projection,
     addressing, and consumption, must eliminate or minimize the role of
     third parties to avoid loss of data privacy, control over business
     process, or diminishment of autonomy.

     This document specifies formats for views and view addresses on
     distributed ledgers.  Similar to the notion of database views,
     distributed ledger views reflect what a given network wishes to
     expose to external parties, typically through scripts, as well as
     access control considerations.  In contrast to conventional
     databases, exposure and access control considerations must be decided
     through decentralized consensus.  Also, in contrast to a conventional
     database, the consumer of the view, who may be a DLT system, must be



  Ramakrishna, et al.       Expires 19 March 2026                 [Page 3]


  Internet-Draft        SAT Views and View Addresses        September 2025


     able to independently validate it as the consensus view of the
     providing network.  Hence, a view incorporates the notion of a proof
     made against a claim.  The view address must encapsulate the view
     request, and optionally carry a policy that circumscribes the
     construction of proof.

     The protocol to communicate view requests and responses is beyond the
     scope of this draft and will be specified in a separate draft.

  2.  Terminology

     The following are some terminology used in the current document:

     *  Blockchain system: Blockchains are distributed digital ledgers of
        cryptographically signed transactions that are grouped into
        blocks.  Each block is cryptographically linked to the previous
        one (making it tamper evident) after validation and undergoing a
        consensus decision.  As new blocks are added, older blocks become
        more difficult to modify (creating tamper resistance).  New blocks
        are replicated across copies of the ledger within the network, and
        any conflicts are resolved automatically using established rules
        [NIST].

     *  Blockchain network: This is a blockchain system that is built on a
        network of nodes that maintain a common shared copy of the
        blockchain using a consensus protocol.

     *  Distributed ledger technology (DLT) system: Technology that
        enables the operation and use of distributed ledgers, where the
        ledger is shared (replicated) across a set of DLT nodes and
        synchronized between the DLT nodes using a consensus mechanism
        [ISO].  Every blockchain system is also a DLT system, and so we
        will mostly use the latter term in this draft when discussing
        protocols for cross-system interactions.

     *  Distributed ledger network: This is a DLT system that is built on
        a network of nodes that maintain a shared copy of the ledger or
        portions of it on different subsets of nodes using a consensus
        protocol.

     *  Resource Domain: The collection of resources and entities
        participating within a blockchain or DLT system.  The domain
        denotes a boundary for permissible or authorized actions on
        resources.

     *  Interior Resources: The various interior protocols, data
        structures and cryptographic constructs that are a core part of a
        blockchain or DLT system.  Examples of interior resources include



  Ramakrishna, et al.       Expires 19 March 2026                 [Page 4]


  Internet-Draft        SAT Views and View Addresses        September 2025


        the ledger (blocks of confirmed transaction data), public keys on
        the ledger, consensus protocol, incentive mechanisms, transaction
        propagation networks, etc.

     *  Exterior Resources: The various resources that are outside a
        blockchain or DLT system, and are not part of the operations of
        the system.  Examples include data located at third parties such
        as asset registries, ledgers of other blockchain/DLT systems, PKI
        infrastructures, etc.

     *  Nodes: The nodes of the blockchain or DLT system which form the
        peer-to-peer network, which collectively maintain the shared
        ledger in the system by following a consensus algorithm.

     *  Gateway nodes: The nodes of the blockchain or DLT system that are
        functionally capable of acting as a gateway in an asset transfer.
        A gateway node conforms to the Secure Asset Transfer Architecture
        [SATA] and implements the Secure Asset Transfer Protocol (SATP)
        [SATP].  Being a node on the blockchain/DLT system, a gateway has
        at least read access to the interior resources (e.g., ledger) of
        the blockchain.  Optionally, it may have write access to the
        ledger and also the ability to participate in the consensus
        mechanism deployed for the system.  Depending on the blockchain/
        DLT system implementation, some or all of the nodes may be
        gateway-capable.

     *  Clients: Entities are permitted to invoke smart contracts to read
        or update ledger state in a blockchain or DLT system.  They
        possess unique identities in the form of public keys.  In a
        permissioned system, identity certificates are issued by the
        system's internal providers (or certificate authorities).

     *  Wallets: Collection of client identities represented by public-
        private key pairs, and optionally certificate issued by a
        blockchain or DLT system's identity providers (or certificate
        authorities).

     *  Virtual Asset: A virtual asset is a digital representation of
        value that can be digitally traded, or transferred as defined by
        the FATF [FATF].

     *  Virtual Asset Service Provider (VASP): Legal entity handling
        virtual assets as defined by the FATF [FATF].

     *  Ledger state: A snapshot of the information held in a distributed
        shared ledger, typically (though not necessarily) as a set of
        blockchain or DLT system.  Examples of interior resources include
        key-and-value pairs.  This information includes records of virtual



  Ramakrishna, et al.       Expires 19 March 2026                 [Page 5]


  Internet-Draft        SAT Views and View Addresses        September 2025


        assets and the state of business processes that are meaningful to
        the DLT system's participants and clients.  State elements and
        subsets may be scoped under the namespaces of given smart
        contracts, thereby being accessible only through invocations on
        those contracts.

     *  Smart contracts: Business workflows written in programming
        languages that manage the states of assets and business processes
        on a shared ledger in a DLT system.  These contracts constrain the
        ability of system clients to modify ledger state and embed guards
        around state elements.  Contracts can be invoked to read from, or
        write, to, a ledger.  They can be deployed on several system
        nodes, who must agree on a given ledger state update via a
        consensus protocol.

     *  Consensus protocol/mechanism: Process by which nodes agree on a
        ledger state update, typically (though not mandatorily) through a
        smart contract invocation.

     *  Local transaction: A transaction triggered by a client to update
        the ledger state in a blockchain or DLT system, typically (though
        not mandatorily) through a smart contract invocation.

     *  View: A projection of a blockchain or DLT system's ledger state
        for external consumption, i.e., for parties outside that system.
        This can be a single element, a subset of the state, or a function
        over a subset.

     *  View Address: A unique identifier or locator for a view into a
        blockchain or DLT system's ledger.  This is analogous to an HTTP
        URL.

     *  Source system: Blockchain or DLT system governing the ledger from
        which a view is produced.

     *  Destination system: System in which a view is consumed.  This can
        be a blockchain or DLT system.

     *  Remote system: Counterparty system in a view request-response
        protocol instance.  From the vantage point of the source system,
        this refers to the destination system, and vice versa.

     *  View requestor: Person or organization triggering a view request
        from a source network.







  Ramakrishna, et al.       Expires 19 March 2026                 [Page 6]


  Internet-Draft        SAT Views and View Addresses        September 2025


     *  Proof: A data structure containing evidence linking a view to its
        source system's blockchain, or more generally, ledger.  The
        evidence may be probabilistic and in some cases cryptographically
        verifiable.

     *  Access/exposure policy: Set of rules governing the release of a
        view to an external party (i.e., outside the source system), held
        in consensus by nodes on the source system's ledger.

     *  Verification policy: Rules for validation of proofs associated
        with views maintained in a destination system.  If the destination
        system is a blockchain or DLT system, these rules are held in
        consensus by nodes on the that system's ledger.

     *  View Request: A request for a made by an external party to a
        source blockchain or DLT system.  The external party may be a
        client in a destination blockchain or DLT system.  The request
        consists of a view address and various metadata, including
        optionally a verification policy.

     *  Asset locking or escrow: The conditional mechanism used within a
        blockchain or DLT system to make an asset temporarily unavailable
        for use by its owner.  The condition of the asset release can be
        based on a duration of time (e.g., hash time locks) or other
        parameters.

     Further terminology definitions can be found in [NIST] and [ISO].
     The term 'blockchain' and 'distributed ledger technology' (DLT) are
     used interchangeably in this document.

  3.  Assumptions and Principles

     The addressing of a DLT system’s assets and asset-related data as
     well as the exposure of such data to a foreign DLT system assumes the
     presence of one or more gateways that are either part of the system
     or working on behalf of it.  These gateways are ultimately
     responsible for generating and interpreting both addresses and data,
     hiding any DLT- or network-specific protocol considerations from each
     other.  All DLT- and network-specific software artifacts that are
     exchanged among gateways will be encapsulated in generic (or DLT-
     neutral) software artifacts.  The gateways are assumed to be
     interoperable using a protocol that corresponds to the design
     principles of the Internet architecture.  The specification of this
     protocol is beyond the scope of this draft and will be described in a
     separate draft.

  4.  Ledger State Views and Proofs




  Ramakrishna, et al.       Expires 19 March 2026                 [Page 7]


  Internet-Draft        SAT Views and View Addresses        September 2025


  4.1.  Abstraction of Distributed Ledger States

     A distributed ledger system maintains a set of ledgers, akin to
     databases.  Each such ledger is organized and addressable in a
     hierarchical namespace with the identifier of the distributed ledger
     system being the root.  A ledger is shared among a subset of members
     of the network that the system, which maintains the distributed
     ledger, is built on.  These subsets of members may overlap or be
     mutually exclusive, depending on the precepts of the given DLT, but
     for the purpose of this document, the distinction is not relevant.
     For example, the Hyperledger Fabric blockchain platform maintains a
     set of channels, where each channel is shared exclusively by a subset
     of members [Andr18].  In contrast, the Corda platform allows each
     data item to be shared by an arbitrary subset of members, in effect
     creating databases privy to mutually overlapping member sets
     [Hear19].  The Ethereum Mainnet has a dynamic group of members
     maintaining a single global ledger with open, or public, access.

     Each shared ledger within a system maintains a snapshot of the
     latest, or current, state, determined through consensus (or
     agreement) by the members sharing it.  In addition, a tamper-evident
     history of the current state, which can be a blockchain or any other
     form of a transaction log, is also maintained by the members sharing
     that database.  The state of the distributed ledger system as a whole
     is the union of states of the ledgers it comprises of.

     Finally, any data item within a ledger can be retrieved, or any
     processed data extracted, using its native logic and interfaces.  As
     a ledger is a traditional database in most respects, it supports
     extraction and processing the same way a database does.  For example,
     data in a SQL database can be extracted using record keys and schema
     attributes, whereas in a No-SQL database, data is extracted using
     knowledge of key value pairs and overlaid schema.  Just as views and
     stored procedures are used to extract information from a database,
     UTXO scripts (in Bitcoin [Naka08]) or smart contracts (in Ethereum
     [Ethe22], and several permissioned DLTs like Hyperledger Fabric and
     Corda) are used to extract information from a ledger.  An interface
     is provided to give the user the ability to query or update ledger
     data.  As UTXO scripts are just simple forms of smart contracts, we
     will assume in our abstraction that each ledger within a DLT system
     possesses a smart contract interface.










  Ramakrishna, et al.       Expires 19 March 2026                 [Page 8]


  Internet-Draft        SAT Views and View Addresses        September 2025


  4.2.  Distributed Ledger System Views

     A view into a distributed ledger system state is similar in concept
     to a traditional database view but has certain additional features
     because the backing state is maintained in a different way than state
     in a traditional database is.  Fundamentally, a DLT system view is
     information that is derived from that system's ledger.  We define it
     as an abstract representation of state projected from a ledger that
     is consumable by entities, who may or may not belong to the network
     or possess credentials to access raw ledger state.  Views are
     uniquely addressable within a DLT system.  A view can be static,
     i.e., referring to information derived from a point-in-time (or
     historical) state, or dynamic, i.e., referring to information derived
     from the current state.

     Semantically, a view represents the what and not the how, i.e., it
     projects information from a ledger but not the details of the process
     through which that information came into being.  This process has
     multiple facets, from the consensus and commitment protocols through
     which raw data was recorded on the ledger to the smart contract
     procedure through which information was extracted from the raw ledger
     data.  These procedures are specific to DLT implementations, which we
     wish to keep opaque from the cross-system communication
     infrastructure, specifically the systems' gateways.  This will allow
     the communication infrastructure to ignore details of ledger
     implementations while managing state when a view is communicated from
     a system to an external entity.  Therefore, we specify the view as a
     package with a generic structure, independent of a specific DLT
     implementation.  Internally, a view will contain data that has a DLT-
     specific representation, but we will leave the interpretation of this
     to modules internal to the systems.  In this document, we will
     specify the formats of the DLT-independent portions of a view that
     will be handled by the communication infrastructure and provide
     suggestive sample view contents for prominent DLTs.

     There is a caveat to the above definition, arising from a fundamental
     difference between a traditional database and a DLT system.  This is
     the fact that state in the former is maintained by a single authority
     whereas state in the latter is maintained collectively, and held in
     agreement, by a peer group of entities, each of which can fail or be
     malicious.  Therefore, a DLT system view is incomplete without an
     associated proof of it being derived from state agreed to by the
     group as a whole.  In practice, this does not require unanimity but
     rather enough representation from group members to overcome failure
     of individual peers' failures and to assure an external client that
     the system as a whole will not repudiate that view, in accordance
     with the consensus rules of the source ledger, at a later time.
     Theoretically, we can quantify the nature of this proof under certain



  Ramakrishna, et al.       Expires 19 March 2026                 [Page 9]


  Internet-Draft        SAT Views and View Addresses        September 2025


     models.  If peers are susceptible only to crash failures, an
     agreement over state from more than 50% of the peers will qualify as
     sufficient proof.  If peers can be malicious, i.e., fail in Byzantine
     ways, a consistent state view is required from more than 2/3 of the
     peers.  More generally, the nature of proof, or determining what is
     sufficient, can be derived from the consensus mechanism used by the
     system.

     The proof associated with a view represents two things.  One is an
     assurance that the view is a group, or consensus, view of the ledger
     held by the DLT system as a whole.  The other is evidence of
     authenticity of the state projection that the view represents.  And
     though the construction of a proof is very DLT-specific, the notion
     that a proof may be supplied with a view can be embodied in a DLT-
     independent specification, thereby adhering to the principle of DLT
     opacity to the communication infrastructure.  Finally, proofs are
     also consistent with the "what, not how" principle because they
     certify that a view represents state at a given point in time and not
     the history of events that led to that state.

     Now we can look at the structure of a view in more detail.  At a high
     level, a view consists of the following:

     *  Request Id: a unique value corresponding to the request for a view
        made by an external entity to the DLT system.

     *  Data: ledger state projection, or derived information, with proof.

     *  Metadata: attributes of the payload used to unpack and interpret
        it.

     Data consists of the following:

     *  View Address: this is supplied by an external entity, and is the
        equivalent of a "getter function" that can be used to uniquely
        identify (or derive) projection into a DLT system state.

     *  Information: this is the actual ledger state projection.

     *  Schema: this described the Information data structure and can be
        used to unpack (or unmarshal) it.  It is optional if the ledger
        schema is well-known.

     *  Proof: This is a structure that validates the Information.  It is
        optional, though recommended for DLT system views.

     *  Proof Schema: this describes the Proof data structure.  It is
        optional if the proof schema is well-known.



  Ramakrishna, et al.       Expires 19 March 2026                [Page 10]


  Internet-Draft        SAT Views and View Addresses        September 2025


     Metadata consists of the following:

     *  View Type: this tells us whether the view is a singleton data
        item, a collection of data items, or a computation over data items
        that are part of the DLT system state.

     *  Protocol Type: this denotes a unique value associated with a given
        DLT protocol; e.g., Bitcoin, Ethereum, Hyperledger Fabric, Corda,
        Solana.

     *  Timestamp: this denotes the time at which the view was produced.

     *  Proof Type: this denotes the type, or category, of proof being
        supplied, e.g., Notarizations/certifications (also called proof of
        authority), Simplified Payment Verifications, Zero Knowledge
        Proof, Proof of Proof-of-Work.

     *  Serialization Format: this denotes the format used to serialize
        the view data, e.g., XML, JSON, protocol buffer.

     *  Commitments: these are commitments made on the view by authorities
        or infrastructure (e.g., the Ethereum Mainnet) external to the DLT
        system.

  4.3.  Simple Views

     A simple DLT view is any unit of a database within a DLT system that
     is exposable through interfaces programmed over that database.  More
     concretely, any blockchain or smart contract system provides the
     ability to write scripts or procedures that can act on the raw ledger
     (database) data, accompanied by interfaces to trigger those scripts
     or procedures to query or update ledger state.  In such a system, a
     simple view is any information that can be obtained directly through
     an invocation of this interface, e.g., any transaction exposed by a
     smart contract deployed on a ledger within the system.

     In the DLT view structure specified earlier, the View Type within
     Metadata will be set to SIMPLE if such a view is requested by an
     external entity.  The content of the view address (described later in
     this draft) can be interpreted to know if the external entity is
     requesting a simple view.










  Ramakrishna, et al.       Expires 19 March 2026                [Page 11]


  Internet-Draft        SAT Views and View Addresses        September 2025


  4.4.  Aggregate Views

     An aggregate DLT view is a collection of addressable units of
     databases within a DLT system.  In effect, it is an array of simple
     views, which can be derived through multiple invocations of different
     scripts or smart contract transactions acting on raw ledger data.  In
     the DLT view structure specified earlier, the View Type within
     Metadata will be set to AGGREGATE if such a view is requested by an
     external entity.  The content of the view address (described later in
     this draft) can be interpreted to know if the external entity is
     requesting an aggregate view.

  4.5.  Complex or Processed Views

     A complex or processed DLT view is the output of a function computed
     over a set of addressable units of databases within a DLT system.  In
     effect, it is a function computed over an aggregate view.  In the DLT
     view structure specified earlier, the View Type within Metadata will
     be set to AGGREGATE if such a view is requested by an external
     entity.  The content of the view address (described later in this
     draft) can be interpreted to know if the external entity is
     requesting a complex view, and the function to be computed will also
     be specified in the view address.

  4.6.  View Proofs

     Proof within a view must ratify the view’s contents as the consensus
     over a projection of ledger state by members of the DLT system.
     Because the projection of state is itself DLT-specific, though it can
     be wrapped in DLT-neutral structures as we have described earlier,
     the proof also takes DLT-specific shapes.  But we can list the set of
     attributes any proof must contain in abstract terms as follows:

     *  Association of response with request: a connection (ideally,
        cryptographically secure) between the request supplied in the view
        address with the ledger state projection as inferred by the source
        system.  For instance, this can take the form of a signature over
        a common structure consisting of both the request and the
        response.

     *  Authenticity of response: a connection (ideally, cryptographically
        secure) between a member generating a ledger state projection and
        its DLT system.  For instance, this can take the form of a
        certificate chain associating the signer with the DLT system’s
        membership authorities.  This is necessary for a permissioned DLT
        system and is optional for open (or permissionless) DLT systems.





  Ramakrishna, et al.       Expires 19 March 2026                [Page 12]


  Internet-Draft        SAT Views and View Addresses        September 2025


     *  Evidence of consensus: information showing that the view contents
        are agreed upon by the network as a whole.  For a permissioned DLT
        system, this typically implies that an identical and authentic
        ledger state projection must be provided by a large enough quorum
        of its members so that the view cannot be repudiated in the
        future.  In an open (or permissionless) system, this can simply be
        the portion of a mined block that shows why it belongs to the
        longest chain; i.e., proof-of work or succinct versions of it
        (like Proof-of-Proof-of-Work [Naka08], or PoPoW [Kiay16][Kiay17]).
        In any DLT system, such evidence can optionally pass a policy
        check, where the policy rule is supplied by the view requestor and
        typically embodies the consensus logic that led to the commitment
        of the ledger state projection being requested.

  5.  Ledger State View Addresses

     To request a view from a DLT system, an external entity must be able
     to unambiguously specify the information it seeks in the form of a
     view address.  The use of the term “address” follows from the
     abstraction of a DLT system as a repository of data resources that
     can be retrieved and computed on.  A view address in blockchain or
     distributed ledger systems is equivalent to URLs [RFC1630] (for
     example, specified as an HTTP address [RFC2616]), which are used to
     address resources offered by Internet and World Wide Web servers
     [RFC1738].

     From a functional perspective, a view address can also be thought of
     as an interface over a “getter”, which is a standard software pattern
     used to fetch data values in a computer program.  The schematic
     representation of a getter is dependent on the protocol followed by
     the underlying distributed ledger system, but is conceptually
     abstracted away by the view address.  An external entity can create
     and manipulate a view address without understanding its semantics and
     usage, which are hidden by the DLT system.  This allows the system to
     use alternate representations for getters internally without
     requiring external entities to understand the implementations of
     these operators.  The view address states the “what” and not the
     “how”.

     A view address must be a globally unique identifier of a view on a
     distributed ledger system, because global interoperability is our
     goal.  Therefore, as with DNS addresses for Internet servers and URLs
     for World Wide Web resources, a view address is a hierarchical
     address, with different segments identifying units of decreasing size
     and increasing specificity in sequence.  The syntax is as follows:






  Ramakrishna, et al.       Expires 19 March 2026                [Page 13]


  Internet-Draft        SAT Views and View Addresses        September 2025


       address  = location-segment "/"
                  ledger-segment "/"
                  view-segment
                  ; distributed-ledger-system/ledger/data-projection

     The location-segment provides identification and reachability
     information for the distributed ledger system.  The ledger-segment
     identifies a unique ledger within this system, and the view-segment
     identifies a view or state projection from that ledger.

     Decentralized ledger systems don’t have a single location as they are
     built on networks of peer nodes.  Maintainers of these systems may
     expose one or more endpoints for external entities to access views,
     which can be hosted on the network nodes themselves or on designated
     gateways.  Gateways form the communication infrastructure for cross-
     system interactions and can be deployed in different configurations:
     a single system may possess multiple gateways, or a single gateway
     may serve multiple systems.  Therefore, to formulate a view address,
     one needs to know the set of endpoints that lead to a given
     distributed ledger system and a unique identifier for the network
     that hosts that system.  In certain systems and gateways, an
     identifier that represents a set of endpoints can be used instead of
     explicitly enumerating those endpoints.  Also, if the specified set
     of endpoints is known to serve a single system, the network
     identifier can be omitted.  The syntax of the location-segment is as
     follows:

       location-segment  = gateway ["/" network-id]
       gateway           = endpoint *(";" endpoint) / name
       endpoint          = host [":" port]
       host              = hostname / IP-address
       port              = 1*DIGIT
       network-id        = name
       hostname          = name 1*("." name)
       name              = (ALPHA / "_") *(ALPHA / DIGIT / "_" / "-")
       IP-address        = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT

     A single gateway serving a given distributed ledger system (network)
     can be represented as follows:

       location-segment  = gateway.trade.com:7542/trade-network
                           \____________________/ \___________/
                                      |                 |
                                   endpoint          network

     Multiple gateways serving a network can be represented as follows:





  Ramakrishna, et al.       Expires 19 March 2026                [Page 14]


  Internet-Draft        SAT Views and View Addresses        September 2025


     location-segment  = gateway1.trade.com:7542;   \
                         gateway2.trade.com:7542;   |--gateway (endpoints)
                         gateway3.trade.com:7542    /
                         /trade-network
                          \___________/
                                |
                             network

     Gateways serving a single well-known network can be represented as
     follows:

       location-segment  = gateway1.trade.com:7542;gateway2.trade.com:7542
                           \_____________________________________________/
                                                  |
                                         gateway (endpoints)

     The ledger-segment names either the ledger, if that ledger has a
     distinct identifier within the system, or a procedure to access a
     ledger, which represents a common set of facts shared by a subset of
     members of the network that maintains the distributed ledger.  These
     subsets may overlap; i.e., certain nodes may maintain more than one
     ledger in the system.  The procedure name can take the form of an
     identifier that represents, say, a decentralized application spanning
     certain nodes, or an explicit enumeration of the identifiers of the
     nodes themselves.  The ledger segment syntax is as follows:

       ledger-segment = *1(
                           (ALPHA / "_")
                           1*(ALPHA / DIGIT / "_" / "-" / ";" / “:”)
                          )

     The ledger-segment can be blank if the distributed ledger system has
     a single ledger.  This is the norm in open blockchain systems like
     Bitcoin or the Ethereum Mainnet, and in private Ethereum-based
     systems like Quorum and Hyperledger Besu.

     Examples are as follows:














  Ramakrishna, et al.       Expires 19 March 2026                [Page 15]


  Internet-Draft        SAT Views and View Addresses        September 2025


       ledger-segment = trade-channel
                        \___________/
                              |
                         ledger name

       ledger-segment = paymentsDapp
                        \___________/
                              |
                      procedure/app name

       ledger-segment = paymentsDappNode1:9005;paymentsDappNode2:9005
                        \____________________/ \____________________/
                                   |                      |
                          procedure/app node     procedure/app node

     The view-segment uniquely identifies a view within a ledger.
     Features particular to a distributed ledger technology will determine
     how to encode this segment, but we can draw out common abstractions
     across DLTs to create a generic specification.  All such technologies
     offer a procedural interface to access and manipulate data, typically
     (but not always) in the form of a smart contract.  The exposed
     interface offers multiple functions to generate views based on the
     provided input.  Hence, we can specify the view-segment as being
     composed of a contract, a function, and a list of input arguments.
     In the most general case, a default contract may be assumed, and
     arguments may be unnecessary, and so these can be omitted.  The
     function, which can either be a procedural identifier, or a direct
     reference to a data item or collection of data items, or a
     programming instruction, must be specified.  The view-segment syntax
     is as follows:

       view-segment   = [contract-id] ":"
                        function-spec *(":" input-argument)
       contract-id    = (ALPHA / "_") 1*(ALPHA / DIGIT / "_")
       function-spec  = name
       input-argument = name
       name           = *HEXDIGIT ; hex-encoded ASCII string

     An example of a view-segment for a Hyperledger Fabric ledger is:

       view-segment   = trade-chaincode:getBillOfLading:bill-10012
                        \_____________/ \_____________/ \________/
                                |               |            |
                            contract         function     argument

     An example for a Corda ledger is:





  Ramakrishna, et al.       Expires 19 March 2026                [Page 16]


  Internet-Draft        SAT Views and View Addresses        September 2025


      view-segment   = :com.trade.dapp.flows.GetDocumentByTypeAndId:C:5
                        \_________________________________________/ \_/
                                             |                       |
                                          function               arguments

     An example of a complete view address is as follows:

       gw.trade.com:7542/traden/tradel/tradec:getBill:bill-10012
       \______________________/ \____/ \_______________________/
                   |               |                |
           location-segment  ledger-segment    view-segment

  6.  Ledger State View Verification Policies

     A verification policy for a ledger state view is a set of rules that
     the proof within the view can be validated against (or filtered
     through).  The condition embedded within a rule can be arbitrary,
     though in practice, it should embody the process by which that
     ledger’s state was updated and consented to in a decentralized manner
     by the network of peers maintaining it.  In permissioned networks
     built on DLTs like Hyperledger Fabric or Corda, a policy typically
     requires evidence of attestations made by a sufficiently large, or
     representative, portion of the peer network maintaining the ledger.
     This takes the form of a set of signatures and is crucial to
     validating views generated by networks built on DLTs like Hyperledger
     Fabric and Corda.  In open networks, we can envision policies that
     require validation of the view data being derived from a block in the
     longest chain, for example.  But in this specification, we will
     consider only attestation-based policies and leave more general
     policies to future drafts.

     The structure of a verification policy is as follows:

     *  Security Domain: a unique identifier for the distributed ledger
        system (or network maintaining it) projecting the ledger state
        view.

     *  Rules: a set of rules, each governing the validation of artifacts
        exposed through a particular category of views within the Security
        Domain.

     Each Rule consists of the following:

     *  View Pattern: a regular expression that can match a set of views.

     *  Policy: a policy rule/filter governing all views that match View
        Pattern.




  Ramakrishna, et al.       Expires 19 March 2026                [Page 17]


  Internet-Draft        SAT Views and View Addresses        September 2025


     Each Policy consists of the following:

     *  Type: an identifier or flag denoting the type of this policy rule.
        For attestation-based policies, this should be set to “Signature”,
        and other identifiers can be created for other policy types in
        future drafts.

     *  Criteria: a Boolean expression with ANDs and ORs, where the
        principals consist of (1) the name of a DLT system unit/
        stakeholder (typically corresponding to a subset of nodes in the
        peer network), and (2) the number of signatures requires from this
        unit.

  7.  Ledger State View Request

     A view request is a message sent to a distributed ledger system by
     any external entity.  It consists of the following:

     *  View Address: uniquely identifies the data sought by the
        requester.

     *  Verification Policy: indicates the proof criteria for the
        requested view.

  8.  Ledger State View Access Control Policies

     An access control policy for a ledger state view is a set of rules
     governing the exposure of the view to an external entity.  Each rule
     maps a set of principals to a set of views.  The structure of an
     access control policy is as follows:

     *  Security Domain: a unique identifier for the entity (which can be
        a distributed ledger system itself) requesting a ledger state
        view.

     *  Rules: a set of rules, each governing access from some entity
        within Security Domain to artifacts exposed through a particular
        category of views.

     Each Rule consists of the following:

     *  Principal: a string that can match a set of subjects or
        principals, which can represents an individuals or an organization
        or a subgroup within an organization identified by role or
        attribute set (profile).

     *  Principal Type: a keyword that denotes the nature of the
        principal.  This can be one of the following:



  Ramakrishna, et al.       Expires 19 March 2026                [Page 18]


  Internet-Draft        SAT Views and View Addresses        September 2025


        -  PUBLIC-KEY: indicates that the principal is a public key
           associated with an individual member of the Security Domain.

        -  CA: indicates that the principal is a certification authority
           for an organization within the Security Domain.

        -  ROLE: indicates that the principal identifies a role within the
           Security Domain.

        -  ATTRIBUTE: indicates that the principal identifies a set of
           attributes, or a profile for a member, within the Security
           Domain.

        -  ‘*’: indicates that the principal can be any member of the
           Security Domain.  The Principal can be left blank in this case.

     *  Resource: a regular expression that can match a set of views,
        which identifies the objects governed by this rule.

     *  Read: a Boolean flag indicating whether this rule is currently
        active.

  9.  Related Open Issues

     This draft provides a specification for views and how to addresses
     them.  It further describes a protocol whereby one system can request
     a view from another through gateways.  But there are several aspects
     of the end to-end process, which are extraneous to the data sharing
     protocol yet crucial to its successful completion.  Though detailed
     specifications of these are beyond the scope of this draft, we list
     them in this section for readers’ considerations.

  9.1.  Forms of proof

     Though we have tried to be agnostic of the nature of the proof
     associated with a view in this draft, the data sharing protocol
     implicitly assumes that the proof takes the form of a quorum of
     digital signatures from parties belonging to a permissioned
     distributed ledger system.  But several other proof types can exist,
     each suitable to the type of system that is exporting a view and the
     technology stack and consensus mechanism it is built on
     [Naka08][Kiay16][Kiay17][PoS][PoET][PoA].









  Ramakrishna, et al.       Expires 19 March 2026                [Page 19]


  Internet-Draft        SAT Views and View Addresses        September 2025


  9.2.  Temporal guarantees of view authenticity

     The view address as specified in this draft has no temporal
     component, implicitly conveying a request for the latest or
     “freshest” state projection from a shared ledger.  Even apart from
     expanding the specification of the view address to include, for
     example, an absolute or relative timestamp, we will need to augment
     the data sharing protocol with a mechanism to convey proof of
     temporal veracity of a view.  Work done on verifiable observation of
     shared ledgers using a public bulletin board [Abebe21] can be taken
     as the starting point for such a specification.

  10.  References

  10.1.  Normative References

     [FATF]     FATF, "International Standards on Combating Money
                Laundering and the Financing of Terrorism & Proliferation
                - The FATF Recommendations", October 2018,
                <http://www.fatf-
                gafi.org/publications/fatfrecommendations/documents/fatf-
                recommendations.html>.

     [ISO]      ISO, "Blockchain and distributed ledger technologies-
                Vocabulary (ISO:22739:2024)", January 2024,
                <https://www.iso.org/standard/82208.html>.

     [NIST]     Yaga, D., Mell, P., Roby, N., and K. Scarfone, "NIST
                Blockchain Technology Overview (NISTR-8202)", October
                2018, <https://doi.org/10.6028/NIST.IR.8202>.

     [RFC1630]  Berners-Lee, T., "Universal Resource Identifiers in WWW: A
                Unifying Syntax for the Expression of Names and Addresses
                of Objects on the Network as used in the World-Wide Web",
                RFC 1630, DOI 10.17487/RFC1630, June 1994,
                <https://www.rfc-editor.org/rfc/rfc1630>.

     [RFC1738]  Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
                Resource Locators (URL)", RFC 1738, DOI 10.17487/RFC1738,
                December 1994, <https://www.rfc-editor.org/rfc/rfc1738>.

     [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
                Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
                Transfer Protocol -- HTTP/1.1", RFC 2616,
                DOI 10.17487/RFC2616, June 1999,
                <https://www.rfc-editor.org/rfc/rfc2616>.





  Ramakrishna, et al.       Expires 19 March 2026                [Page 20]


  Internet-Draft        SAT Views and View Addresses        September 2025


     [SATA]     Hardjono, T., Hargreaves, M., Smith, N., and V.
                Ramakrishna, "Secure Asset Transfer (SAT) Interoperability
                Architecture, IETF, draft-ietf-satp-architecture-08", July
                2025, <https://datatracker.ietf.org/doc/draft-ietf-satp-
                architecture/>.

     [SATP]     Hargreaves, M., Hardjono, T., Belchior, R., Ramakrishna,
                V., and A. Chiriac, "Secure Asset Transfer Protocol (SATP)
                Core, IETF, draft-ietf-satp-core-11", August 2025,
                <https://datatracker.ietf.org/doc/draft-ietf-satp-core/>.

  10.2.  Informative References

     [Abebe21]  Abebe, E., Hu, Y., Irvin, A., Karunamoorthy, D., Pandit,
                V., Ramakrishna, V., and J. Yu, "Verifiable Observation of
                Permissioned Ledgers (ICBC 2021)", May 2021,
                <https://arxiv.org/abs/2012.07339>.

     [Andr18]   Androulaki, E., Barger, A., Bortnikov, V., Cachin, C.,
                Christidis, K., De Caro, A., Enyeart, D., Ferris, C.,
                Laventman, G., Manevich, Y., Muralidharan, S., Murthy, C.,
                Nguyen, B., Sethi, M., Singh, G., Smith, K., Sorniotti,
                A., Stathakopoulou, C., Vukolic, M., Weed Cocco, S., and
                J. Yellick, "Hyperledger Fabric: A Distributed Operating
                System for Permissioned Blockchains, EuroSys", January
                2018, <https://arxiv.org/abs/1801.10228>.

     [BVGC20]   Belchior, R., Vasconcelos, A., Guerreiro, S., and M.
                Correia, "A Survey on Blockchain Interoperability: Past,
                Present, and Future Trends", May 2020,
                <https://arxiv.org/abs/2005.14282v2>.

     [Clar88]   Clark, D., "The Design Philosophy of the DARPA Internet
                Protocols, ACM Computer Communication Review, Proc SIGCOMM
                88, vol. 18, no. 4, pp. 106-114", August 1988.

     [Ethe22]   "Ethereum whitepaper", September 2022,
                <https://ethereum.org/en/whitepaper/>.

     [Gray81]   Gray, J., "The Transaction Concept: Virtues and
                Limitations, in VLDB Proceedings of the 7th International
                Conference, Cannes, France, September 1981, pp. 144-154",
                September 1981.

     [Hear19]   Hearn, M. and R. G. Brown, "Corda: A Distributed Ledger",
                August 2019, <https://docs.r3.com/en/pdf/corda-technical-
                whitepaper.pdf>.




  Ramakrishna, et al.       Expires 19 March 2026                [Page 21]


  Internet-Draft        SAT Views and View Addresses        September 2025


     [Herl19]   Herlihy, M., "Blockchains from a Distributed Computing
                Perspective, Communications of the ACM, vol. 62, no. 2,
                pp. 78-85", February 2019,
                <https://doi.org/10.1145/3209623>.

     [HLP19]    Hardjono, T., Lipton, A., and A. Pentland, "Towards an
                Interoperability Architecture for Blockchain Autonomous
                Systems, IEEE Transactions on Engineering Management",
                June 2019, <https://ieeexplore.ieee.org/document/8743548>.

     [HS2019]   Hardjono, T. and N. Smith, "Decentralized Trusted
                Computing Base for Blockchain Infrastructure Security,
                Frontiers Journal, Special Issue on Blockchain Technology,
                Vol. 2, No. 24", December 2019,
                <https://doi.org/10.3389/fbloc.2019.00024>.

     [Kiay16]   Kiayias, A., Lamprou, N., and A. Stouka, "Proofs of proofs
                of work with sublinear complexity, International
                Conference on Financial Cryptography and Data Security,
                pages 61–78, Springer", 2016.

     [Kiay17]   Kiayias, A., Miller, A., and D. Zindros, "Non-Interactive
                Proofs of Proof-of-Work, Cryptology ePrint Archive, Paper
                2017/963", September 2017,
                <https://eprint.iacr.org/2017/963>.

     [Naka08]   Nakamoto, S., "Bitcoin: A Peer-to-Peer Electronic Cash
                System, Decentralized Business Review", October 2008,
                <https://bitcoin.org/bitcoin.pdf>.

     [PoA]      Antolin, M., "What Is Proof-of-Authority? Understanding
                PoA Consensus Mechanisms, CoinDesk", June 2022,
                <https://www.coindesk.com/learn/what-is-proof-of-
                authority/>.

     [PoET]     Bowman, M., Das, D., Mandal, A., and H. Montgomery, "On
                Elapsed Time Consensus Protocols, Cryptology ePrint
                Archive, Paper 2021/086", 2021,
                <https://eprint.iacr.org/2021/086>.

     [PoS]      "Proof-of-Stake (PoS) | ethereum.org", September 2022,
                <https://ethereum.org/en/developers/docs/consensus-
                mechanisms/pos/>.

     [SRC84]    Saltzer, J., Reed, D., and D. Clark, "End-to-End Arguments
                in System Design, ACM Transactions on Computer Systems,
                vol. 2, no. 4, pp. 277-288", November 1984.




  Ramakrishna, et al.       Expires 19 March 2026                [Page 22]


  Internet-Draft        SAT Views and View Addresses        September 2025


  Authors' Addresses

     Venkatraman Ramakrishna
     IBM Research
     Email: vramakr2@in.ibm.com


     Vinayaka Pandit
     IBM Research
     Email: pvinayak@in.ibm.com


     Ermyas Abebe
     Consensys
     Email: ermyas.abebe@consensys.net


     Sandeep Nishad
     IBM Research
     Email: sandeep.nishad1@ibm.com


     Krishnasuri Narayanam
     IBM Research
     Email: knaraya3@in.ibm.com


























  Ramakrishna, et al.       Expires 19 March 2026                [Page 23]


