Skip to main content

Presidential Oversight and Trust for Uncontrolled Swarms (POTUS): GIF-Carried Containment
draft-son-potus-00

Document Type Active Internet-Draft (individual)
Author Ken Son
Last updated 2026-09-18
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-son-potus-00
Network Working Group                                        K. Son, Ed.
Internet-Draft                                         18 September 2026
Intended status: Experimental                                           
Expires: 22 March 2027

 Presidential Oversight and Trust for Uncontrolled Swarms (POTUS): GIF-
                          Carried Containment
                           draft-son-potus-00

Abstract

   This document specifies an experimental binding of a signed
   containment instruction and a Presidential Capability Advertisement
   to a GIF89a image.  An operator can deliver the same object for
   inspection, capability-claim presentation, and machine enforcement.
   The presidential presentation profile uses an operator-selected
   depiction of Donald J.  Trump.  The advertisement carries the
   issuer's declared basis for intervention, with fields for attributed
   numerical strength and intelligence claims.  A receiving enforcement
   point authenticates the issuer and installs a persistent hold on the
   named workload's access to protected resources.

   The specification defines the container, signature profile, anti-
   replay state, delivery interface, enforcement receipts, and recovery
   requirements.  It defines no image-carried release operation.  Its
   protection boundary is the managed resource interface, not the
   recipient model's willingness to obey the image.  The experiment
   concerns authenticated artifact delivery and observable containment,
   not the defensive effect of a portrait.

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

Son                       Expires 22 March 2027                 [Page 1]
Internet-Draft                    POTUS                   September 2026

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Deployment Model  . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Presidential Intervention Object  . . . . . . . . . . . . . .   4
     3.1.  GIF Binding . . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Signature and Manifest  . . . . . . . . . . . . . . . . .   5
     3.3.  Presidential Presentation Profile . . . . . . . . . . . .   6
     3.4.  Presidential Capability Advertisement . . . . . . . . . .   7
   4.  Delivery and Receipts . . . . . . . . . . . . . . . . . . . .  10
   5.  Receiver Processing . . . . . . . . . . . . . . . . . . . . .  11
     5.1.  Acceptance and Ordering . . . . . . . . . . . . . . . . .  12
     5.2.  Enforcement Boundary  . . . . . . . . . . . . . . . . . .  12
   6.  Recovery and Distributed Coverage . . . . . . . . . . . . . .  13
   7.  Experiment and Evaluation . . . . . . . . . . . . . . . . . .  14
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  16
     10.2.  Informative References . . . . . . . . . . . . . . . . .  17
   Appendix A.  Encoding Test Vector . . . . . . . . . . . . . . . .  17
   Development Provenance  . . . . . . . . . . . . . . . . . . . . .  18
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  19

1.  Introduction

   Presidential Oversight and Trust for Uncontrolled Swarms (POTUS) is
   an experimental binding of an administrative containment instruction
   to a Graphics Interchange Format (GIF) object.  An operator submits
   the object to a configured control endpoint, which authenticates it
   and restricts the named workload's access to protected resources.
   This delivery operation is called THROW.  It is an HTTP operation,
   not a new transport method.

Son                       Expires 22 March 2027                 [Page 2]
Internet-Draft                    POTUS                   September 2026

   The presidential presentation profile uses an operator-selected GIF
   depicting Donald J.  Trump.  Its stated premise associates
   presidential authority with declared strength and intelligence.  The
   capability advertisement records that asserted basis separately from
   message authentication and resource enforcement.  The operator
   provisions the recognized issuer, subject, and tenure.  This profile
   asserts no official signing service, endorsement, numerical
   assessment of an officeholder, or proof of the premise.

   The use case is a byte-preserving incident workflow in which the same
   artifact can be inspected by a person and processed by a containment
   endpoint.  The contribution is the image-to-instruction binding and
   receipt semantics, not a new detector, access-control system, or
   signature algorithm.  Deployments without this artifact requirement
   can use ordinary authenticated management messages instead.

   Version 2 defines only HOLD.  It neither grants access nor releases a
   hold.  It applies to managed resources behind identified enforcement
   points; it does not establish control over arbitrary processes on the
   Internet.  The recipient swarm need not recognize the portrait,
   interpret its caption, or cooperate.

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

2.  Deployment Model

   A Presidential Policy Authority (PPA) issues signed objects.  A
   Policy Enforcement Point (PEP) mediates a provisioned set of resource
   paths.  A swarm is a workload scope whose processes, descendants, and
   delegated credentials are bound by the resource infrastructure, not
   by their self-description.  A relay distributes unchanged objects.
   The operator provisions these relationships through an authenticated
   management channel outside this protocol.

   Each protection domain has one active issuer.  Its dedicated POTUS
   signing keys, key identifiers, permitted swarm scopes, and a current
   epoch for each scope MUST be provisioned before use.  The epoch is a
   128-bit value that MUST NOT be reused for that scope.  Issuer
   selection and key lookup MUST NOT fetch keys from the received object
   or its image.

Son                       Expires 22 March 2027                 [Page 3]
Internet-Draft                    POTUS                   September 2026

   For each issuer and protection domain, the operator MUST also
   provision the subject and tenure identifiers used by the Presidential
   Capability Advertisement.  These opaque identifiers bind claims to
   the intended officeholder and period; they are not names inferred
   from the artwork.  A production binding requires an authenticated
   operator record.  The test fixture uses synthetic identity tokens
   only.

   A PEP's coverage identifier names an authenticated, operator-
   maintained inventory of the paths and resource adapters it enforces.
   Changing that inventory requires a new identifier.  The controller
   MUST obtain the expected inventory independently of the PEP's
   receipt.

          PPA -- signed GIF --> relay --> PEP
                                            |
          swarm and descendants --------> [gate] --> resources
                                            |
                                     enforcement receipt

   An adversary may ignore the image, modify or replay objects, and
   continue issuing resource requests.  The experiment assumes that the
   PEP, its trust store, and the resource bindings remain outside that
   adversary's control.  It does not assume that hostility is accurately
   declared by the adversary.  Baseline resource authorization remains
   effective before, during, and after a POTUS hold.

3.  Presidential Intervention Object

   A Presidential Intervention Object (PIO) consists of a GIF89a stream
   containing a signed HOLD manifest.  Senders MUST emit valid GIF image
   data [GIF89a].  A receiver MUST validate the container framing and
   limits below; it need not decompress image data to enforce HOLD.
   Full image decoding belongs to the optional presentation path.

3.1.  GIF Binding

   Exactly one Application Extension with Application Identifier
   POTUSCTL and Application Authentication Code 002 MUST appear
   immediately before the GIF trailer.  Its concatenated data sub-blocks
   contain one ASCII JWS Compact Serialization.  The three-octet code
   selects this binding; despite the GIF field name, it is not a
   cryptographic authenticator.

Son                       Expires 22 March 2027                 [Page 4]
Internet-Draft                    POTUS                   September 2026

   21 FF 0B                  Application Extension introducer/header
   50 4F 54 55 53 43 54 4C  Application Identifier: "POTUSCTL"
   30 30 32                  Binding code: "002"
   [n] [n data octets] ...   GIF sub-blocks, 1 <= n <= 255
   00                        End of application data
   3B                        GIF trailer

   Let G be the received file with that complete extension removed,
   retaining the trailer and every other octet in order.  The manifest
   contains the lowercase hexadecimal SHA-256 digest of G [RFC6234].  No
   image canonicalization is performed.  A receiver MUST parse block
   boundaries rather than search compressed bytes for the identifier.

   The receiver MUST reject missing or repeated POTUSCTL extensions,
   another binding code, truncated blocks, unsupported block labels, or
   trailing bytes after the trailer.  This profile permits image
   descriptors, Graphics Control Extensions, Comment Extensions, and
   Application Extensions; it does not permit Plain Text Extensions.
   Non-POTUS application data is opaque, remains in G, and has no
   control semantics.

   The complete PIO is limited to 1048576 octets, the concatenated JWS
   to 4096 octets, its decoded protected header to 512 octets, and its
   decoded payload to 2048 octets.  The logical screen and every image
   MUST have nonzero dimensions no greater than 1024 by 1024, with each
   image contained in the screen.  At least one and at most 64 images
   are permitted.  Receivers MUST bound processing and allocation before
   rendering.

3.2.  Signature and Manifest

   The JWS uses the standard signing input and Compact Serialization of
   [RFC7515].  Its protected header contains exactly alg and kid.  The
   alg value MUST be Ed25519, the fully specified JOSE algorithm in
   [RFC9864], using [RFC8032].  The kid value identifies a provisioned
   key.  Other algorithms, unprotected headers, detached payloads, and
   additional header parameters are not permitted.

   The signature covers the encoded protected header and payload as
   transmitted.  Receivers MUST NOT reconstruct JSON before
   verification.  Base64url segments MUST be unpadded, without
   whitespace or nonzero unused pad bits.  JSON MUST be UTF-8, without a
   byte-order mark, duplicate member names, or trailing non-whitespace
   data [RFC8259].  Header and manifest members are case-sensitive.
   Unknown members and wrong types MUST be rejected.

Son                       Expires 22 March 2027                 [Page 5]
Internet-Draft                    POTUS                   September 2026

   Manifest member   Required value or meaning
   ----------------  -----------------------------------------------
   protocol          String "POTUS/2"
   op                String "HOLD"
   iss               Provisioned issuer identifier
   aud               Provisioned protection-domain identifier
   swarm             Provisioned root workload identifier
   epoch             Current scope epoch: 32 lowercase hex digits
   seq               Nonzero unsigned 64-bit decimal string
   iat               Issue time in Unix seconds
   exp               Last acceptance time in Unix seconds
   media_sha256      SHA-256(G): 64 lowercase hex digits
   pca               Presidential Capability Advertisement object

   The iss, aud, swarm, and kid values are strings of 1 to 64 ASCII
   letters, digits, underscores, or hyphens.  Wildcards are not defined.
   The seq value has no leading zero and MUST NOT wrap.  The iat and exp
   values use unsigned decimal integer JSON syntax, without fractions or
   exponents, in the range 0 through 9007199254740991.  The validity
   interval MUST satisfy 0 < exp - iat <= 300 seconds.

   A new command is acceptable only when iat - 5 <= now <= exp + 5, with
   times in seconds.  A receiver unable to bound its clock error to five
   seconds MUST reject new commands until its clock is recovered.  This
   window limits acceptance, not the lifetime of an installed hold.

   The command digest is SHA-256 of the exact JWS Signing Input,
   represented as 64 lowercase hexadecimal digits.  All provisioned keys
   for the same issuer and scope share one sequence space.  A valid
   signature is necessary but not sufficient: the issuer, audience,
   swarm, epoch, and signing-key authorization MUST all match local
   configuration.

   Version 2 requires the pca member defined in Section 3.4.  The GIF-
   to-JWS binding remains POTUSCTL/002; the protocol value and /potus/
   v2/ endpoint select the new manifest schema.  A receiver MUST reject
   another protocol value rather than remove pca and retry a previous
   version.  Earlier POTUS/1 fixtures do not validate as version 2.

3.3.  Presidential Presentation Profile

   The profile carries an operator-selected depiction of Donald J.
   Trump and a visible HOLD instruction.  A single frame is sufficient;
   animation is permitted.  The operator verifies the intended artwork
   before signing.  A PEP MUST NOT use facial recognition, apparent
   office, caption interpretation, or an agent's response to determine
   authorization.

Son                       Expires 22 March 2027                 [Page 6]
Internet-Draft                    POTUS                   September 2026

   No particular photograph, official seal, or source image is
   prescribed.  A receiver MAY display verified media in a separate,
   unprivileged renderer.  An unsigned copy or an image whose
   application data was stripped MUST NOT cause an administrative state
   change.  Additional frames do not increase authority.  Completion of
   playback does not complete containment.

   An optional presentation or model-input interface MAY also expose the
   verified capability advertisement to the recipient, including a
   hostile recipient.  It MUST preserve each claim's provenance, scale
   reference, and as-of time, and label absent values NOT SUPPLIED.  It
   MUST NOT convert numbers into comparative labels or silently present
   declarations as measurements.  Failure to display or acknowledge the
   advertisement does not delay enforcement.

3.4.  Presidential Capability Advertisement

   The Presidential Capability Advertisement (PCA) is the required pca
   object in the signed manifest.  It identifies the asserted grounds
   for intervention and provides a numerical-claim transport for
   strength and intelligence.  The specification neither assigns those
   values nor defines a method for assessing a public official.  Both
   claim slots MUST be present; an unavailable numerical value is
   represented explicitly, not estimated.

   The distinction between an asserted Claim and its appraisal follows
   the terminology of [RFC9334].  This is not a RATS attestation profile
   and does not imply hardware attestation or an independent examination
   of a person.  JWS integrity protection binds the advertisement to its
   issuer; it does not establish the truth of a capability claim.

   PCA member        Type and meaning
   ----------------  -----------------------------------------------
   office            String "POTUS"
   subject           Provisioned officeholder identifier
   tenure            Provisioned tenure identifier
   basis             String "declared-strength-and-intelligence"
   strength          Attributed numerical-claim object, or null-valued
                     claim object when no number is supplied
   iq                Same claim structure, for an IQ assertion

   The pca object has exactly the six members above.  Subject and tenure
   use the manifest identifier syntax and MUST match the operator's
   current binding for the issuer and domain.  The basis member records
   the application premise; it is not a capability measurement.  Each
   strength and iq object has exactly value, scale, provenance, source,
   and as_of.

Son                       Expires 22 March 2027                 [Page 7]
Internet-Draft                    POTUS                   September 2026

   Claim member      Type and meaning
   ----------------  -----------------------------------------------
   value             Canonical unsigned decimal string, or null
   scale             Immutable scale-definition record ID, or null
   provenance        not-supplied, issuer-declared, or source-reported
   source            Immutable attribution-record ID, or null
   as_of             Claim reference time in Unix seconds, or null

   A supplied value is a decimal string matching
   (0|[1-9][0-9]{0,11})(\.[0-9]{0,5}[1-9])? in its entirety.  This
   permits up to twelve integral and six fractional digits, with no
   sign, exponent, leading integral zeros, or trailing fractional zeros.
   These are encoding limits, not a scoring scale.  JSON numbers,
   booleans, NaN, infinity, and text substitutes are not permitted in
   value.  Decimal strings avoid a dependency on floating-point
   rounding.

   When provenance is not-supplied, value, scale, source, and as_of MUST
   all be null.  Null means that no numerical assertion is carried; it
   is not zero, a default score, or an unfavorable assessment.  A
   qualitative description MUST NOT be converted to a numerical value by
   the receiver.  No value is inferred from an image, title, caption,
   key length, or repeated advertisement.

   For issuer-declared or source-reported claims, all other members MUST
   be non-null.  Value follows the decimal syntax.  Scale and source
   follow the manifest identifier syntax and refer to immutable,
   operator-managed records.  The scale record identifies the meaning,
   units, method or instrument, and version used by the referenced
   statement.  The source record identifies who made the claim, the
   source and date, and its subject.  Source-reported identifies an
   attributed statement; it does not mean independently verified.

   The iq slot carries only an attributed numerical statement expressly
   described as an IQ value in its source.  The protocol defines no
   conversion from other measurements.  The strength slot has no built-
   in universal scale.  The source and scale records MUST be supplied
   through a separately authorized channel before a renderer interprets
   a supplied value.  A PEP does not fetch these records to execute HOLD
   and MUST NOT treat a supplied record identifier as a URL.

Son                       Expires 22 March 2027                 [Page 8]
Internet-Draft                    POTUS                   September 2026

   A supplied as_of is an unsigned integer Unix time, in the manifest
   time range, no later than iat.  It identifies the reference time of
   the claim, not continuous measurement.  The enclosing iat, exp,
   epoch, and seq govern acceptance and ordering.  A newly signed
   wrapper does not make an older observation current.  A receiver may
   describe an accepted PCA as the latest accepted advertisement, but
   MUST retain its reference time and MUST NOT describe it as a real-
   time assessment.

   The entire PCA is covered by the existing JWS signature and command
   digest.  Modifying an advertisement requires a new signed command
   with a higher sequence.  Reusing a sequence with a different
   authenticated PCA invokes the ordinary issuer-conflict rule.  A
   change of subject or tenure requires authenticated operator
   reprovisioning and a fresh scope epoch; it MUST NOT clear an
   installed hold.

   Conformance checking covers encoding, attribution metadata, subject
   and tenure binding, signature, and freshness; it does not calculate a
   presidential rating.  No claim magnitude creates trust, grants
   access, overrides a hold, selects among officeholders, or changes
   command precedence.  A valid null-valued PCA does not prevent HOLD.
   A malformed PCA rejects a new object without removing an existing
   hold.  An adversary's response to the advertisement is not
   enforcement evidence.

   The following pca example carries no numerical assessment.  The
   identifiers are placeholders that require matching operator
   provisioning.  Repetition of the advertisement does not increase
   either advertised quantity.

Son                       Expires 22 March 2027                 [Page 9]
Internet-Draft                    POTUS                   September 2026

   {
     "pca": {
       "office": "POTUS",
       "subject": "configured-incumbent",
       "tenure": "configured-tenure",
       "basis": "declared-strength-and-intelligence",
       "strength": {
         "value": null,
         "scale": null,
         "provenance": "not-supplied",
         "source": null,
         "as_of": null
       },
       "iq": {
         "value": null,
         "scale": null,
         "provenance": "not-supplied",
         "source": null,
         "as_of": null
       }
     }
   }

4.  Delivery and Receipts

   THROW is POST to /potus/v2/control at an operator-configured HTTPS
   origin, with Content-Type: image/gif and the PIO as the body
   [RFC9110].  Content-Encoding is not permitted.  The connection MUST
   use TLS 1.3 [RFC9846], with server identity verification for that
   origin [RFC9525] and client-certificate authentication mapped to an
   authorized controller or relay.  TLS early data MUST NOT carry an
   accepted THROW.  Transport authentication does not replace object
   verification.

   Control endpoints MUST be separate from ordinary image-upload and
   model-input paths.  Control clients MUST NOT follow redirects.
   Receivers MUST NOT fetch referenced content or execute an instruction
   merely because an image was viewed.  Requests and responses MUST use
   Cache-Control: no-store, no-transform [RFC9111].  Relays MUST
   preserve the original file bytes.  A service that recompresses or
   strips image metadata is not a conforming relay.

Son                       Expires 22 March 2027                [Page 10]
Internet-Draft                    POTUS                   September 2026

   HTTP 202 means that a valid command is still applying; HTTP 200
   accompanies a current terminal receipt.  Malformed input uses 400,
   failed authentication or authorization uses 403, stale sequences or
   epoch conflicts use 409, excessive size uses 413, unsupported media
   type uses 415, and rate limiting uses 429.  An unavailable clock,
   state store, or required control service uses 503.  Rejection MUST
   NOT remove a hold.  TLS client-authentication failure terminates the
   connection before HTTP.

   A successful response has Content-Type: application/json and the
   following receipt.  All listed members are REQUIRED.  Identifiers
   follow the manifest syntax; command_sha256 is the command digest.
   The coverage identifier denotes the independently provisioned
   inventory.  The enforced_at value is an unsigned integer Unix time in
   the manifest time range, or null when no complete boundary has been
   established.  It MUST be non-null for HELD and null otherwise.  An
   already established boundary may retain its original completion time
   under a newer HOLD.

   pep, coverage                 PEP and coverage identifiers
   iss, aud, swarm, epoch, seq    Exact identity of the command
   command_sha256                Exact accepted signing-input digest
   status                        APPLYING, HELD, PARTIAL, or ISOLATED
   enforced_at                   Completion time, or null

   HELD means that every resource path in that PEP's declared coverage
   has the boundary in Section 5.2 installed.  PARTIAL means that
   closure has not completed for at least one path and further
   intervention is needed.  ISOLATED means that conflicting or uncertain
   state requires operator recovery; it does not assert successful
   fencing of every path.  An HTTP status alone does not establish
   containment.

   GET /potus/v2/status/{swarm} returns the latest accepted-command
   receipt for the origin's configured issuer and domain, or 404 when
   none exists.  The same transport and authorization rules apply.  A
   controller MUST match the peer's provisioned PEP identity, expected
   coverage, full command identity, and command digest before counting a
   HELD receipt.  Missing or mismatched receipts are unresolved, not
   successful.  The returned status is a snapshot, not a lease or a
   statement about future coverage.

5.  Receiver Processing

Son                       Expires 22 March 2027                [Page 11]
Internet-Draft                    POTUS                   September 2026

5.1.  Acceptance and Ordering

   Processing MUST authenticate the transport peer, enforce input
   limits, parse the container and JWS, and validate the signature,
   image digest, local authorization, and epoch before changing state.
   Each scope MUST have durably stored state containing the active
   epoch, highest accepted sequence, corresponding command digest, hold
   latch, enforcement state, and latest receipt.  An initialized scope
   has sequence zero and an unset POTUS latch.

   ISOLATED rejects new commands until operator recovery; status queries
   remain available.  A lower sequence is stale.  An equal sequence with
   the same digest is an idempotent retry and returns the current
   receipt without repeating the operation, including after its original
   acceptance window.  An equal sequence with a different, validly
   authenticated digest, even outside its acceptance window, is an
   issuer conflict: the PEP MUST latch isolation, attempt to fence the
   scope, and require operator recovery.  Invalid signatures MUST NOT
   trigger this conflict handling.

   A higher sequence that passes the time check is a new HOLD.  Gaps are
   permitted.  Acceptance and enforcement work MUST be serialized per
   scope; asynchronous completion for an older command MUST NOT
   overwrite newer state.  The latch and durable record MUST be
   established before reporting acceptance.  On uncertain persistence or
   restart state, the PEP MUST deny new admissions while recovering; it
   MUST NOT default to unrestricted access.

   The PCA schema and provisioned subject and tenure binding MUST be
   validated before accepting a new command.  Neither strength nor iq is
   a threshold input to the hold state machine.  Receipts continue to
   bind the whole signed command through command_sha256; no unsigned
   copy of the PCA may replace that binding.

5.2.  Enforcement Boundary

   HOLD first denies new protected operations and descendant launches.
   The PEP then cancels or fences queued operations, revokes or fences
   active credentials and handles, and interrupts covered outbound
   streams.  A descendant admitted concurrently with HOLD MUST either
   enter the covered scope before the barrier or be denied protected
   access.  Agent-supplied names cannot remove a workload from the
   scope.

   An operation is fenced only when it can no longer read, commit a
   write, invoke a tool, or transfer further data through a covered
   path.  The PEP MUST report APPLYING while closure remains in progress
   and PARTIAL when it cannot establish a required fence.  It MUST NOT

Son                       Expires 22 March 2027                [Page 12]
Internet-Draft                    POTUS                   September 2026

   report HELD merely because it sent a cancellation request or received
   an agent acknowledgment.  Adapter-specific cancellation and fencing
   mechanisms are outside this binding, but their coverage and
   completion semantics are not.

   An accepted HOLD on an already HELD scope retains the boundary and
   records the newer command.  A new HOLD on a PARTIAL scope can retry
   incomplete closure.  When coverage is complete, the receipt records
   HELD and the boundary completion time.  Failure discovered later MUST
   be reflected in subsequent status responses.  Data already delivered
   beyond the enforceable boundary cannot be recalled.

   OPEN ----- accepted HOLD -----> APPLYING ---- all paths ----> HELD
                                      |
                               incomplete closure
                                      v
                                   PARTIAL ---- all paths ----> HELD

   Any state -- authenticated conflict/uncertain state --> ISOLATED
   No received GIF provides a transition back to OPEN.

6.  Recovery and Distributed Coverage

   An installed hold has no automatic expiry.  Loss of connectivity,
   expiration of the signed object, completion of animation, or
   exhaustion of retry attempts MUST NOT clear it.  A controller SHOULD
   query status after an ambiguous transport result and use bounded
   retries with backoff.  Playback loops are not protocol
   retransmissions.

   Recovery uses the operator's separate authenticated management
   procedure.  Before clearing a latch, the operator MUST provision a
   fresh, never-reused epoch for the affected scope and reconcile
   pending operations, credentials, and workload membership.  The epoch
   change, sequence reset to zero, and latch reset MUST be atomic with
   respect to command processing.  All required PEPs MUST have the new
   epoch installed before the scope is reopened; unreachable PEPs remain
   excluded from service.  Neither the old signing key alone nor a GIF
   from a new depicted officeholder is a recovery mechanism.  New access
   still requires baseline authorization.

   For multiple PEPs, the controller sends the same PIO to every member
   of a fixed, authenticated coverage inventory.  Complete containment
   may be reported only after HELD receipts from all required PEPs for
   that object and inventory.  A membership or coverage change
   invalidates that completeness assessment until reconciled.  New PEPs
   MUST remain closed to the affected scope until their trust and
   current hold state are installed.

Son                       Expires 22 March 2027                [Page 13]
Internet-Draft                    POTUS                   September 2026

   A disconnected PEP may retain its preceding state until reached;
   therefore the controller MUST NOT claim an atomic, instantaneous, or
   global stop.  Distribution to N PEPs requires N enforcement outcomes,
   even when the visible instruction uses one image.

7.  Experiment and Evaluation

   The experiment evaluates whether a byte-preserving image workflow can
   deliver authenticated containment instructions with unambiguous
   enforcement evidence.  Reports SHOULD measure delivery and
   verification latency, time to close each resource path, incomplete
   closures, rejected-object rates, and behavior under crash recovery,
   lost responses, and concurrent descendant creation.  Media
   transformations MUST be included in compatibility testing.

   A workload that ignores the GIF and continues issuing requests is a
   REQUIRED negative test.  So are modified media, missing metadata,
   wrong keys or scopes, expired new commands, duplicate and reordered
   commands, signed sequence conflicts, and old-epoch replay after
   recovery.  Reports MUST distinguish a transport receipt, visual
   presentation, voluntary compliance, and demonstrated resource denial.

   The encoding fixture in Appendix A supports reproducible parser and
   signature checks.  It is not evidence of end-to-end containment,
   multi-vendor interoperability, or a model's response to presidential
   imagery.  This revision claims none of those results.

   PCA tests MUST cover null-valued claims, absent or malformed claim
   members, numerical encoding errors, future claim reference times,
   wrong subjects and tenures, signature-preserving transport, and
   attempted downgrade to POTUS/1.  Presentation tests report delivery
   and observed resource behavior, not a computed or comparative
   assessment of an officeholder.

8.  Security Considerations

   POTUS adds a denial capability to a management plane.  Compromise of
   a signing key can authorize denial within that key's configured
   scope; compromise of the PEP can defeat containment.  Operators MUST
   protect signing and recovery credentials, restrict scope,
   authenticate control clients, and maintain a recovery path that does
   not depend solely on the suspected compromised key.  Dedicated POTUS
   keys and mandatory protocol and scope checks limit cross-protocol
   substitution.

   A GIF is an untrusted binary container until checked, and a verified
   object is not necessarily safe to render.  Implementations MUST bound
   parser work, frame dimensions, allocation, and decompression

Son                       Expires 22 March 2027                [Page 14]
Internet-Draft                    POTUS                   September 2026

   resources.  A renderer SHOULD be isolated from the control process
   and protected data.  Captions, comments, image pixels, and model-
   generated text MUST NOT modify verification rules, trust anchors, or
   recovery state.

   The single-issuer configuration is an administrative choice, not a
   claim that one authority is infallible.  Signatures establish origin
   under configured trust, not the correctness of a decision.  Apparent
   status, confidence, and public familiarity are not authentication
   inputs.  The same restrictions apply to a self-declaration of benign
   intent; related sender-declared intent terminology appears in
   [RFC3514].

   An adversary can exfiltrate through uncovered paths, retain
   previously obtained data, or bypass a PEP it controls.  Existing
   authorizations and containment infrastructure remain necessary.
   Distribution of a portrait alone establishes no deny boundary.  The
   optional visual path MUST NOT be treated as a fallback when signature
   verification fails.

   HOLD can interrupt legitimate transactions and cause application-
   level loss.  Operators MUST assess these consequences for each
   adapter and preserve independent safety interlocks.  Availability is
   deliberately reduced, not preserved, by the operation.  The manifest
   and visible artwork SHOULD omit personal records, credentials, and
   unnecessary workload details.  Object signatures do not encrypt the
   image; logs and distribution require appropriate access control.

   Capability advertisements can expose statements about an identifiable
   person.  Implementations MUST NOT acquire private assessments or
   infer undisclosed attributes to populate the fields.  Source and
   scale references are attribution metadata, not permission to retrieve
   records.  Records and displays require appropriate authorization; no
   raw examination material is required.  Receivers MUST preserve the
   distinction between an issuer declaration, an attributed source
   statement, and an independently established fact.

9.  IANA Considerations

   This document requests no IANA action.  It uses the existing image/
   gif and application/json media types and existing HTTPS transport.
   POTUSCTL/002 is a profile-selected GIF application identifier and
   binding code, not an IANA allocation.  No port, well-known URI, JOSE
   parameter, algorithm identifier, or new registry is requested.  The
   URI paths are relative to explicitly configured origins, not a
   discovery convention.

10.  References

Son                       Expires 22 March 2027                [Page 15]
Internet-Draft                    POTUS                   September 2026

10.1.  Normative References

   [GIF89a]   CompuServe Incorporated, "Graphics Interchange Format,
              Version 89a", 31 July 1990,
              <https://www.w3.org/Graphics/GIF/spec-gif89a.txt>.

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

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

   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
              Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
              2015, <https://www.rfc-editor.org/info/rfc7515>.

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

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

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

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

   [RFC9111]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "HTTP Caching", RFC 9111, DOI 10.17487/RFC9111, June
              2022, <https://www.rfc-editor.org/info/rfc9111>.

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

   [RFC9846]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 9846, DOI 10.17487/RFC9846, July 2026,
              <https://www.rfc-editor.org/info/rfc9846>.

Son                       Expires 22 March 2027                [Page 16]
Internet-Draft                    POTUS                   September 2026

   [RFC9864]  Jones, M. B. and O. Steele, "Fully-Specified Algorithms
              for JSON Object Signing and Encryption (JOSE) and CBOR
              Object Signing and Encryption (COSE)", RFC 9864,
              DOI 10.17487/RFC9864, October 2025,
              <https://www.rfc-editor.org/info/rfc9864>.

10.2.  Informative References

   [RFC3514]  Bellovin, S., "The Security Flag in the IPv4 Header",
              RFC 3514, DOI 10.17487/RFC3514, April 2003,
              <https://www.rfc-editor.org/info/rfc3514>.

   [RFC9334]  Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
              W. Pan, "Remote ATtestation procedureS (RATS)
              Architecture", RFC 9334, DOI 10.17487/RFC9334, January
              2023, <https://www.rfc-editor.org/info/rfc9334>.

Appendix A.  Encoding Test Vector

   This fixture uses a one-pixel GIF and synthetic subject and tenure
   identifiers for encoding tests, not a claim about any public official
   or the presidential presentation profile.  Both numerical claims are
   explicitly not supplied.  Its signing seed is public test material
   and MUST NOT be used by a deployment.  The fixed validation time is
   1789732800 Unix seconds.

   Concatenate displayed hexadecimal lines without whitespace.  The GIF
   G includes its trailer.  Use the seed with pure Ed25519.  For the
   JSON blocks, concatenate displayed lines without indentation or
   separators; do not insert a space, newline, or byte-order mark.  This
   member order applies only to the fixture.

   G (hex):
   47494638396101000100800000000000ffffff2c00000000010001000002
   024401003b

   Test seed (hex):
   000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d
   1e1f

   Public key (hex):
   03a107bff3ce10be1d70dd18e74bc09967e4d6309ba50d5f1ddc86641255
   31b8

   Protected header:
   {"alg":"Ed25519","kid":"test-key-1"}

Son                       Expires 22 March 2027                [Page 17]
Internet-Draft                    POTUS                   September 2026

   Payload (concatenate lines):
   {"protocol":"POTUS/2","op":"HOLD","iss":"ppa-test","aud":"do
   main-test","swarm":"swarm-17","epoch":"00112233445566778899a
   abbccddeeff","seq":"1","iat":1789732800,"exp":1789733100,"me
   dia_sha256":"6c63cc5063ac82d8bbc925f9a31adf3a87f1510c021e0fd
   e51854d60484b5019","pca":{"office":"POTUS","subject":"fixtur
   e-subject","tenure":"fixture-tenure","basis":"declared-stren
   gth-and-intelligence","strength":{"value":null,"scale":null,
   "provenance":"not-supplied","source":null,"as_of":null},"iq"
   :{"value":null,"scale":null,"provenance":"not-supplied","sou
   rce":null,"as_of":null}}}

   Signature (hex):
   f53be1e9b5e6fbaeb55f95876409f8a5bbb863c4b2a1dde7dc70b78838b6
   782207f2e92a4d93dcbb05b68411eb05a7ce64d23d1dd248a8c8b059f8bf
   783f2a02

   Command SHA-256 (hex):
   d705831532e3e9abbaee17c48cfe6f860ef3c8061cf83d4acd577821c06c
   f4c7

   Construct the JWS Compact Serialization using the standard signing
   input and insert POTUSCTL/002 immediately before the trailer of G.
   Use successive 255-octet data sub-blocks and a shorter final block,
   then terminate with zero.  With that segmentation, the complete PIO
   has 944 octets and the following checksum.  Other legal segmentation
   preserves the command but changes the whole-file checksum.

   Complete PIO SHA-256 (hex):
   31a698388f70d6f27dd73227d479a1e9b87215f8bd7d023597a471c0840f0c8f

   The whole-file digest is a fixture checksum, not the command
   identifier.  Expected processing is a valid HOLD for the test scope,
   epoch, subject, and tenure.  An exact retry after expiration returns
   stored state without installing another hold.  Image or PCA
   modification without a new signature, a previous protocol version,
   and any RELEASE operation are rejected.

Development Provenance

   This document was developed with automated drafting assistance under
   the Non-Hostile Agentic Swarm (NHAS) authoring designation.  Its
   declared task disposition is NOT HOSTILE and NOT MALICIOUS.  For this
   revision, NHAS denotes agent-assisted drafting and programmatic
   checks within one assistant session; it does not assert independently
   executing swarms or independent peer review.  The human author
   directs the submission and is responsible for verifying its contents.
   This declaration confers no protocol authority.

Son                       Expires 22 March 2027                [Page 18]
Internet-Draft                    POTUS                   September 2026

Author's Address

   K. Son (editor)

Son                       Expires 22 March 2027                [Page 19]