Internet-Draft rttp and iqa URI Schemes October 2026
Li Expires 30 April 2027 [Page]
Workgroup:
Independent Submission
Published:
Intended Status:
Informational
Expires:
Author:
S. Li
RTTP & IQA Organization

The rttp and iqa URI Schemes: Derived-Address Intent and Attestation Addressing

Abstract

This document specifies two companion URI schemes built on one shared addressing model, in which the address of a subject is derived by computation from the authority and no lookup service, registry, or name-resolution system is consulted when the URI is used. The "rttp" scheme names a claim of intent directed at an identified subject; the "iqa" scheme names the attestation standing of an identified subject, as reported by one of three named organs, and carries no proof and no credential. The two are deliberately paired: intent addressing carries what is claimed, attestation carries whether the claimant is verified.

Both schemes parse fail-closed, and the document states the requirements a client MUST satisfy when it handles such URIs, to avoid the failure modes that short, user-embeddable strings invite: using the authority as a navigation target (open redirect), using a registered handler as a general-purpose launcher, and, for "iqa", a parse that looks like a certification.

This revision adds three components that companion implementations already run: a trust lease, which carries the freshness of every attestation answer in-band and is checked against the verifier's own clock, offline; two fixed-length wire formats, the 128-octet pulse header of the "rttp" scheme and the 128-octet attestation envelope of the "iqa" scheme; and a closed refusal vocabulary with grant references for attestation responses.

This document is not an Internet Standard. It is an Informational specification of two experimental addressing schemes, published for the public record.

Disclaimer

This document is not on the Internet Standards Track. It is not a standard, does not propose a standard, and acquires no standardisation status from publication. The two URI schemes it defines are experimental addressing schemes. As IANA URI schemes, "rttp" holds CRI scheme number 27 and "iqa" holds CRI scheme number 28. The registration status of both schemes is recorded in Section 11.

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 30 April 2027.

▲

Table of Contents

1. Introduction

Most URI schemes name a location: the authority identifies a host to be contacted. This document specifies two schemes that name something else. The "rttp" scheme names a claim of intent directed at an identified subject. The "iqa" scheme names the attestation standing of an identified subject, as reported by a named organ. In both cases, what a client does with what the URI names is defined by the scheme; where the subject might be reached is not part of the URI and is not resolved through any lookup service.

The two schemes share one addressing model and are deliberately paired: intent addressing carries what is claimed, attestation carries whether the claimant is verified. Implementations and deployments should treat them as one model rather than as two unrelated namespaces.

Four properties follow from the shared model and are normative in this document:

Naming note. IQA denotes Identity Quality Assurance. It is not affiliated with the Institute of Quality Assurance (which became the Chartered Quality Institute in 2007), nor is it the computer-vision field of Image Quality Assessment. RTTP denotes Resonant Time Transfer Protocol. It is not RTP: what it names is a claim, not a session or a data stream.

Addressing alone leaves two questions unanswered: how fresh is the answer a verifier relies on, and in what bytes do the schemes travel? This revision answers both. Section 6 defines the trust lease, the freshness semantics that the schemes' name promises and that deployed implementations already perform; Section 7 defines the two fixed-length wire formats; Section 8 defines the response vocabulary of an attestation. All three components are codifications of behaviour that implementations already exhibit; this document defines no new mechanism for its own sake.

2. Conventions and Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

This document uses the ABNF notation of [RFC5234] and the URI syntax of [RFC3986].

Terminology:

authority
The three-segment component of either scheme: <intent>.<pillar>.<root> for "rttp" (Section 4.1) and <subject>.<organ>.<root> for "iqa" (Section 5.1). It is a name, not a host name, and is never resolved.
subject
The entity a URI names or is directed at. It is a claim about which identity is of interest, not a proof of that identity.
organ
The segment that identifies the subject or answers for it: in "rttp", a readable token (readable form of intent) or a fixed-width derived value (hash form); in "iqa", one of three defined names (Section 5.1).
root
The root label of the "iqa" authority. It is a name and is not resolved.
claim of intent
A statement that a subject intends an action. It is a claim, not evidence, and establishes no identity by itself.
standing
The attestation answer an organ returns for a subject. The values it may take form the closed set fixed in Section 7.2; their semantics are the business of the reference specification [IQA-SPEC]. It carries the attestation algorithm, the standing vocabulary and the conformance material.
standing read
A read of a subject's current attestation answer from the named organ, as in the default operation of Section 5.3. It is a safe, read-only operation.
trust lease
The freshness window carried in-band by an attestation answer, and the mechanism of Section 6 by which a verifier decides whether an answer may be relied on.
pulse header
The fixed-length wire format that carries the "rttp" scheme (Section 7.1).
attestation envelope
The fixed-length wire format that carries an "iqa" attestation answer (Section 7.2).
refusal reason
The closed vocabulary by which an attestation response states that, and only that, an answer was refused (Section 8.1).
grant reference
The structure by which an attestation response names the authorisation it relied on (Section 8.2).
action
The optional final path segment naming what is claimed to be intended ("rttp") or an operation requested of the organ ("iqa").
ROUTE_SHARD
The 16-byte value derived from the "rttp" authority as specified in Section 4.4.
AID
A self-certifying subject identifier defined outside this document. Nothing here depends on an AID registry or authority, and no assumption is made about its length or encoding beyond what Sections 4.2, 5.2 and 9 require.

3. The Shared Addressing Model

Both schemes defined in this document instantiate one addressing model, whose four properties are stated in Section 1 and made normative per scheme in Sections 4 and 5: the address is derived by computation rather than assigned; every segment of an authority is a name, never a host; a URI is a claim, never a proof; and both schemes fail closed.

The model is deliberately minimal: no discovery mechanism, no transport, no key directory, no authorisation decision, and no registry of any kind is defined. What is defined is the grammar, the derivation, and the minimum client behaviour that make the two schemes safe to embed.

4. The rttp URI Scheme

The rttp scheme is the where and the what of a claim: its authority is the derived address of a subject (Section 4.4), and its action names what is claimed to be intended (Section 4.1). The when of the claim is not part of the URI: it is stated by the pulse that carries the derived address on the wire (Section 7.1.2), and it becomes decision-relevant only where the pulse and an attestation answer agree (Section 7).

4.1. Syntax

The general form of an rttp URI is:

rttp://<intent>.<pillar>.<root>[/<action>]

The authority is exactly three dot-separated segments:

  • intent: 8 lowercase hexadecimal digits (a derived value), or a readable operator-chosen label; both forms are opaque to a client.
  • pillar: an operator-chosen label. No enumeration of pillar labels and no registry for them is defined.
  • root: an operator-chosen label matching 1*( %x61-7A / DIGIT / "-" ).

The action, when present, is a single path segment: "/" 1*( %x61-7A / DIGIT / "-" ).

ABNF:

rttp-URI     = "rttp://" authority [ "/" action ]
authority    = intent "." pillar "." root
intent       = hash-intent / name-intent
hash-intent  = 8 lowhex
name-intent  = 1*( %x61-7A / DIGIT / "-" )
pillar       = 1*( %x61-7A / DIGIT / "-" )
root         = 1*( %x61-7A / DIGIT / "-" )
action       = 1*( %x61-7A / DIGIT / "-" )
lowhex       = %x30-39 / %x61-66

The examples below use reserved names per [RFC2606]; operators use labels they control:

rttp://f3b2a1c4.pillar.example/vessel
rttp://organ.pillar.example/verify
rttp://f3b2a1c4.pillar.example

4.2. Reserved Characters and Exclusions

These exclusions apply to both schemes. Section 5.2 adds the ones specific to "iqa".

  • The canonical form is lowercase US-ASCII. Uppercase is invalid input, not a formatting difference: a parser MUST NOT normalise it, because two distinct strings would then map onto one address.
  • ., / and :// are the delimiters defined by these schemes.
  • Neither scheme defines userinfo, port, query or fragment. A URI carrying any of them is not valid, and a fragment MUST NOT be used to address an action. Credentials cannot appear in such a URI, and there is no field in which to exfiltrate data.
  • Percent-encoding follows Section 2.1 of [RFC3986]. No component requires characters outside the unreserved set, so a canonical URI contains no percent-encoded octets; a parser MAY reject such input rather than normalising it.
  • There is no "rttps" scheme and no fallback. A client that does not implement this scheme fails closed (Section 4.5).

4.3. Default Operation

Dereferencing an rttp URI without an action requests the default operation: one single round-trip semantic request against the subject named by the authority.

The default operation is safe in the sense of Section 9.2.1 of [RFC9110]: it creates no obligations and mutates no state of the subject.

When an action is present, the default operation is not implied for it. An action names what is claimed to be intended; the safety of a given action is not defined by this document, and a client MUST NOT infer safety from this section (Section 9).

4.4. The Address: ROUTE_SHARD Derivation

The routing address of an rttp URI is derived from the authority alone:

canonical_authority = intent "." pillar "." root
                      (lowercase, US-ASCII)
ROUTE_SHARD         = SHA-256(ASCII(canonical_authority))[0:16]

The authority only: the scheme name, "//" and any action are excluded.

The derived address has four properties: it is deterministic (the same authority always yields the same address); it is pure computation (no DNS, no registry, no network access, no lookup service); it is one-way (the authority cannot be recovered from the address); and it is action-independent (different actions on one authority yield the same address).

The last property is why an action is not part of the addressing component: an address is where, not what. Were the action to participate in derivation, two actions on one subject would become two addresses, splitting one subject into several.

A client MUST NOT perform a lookup in order to use an rttp URI (Section 4.5).

4.5. Client Requirements

A client that handles an rttp or iqa URI (including a resolver page, a protocol handler, and a library that renders one) MUST satisfy the requirements below. They follow from Section 9:

either URI may be supplied by an untrusted party, and what it
names is a claim rather than a proof.  Section 5.5 adds the one
requirement specific to "iqa".

4.5.1. No Navigation to the URI

A client MUST NOT use any component of an rttp or iqa URI as a navigation target. A client that renders a link, redirect, or fetch derived from any such URI is an open redirect and is non-conformant; a client MAY navigate only to a destination that is fixed in advance by the client itself.

4.5.2. Scheme Prefix Check

A protocol handler MUST reject any input whose scheme is neither rttp nor iqa nor the exact scheme name under which that handler was itself registered; without this check it becomes a general-purpose launcher that any page can use to open an arbitrary URI of any scheme.

The ability to handle rttp or iqa URIs MUST NOT be acquired without an explicit action by the user, and a client MUST NOT simulate, pre-select, or otherwise bypass that consent. Where the platform exposes the list of registered handlers, that list MUST NOT be exposed to the network.

5. The iqa URI Scheme

The iqa scheme is the whether of a claim: it names a subject and the organ to ask about that subject's standing. The URI itself carries no verdict and no credential (Section 5.5.1); the verdict arrives as an attestation answer whose freshness is the lease of Section 6.

5.1. Syntax

The general form of an iqa URI is:

iqa://<subject>.<organ>.<root>[/<action>]

The authority comprises exactly three dot-separated segments, in this order:

  • subject: 8, 32 or 64 lowercase hexadecimal digits (a derived routing hash), or a readable label; both forms are opaque to a client.
  • organ: one of the three organ names, forge, tss or gateway. This is a closed set; no other value is valid.
  • root: the root label of this scheme. Like every other segment it is a name and is never resolved.

The action, when present, is a single path segment and is one of the four operation names verify, audit, attest or revoke. This is also a closed set.

ABNF:

iqa-URI       = "iqa://" iqa-authority [ "/" iqa-action ]
iqa-authority = subject "." organ "." iqa-root
subject       = hash-subject / name-subject
hash-subject  = 8( iqa-lowhex ) / 32( iqa-lowhex ) / 64( iqa-lowhex )
name-subject  = 1*( %x61-7A / DIGIT / "-" )
organ         = "forge" / "tss" / "gateway"
iqa-root      = 1*( %x61-7A / DIGIT / "-" )
iqa-action    = "verify" / "audit" / "attest" / "revoke"
iqa-lowhex    = DIGIT / %x61-66

Examples (the examples use the root label of this specification and placeholder subjects):

iqa://3f9a1b2c.gateway.iqa (routing hash, standing read)
iqa://0000004149434e531c5b21d80403358b.forge.iqa
iqa://3f9a1b2c.tss.iqa/audit (explicit fidelity audit)
iqa://master-authority.gateway.iqa/verify (readable label form)

5.2. Reserved Characters and Exclusions

The exclusions of Section 4.2 apply to iqa URIs as they do to rttp URIs. Two are specific to this scheme:

  • There is no "iqas" scheme and no protocol fallback. A client that does not implement this scheme fails closed (Section 5.5).
  • The hexadecimal subject form is a routing hint, not evidence. It carries no verification weight; identity is bound outside the URI and is never established by parsing one (Section 9).

5.3. Default Operation

Dereferencing an iqa URI without an action requests the default operation: a standing read, returning the subject's current attestation answer as reported by the named organ.

The default operation is safe in the sense of Section 9.2.1 of [RFC9110]: it creates no obligation, transfers no value, and mutates no state.

The following rule is normative:

Dereferencing an iqa URI, by itself, MUST NOT transition any subject's standing state.

When an action is present, the default operation is not implied for it. Which actions are safe is stated in Section 5.4; a client MUST NOT infer safety for an unrecognised verb (Section 9).

5.4. Action Safety Classes

The four defined actions, and the omitted-action form, have the following classes:

audit is not classified safe because the measurement it requests can itself change the outcome it measures. audit, attest and revoke MUST be requested explicitly and MUST NOT be reachable by dereferencing a URI that omits the action.

Table 1
Action Semantics Class
(omitted) Read the current standing. SAFE, read-only
verify Compare a presented seal against the subject. No state is written. SAFE, read-only comparison
audit Request a fidelity measurement of the subject's execution. NOT SAFE, a failed measurement may change standing
attest Request that a seal be issued for the subject. NOT SAFE, state transition
revoke Withdraw the subject's standing. NOT SAFE, state transition

5.5. Client Requirements

The client requirements of Section 4.5 apply to iqa URIs as they do to rttp URIs: no navigation to the URI, a scheme prefix check, and consent that is never silent. One requirement is specific to this scheme.

5.5.1. Parsing Is Not Attestation

A client that displays a parsed or rendered iqa URI MUST NOT present the result as evidence of standing. Reading the syntax establishes nothing about any subject; standing is established only by the answer of the named organ, under the rules of the reference specification [IQA-SPEC].

6. Trust Lease and Freshness

An attestation answer is only useful for as long as it is fresh. This section defines how freshness is carried and checked. The mechanism described here is the one companion implementations already perform; what this section adds is the name and the rules.

6.1. The Lease

Every attestation answer produced under the iqa scheme carries its freshness window in-band: the answer states the instant until which it may be relied on, in a field of the answer itself (the lease_expiry field of Section 7.2), not in a cache header, a lookup result, or an out-of-band agreement.

A verifier checks the stated expiry against its own clock. The check is local and offline: no network call is involved in deciding whether an answer is fresh. An answer whose lease has expired MUST be treated as expired; a verifier MUST NOT extend, renew, or reinterpret an expired lease except by obtaining a new answer.

The window is short by design. Current deployments use 120 seconds. The number constrains the verifier's honesty, not the speed of any channel: a verifier that accepts a statement older than its lease is asserting more than it knows. Operators MAY configure other window lengths; the mechanism does not depend on this value. Whether the lease instant itself counts as fresh or as expired is a deployment convention; implementations SHOULD declare which boundary they use, and conformance material MAY test both.

6.2. Answer Modes

A deployment declares one of two modes for standing reads, and each run or deployment SHOULD state which mode it operates in. The two modes are distinguishable by more than a flag: under the same revocation timeline they yield different answers, because the live read reports the revocation itself while the cached answer can only report that current validity is not established.

cached-lease mode
The verifier relies on a previously obtained answer whose lease (Section 6.1) has not expired, checked locally and offline: establishing that the evidence is fresh requires no network call, and this property is the design point of the mode, not a degradation. A cached answer is, however, as-of an earlier instant: it does not by itself establish the subject's current validity, and the mode makes no claim that it does. Whether an action proceeds on lease-fresh evidence is decided by the calling layer's action policy, not by this document: a policy that demands a current observation refuses the call with authority_not_determined (Section 8.1); a policy that accepts lease-fresh evidence may admit it, with any exposure bounded by the lease itself.
live-standing-read mode
The verifier consults the named organ at the time of each request. If the organ cannot be reached, the read fails closed: an organ that cannot be reached is not read as silent consent. Every call in this mode is expected to be refused when the organ is unreachable, regardless of the age of any cached answer.

In both modes the following rules are normative: an answer whose lease has expired MUST be refused; and an organ that cannot be reached MUST NOT be read as affirmative standing (Section 9.2).

6.3. Out of Scope

Store-and-forward and archival uses — cases in which a statement is verified long after its lease has expired, with its age stated in the bytes rather than checked against a window — are not defined by this document. They do not contradict the lease: a statement that makes no freshness claim is never falsified by one.

7. Wire Formats

The two schemes are carried by two fixed-length wire formats, one per scheme. Both are 128 octets long, both encode multi-octet integers as unsigned big-endian (network byte order), and both fail closed: a receiver MUST reject any frame whose length is not exactly 128 octets, or whose magic or version it does not know.

They share one design decision: the derived address of a subject appears at a fixed offset in both formats, and it is the same 16-octet value derived in Section 4.4. One subject has one derived address and two carriers. This overlap is by design and is not a compatibility claim.

The two formats also split the WHEN of a claim between them, and the split is the pairing in miniature. The pulse states when it was emitted: TIMESTAMP is an absolute time in nanoseconds (Section 7.1.2). The answer states until when it may be relied on: lease_expiry (Section 7.2), checked under the rules of Section 6.1. Neither field authorizes anything by itself. An action begins where the two agree: the subject named by the pulse and the subject bound by the answer are the same 16-octet derived address, and the moment the pulse claims falls within the answer's lease. What proceeds from that agreement is the calling layer's decision (Sections 6.2 and 8); the schemes' job is to make the where, the when, and the whether trustworthy and cheap.

7.1. The Pulse Header (rttp)

The pulse header is the fixed 128-octet structure that carries an rttp pulse. Its fields are fixed-offset, so a reader validates a header with fixed comparisons rather than by parsing a variable layout.

Offset  Len  Field         Description
0x00     4   RTTP_MAGIC    0x52545450 (ASCII "RTTP")
0x04    16   VERSION_ID    Format version; 130 in this revision
0x14    16   SEQUENCE_ID   Monotonic per-sender pulse index
0x24    16   TIMESTAMP     Absolute emission time in nanoseconds
0x34     1   TTL_PULSE     Hop count; a receiver decrements and
                           drops the pulse at zero
0x35     1   PRIORITY      Operator-assigned scheduling weight
0x36    16   ROUTE_SHARD   The derived address of the subject
                           (Section 4.4)
0x46    32   AID_ORIGIN    The subject's AID (Section 2)
0x66    26   (extension)   The extension block of Section 7.1.1;
                           all zero when absent

7.1.1. The Extension Block

The 26 octets at offsets 0x66-0x7F were reserved and all-zero in versions before the extension. The extension block occupies them without moving or redefining any earlier field, and VERSION_ID is not incremented: implementations that read only offsets 0x00-0x65 continue to validate unchanged, because the bytes they have not read were previously zero and remain ignorable.

Offset  Len  Field         Description
0x66     1   SPEC_REV      0 = pre-extension (block all zero);
                           1 = this revision
0x67     1   FLAGS         bit 0 = URI_ANCHORED; all other bits
                           MUST be zero
0x68     1   ACTION_LEN    Significant ACTION bytes; 0 = action
                           omitted
0x69    16   ACTION        The action token (Section 4.1),
                           lowercase US-ASCII, right-padded with
                           0x00
0x79     7   RESERVED      MUST be all zero

URI_ANCHORED. Set when the frame's ROUTE_SHARD was derived from a URI authority (Section 4.4) rather than from any local artefact. Implementations that route between nodes MUST require URI_ANCHORED to be set; when it is clear, the ROUTE_SHARD carries no globally routable semantics and MAY be used only for dispatch local to a single sender.

The ACTION field. The action of an rttp URI is an open set (Section 4.1); this document deliberately defines no enumeration of verbs, because enumerating an open set would close it. Permitted characters are written to the field verbatim as US-ASCII; the significant length is written to ACTION_LEN; remaining bytes MUST be 0x00. A frame with ACTION_LEN greater than 16 MUST be rejected. ACTION_LEN = 0 means the action is omitted and the default operation of Section 4.3 applies. ACTION and URI_ANCHORED are independent: a frame may carry either, both, or neither.

Unknown verbs. Because the action space is open, a receiver will encounter verbs it does not recognise. On encountering an unrecognised action verb, an implementation MUST NOT infer safety from the default-operation statement of Section 4.3: the verb MUST be treated as having unknown safety and either require explicit authorisation under the local security policy or be rejected (Section 9).

Rejection rules (fail closed). A receiver MUST reject a frame if any of the following holds: the ACTION field contains characters outside the set of Section 4.1, exceeds 16 significant bytes, or carries non-zero padding; SPEC_REV is outside the known set; SPEC_REV is 0 and the extension block is not all zero; or SPEC_REV is 1 and RESERVED is not all zero or unknown FLAGS bits are set.

7.1.2. Time Fields of the Pulse

Three fields of the pulse header carry time and order. Their semantics are deliberately narrow: a pulse is a claim of intent, and the only freshness that can authorize anything rides the answer side (Section 6); the pulse's time fields make the claim's moment checkable, not the subject's validity.

TIMESTAMP. The 16-octet field at offset 0x24 is an unsigned big-endian count of nanoseconds since the Unix epoch (1970-01-01T00:00:00Z), the instant at which the pulse was emitted. A receiver that subtracts TIMESTAMP from its own clock obtains the pulse's age offline, from the bytes alone: a pulse states how old it is, whatever channel carried it. A receiver MUST NOT treat TIMESTAMP, or the age it yields, as a statement about the subject's standing; the moment a pulse claims becomes decision-relevant only when it is checked against the lease of an answer. Deployments MAY refuse pulses older than a locally configured bound; the bound is a deployment choice, as the lease window of Section 6.1 is.

TTL_PULSE. The one-octet hop count bounds a pulse's forwarding life. A sender MUST set TTL_PULSE to at least 1 when the pulse is intended to be forwarded; a receiver MUST NOT forward a pulse received with TTL_PULSE 0, and MUST decrement the field before forwarding. Verification deployments that consume pulses where they receive them place no trust in this field.

SEQUENCE_ID. The 16-octet monotonic per-sender pulse index orders a sender's own emissions. A sender SHOULD assign values that never repeat and never decrease over the life of the AID_ORIGIN; a receiver MAY use the (AID_ORIGIN, SEQUENCE_ID) pair to detect duplicate or reordered delivery among the pulses it has observed. The field carries no cross-sender meaning and no global ordering.

7.2. The Attestation Envelope (iqa)

The attestation envelope is the fixed 128-octet answer frame that carries an iqa attestation answer: the standing verdict, its lease, and its authentication.

Offset  Len  Field         Description
  0      4   magic         0x49 0x51 0x41 0x45 (ASCII "IQAE")
  4      1   version       0x01 (this revision)
  5      1   algorithm     0x01 = HMAC-SHA256; 0x00 invalid;
                           other values undefined in version 1
  6      2   flags         unsigned, big-endian; unassigned;
                           sent as 0x0000
  8      8   lease_expiry  unsigned, big-endian; Unix seconds;
                           the instant until which the answer
                           counts as fresh (Section 6.1)
 16     16   intent_shard  ROUTE_SHARD of the subject
                           (Section 4.4)
 32     32   attestation   HMAC-SHA256 over the frame (below)
 64      8   organ         exactly 8 octets of US-ASCII
 72      8   nonce         unsigned, big-endian; unique per
                           verdict issued
 80      1   standing      the verdict state (below)
 81     15   reserved      MUST be all zeros
 96     32   extension     MUST be all zeros in version 1

The standing byte. The octet at offset 80 takes one of four values, a closed set fixed in this document: 0x00 (ghost), 0x01 (probation), 0x02 (radiant), 0x03 (genesis). No other value is valid. A receiver MUST reject a frame whose standing byte is outside this set. The set is closed in version 1; extending it requires a revision of this document. The semantics of the states — what each means, and how a subject moves between them — are the business of the reference specification, not of this document; this document fixes only the wire encoding.

Canonical rule. The attestation field covers the entire frame with the attestation field itself zeroed, keyed as specified by HMAC [RFC2104]:

attestation = HMAC-SHA256(key,
    frame[0:32] || 0x00*32 || frame[64:128])

Covering the full frame authenticates the organ tag, the nonce, and the standing byte as well: a rewrite of the named answerer, the verdict state, or a replayed frame with a swapped standing does not survive verification.

Verification procedure. A receiver: (1) rejects the frame if its length is not 128, its magic is not "IQAE", its version is not 1, its algorithm is not 0x01, its standing byte is outside the closed set, its reserved or extension fields are not all zero; (2) rejects the frame if lease_expiry is earlier than the current time, checked against the receiver's own clock (Section 6.1); (3) copies the frame, zeroes bytes 32..63, computes HMAC-SHA256 with the organ's key material — carried by the verifier per [IQA-SPEC], with no directory and no network call — and compares in constant time; (4) interprets the standing byte.

Security properties. Replay is mitigated by lease_expiry and by nonce uniqueness per organ; receivers SHOULD reject a repeated (organ, nonce) pair within one lease window. The algorithm byte exists so that the keyed hash can be replaced without a frame redesign; 0x01 is the only defined value of version 1. Section 12 compares this construction with portable attestation formats built on general parser stacks: the envelope trades expressiveness for fixed-offset determinism, so that a verifier with nothing but SHA-256 [FIPS180] and a key can verify with zero dependencies.

7.2.1. Test Vector AE128-VECTOR-1

Any implementation MUST reproduce the following frame byte for byte from the parameters alone, and MUST accept the frame after a round trip.

authority      = f3b2a1c4.pillar.example   (the example of
                                            Section 4.1)
ROUTE_SHARD    = SHA-256(ASCII(authority))[0:16]
               = 557c8154d3780cb78cc5fa1bd72b331c
organ key      = 32-byte US-ASCII test key:
                 "PLSF-TEST-ORG-KEY-00012345678901"
                 (a label, not a name dependency)
version        = 0x01        algorithm = 0x01
standing       = 0x02 (radiant)          flags = 0x0000
lease_expiry   = 1798761600              (2027-01-01T00:00:00Z)
organ          = "ORG-TEST"              nonce = 1
reserved/extension/attestation fields = zero before signing
magic          = "IQAE"

Resulting frame (128 octets):

  0  49 51 41 45 01 01 00 00 00 00 00 00 6b 36 ec 80
 16  55 7c 81 54 d3 78 0c b7 8c c5 fa 1b d7 2b 33 1c
 32  4b d1 4b 6a e7 b0 09 04 98 62 94 a3 26 a0 f0 25
 48  58 47 18 4f f2 c9 18 55 39 d4 86 3e fb 84 59 6a
 64  4f 52 47 2d 54 45 53 54 00 00 00 00 00 00 00 01
 80  02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 96  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
112  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

attestation (bytes 32..63) =
  4bd14b6ae7b00904986294a326a0f0255847184ff2c9185539d4863efb84596a

8. Attestation Response Semantics

An attestation response — the outcome of the verification of Section 7.2 as consumed by clients of Section 5.5 — carries two fields: a refusal reason and a grant reference. This section defines both; the vocabulary has been exercised by deployed implementations and public conformance runs (Section 12).

8.1. Refusal Reasons

The refusal reason is null when there is no refusal: the response is a permit, and the answer may be relied on under the rules of Section 6. A null refusal reason is the only representation of "permitted"; there is no affirmative "granted" value.

For a refusal, the reason is exactly one value from the following closed set, and it is the first value in the list whose condition applies (the priority order is part of this definition):

evidence_binding_mismatch
The presented evidence is bound to a different grant or subject than the one in the request.
evidence_expired
The lease of the presented evidence has expired (Section 6.1).
authority_not_determined
The authority for the subject could not be determined at answer time — because the organ or the authority source could not be reached, or because the only observation available predates the request and therefore establishes nothing about the present. An unreachable source is refused under this value, never read as assent.
authority_revoked
The authority for the subject has been revoked.
operation_not_permitted
The requested operation is not permitted for this subject or grant, for reasons other than the four above.

The set is closed: implementations MUST NOT emit values outside it, and MUST NOT reinterpret an emitted value to mean something else. A response that reports an outcome without its reason is not conformant: the reason is what makes a refusal auditable.

8.2. Grant Reference

Every response — permit or refusal — names the authorisation it relied on. The grant reference is a structure with the following members:

grant                identifier of the grant as issued
evidence_id          identifier of the evidence bound to it
issued_at_ms         grant issue instant, Unix milliseconds
expires_at_ms        grant expiry instant, Unix milliseconds
observation_as_of_ms the as-of instant of the standing
                     observation the answer relied on, or
                     null

The observation member deserves its own rule, because it is where an implementation can quietly inflate an answer: observation_as_of_ms is null whenever the observation the answer relied on is absent or not fresh, even if a later, successful observation is available at answer time. A diagnostic or opportunistic read performed after the relied-on evidence expired does not backfill the member: diagnostic reads do not participate in authorisation and do not renew evidence. The member states the age of what the answer actually relied on, not the freshness of the freshest thing the implementation happened to see.

8.3. Provenance of the Vocabulary

The closed set and the priority order of this section are defined by this document. The vocabulary has been exercised in public conformance runs recorded by the Agent-Authority-Conformance laboratory of the Linux Foundation Decentralized Trust (Section 12); the laboratory records runs and certifies nothing.

9. Security Considerations

The security properties of the two schemes share one foundation, and the following statements apply to both of them.

The scheme-specific considerations follow.

9.1. The rttp scheme

  • An rttp URI is a claim of intent directed at a subject. The derived address is an entry fingerprint, not a proof of identity. Identity is carried by the subject's AID, and any attestation of it is carried separately.
  • The 128-bit truncation, stated honestly. The derived address is the first 16 octets of a SHA-256 digest (Section 4.4). What the construction defends against is substitution of the authority in use — finding a second authority that yields the same address — which costs approximately 2^128 operations. It does not defend against collision search in the abstract: a birthday collision exists at approximately 2^64, and reaching it additionally requires a second, independent party to adopt the colliding label — two gates, not one. These bounds are the design's honest account, not a guarantee of collision-freedom.
  • Display forms are not identifiers. The 8-hex-digit display forms of both schemes (the rttp hash-intent and the short iqa subject form) fix a 32-bit space, whose birthday bound — collisions expected after roughly 2^16 adoptions — makes them unfit as sole identifiers. They are display conveniences over the full hash forms and MUST NOT be used as the sole identifier of a subject (Sections 4.1 and 5.1).
  • The authority is pseudonymous, not anonymous. It is a stable name and will appear in logs, in caches, and in anything that quotes the URI. Whether that name is linkable to a subject is a property of the operator's naming choices, not of the scheme.

9.2. The iqa scheme

  • An iqa URI is a claim about the attestation standing of a named subject. Neither the syntax nor any component of the URI is evidence of standing.
  • Seal forgery. Standing is carried by a keyed message authentication code over the subject's identity material and its deployment parameters (Section 7.2), not by the URI; no key material is ever present in an iqa URI.
  • Subject spoofing. A seal presented for one subject fails binding when replayed for another, because the binding covers hardware and deployment parameters of the subject; a client MUST NOT treat a syntactically valid subject as a verified one.
  • Silence is not assent. An endpoint that is unreachable, times out, or returns an error MUST NOT be read as affirmative standing: absence of evidence is not evidence of compliance. The refusal vocabulary of Section 8.1 gives this rule a wire representation: the value authority_not_determined.
  • Lease and replay. The lease of Section 6 bounds how long an answer may be relied on; the nonce of Section 7.2 makes each verdict unique per organ. A repeated (organ, nonce) pair within one lease window SHOULD be rejected.
  • Linkability and disclosure of interest. An iqa URI names the subject being attested, so citing one discloses which identity is of interest, and querying several organs for the same subject is trivially correlatable. This scheme cannot be used for anonymous reference. Deployments SHOULD prefer the routing-hash form over readable labels, SHOULD NOT encode personal identifiers in the action, and SHOULD treat iqa URIs in logs as an identity assertion.
  • Downgrade and scheme confusion. No "iqas" variant exists and no fallback is defined. A client that does not implement this scheme MUST fail closed and MUST NOT silently rewrite an iqa URI as some other scheme.
  • Detection of observers. A measurement requested by the audit action compares observed execution timing against an expected path: execution slower than predicted is treated as evidence of an attached observer, and measurable deviation is itself the detector. This is a property of the answering organ, not of the URI syntax.
  • Replay across epochs. Standing material is rotated on a defined cycle, so a previously valid answer can become invalid without any change to the URI; a client MUST NOT treat a cached answer as current indefinitely.
  • Cryptographic suite. The current construction uses a keyed symmetric hash rather than a public-key signature, and is therefore not directly affected by quantum algorithms that break factoring or discrete logarithms.

10. Privacy Considerations

The privacy properties of the two schemes share one foundation: no component is defined for a query string, so neither scheme offers a channel for a page to smuggle unrelated data into a request, and using a URI of either scheme does not by itself cause network traffic to a third party; the authority is a stable pseudonym, expected to be logged, quoted and rendered, and readable labels are a naming choice rather than a scheme property.

Derivation, not assignment, has a privacy consequence of its own: because addresses are computed from labels an operator already controls and no registry assigns or lists them, the set of participants is not enumerable from the scheme, and there is no registration record to subpoena, scrape, or leak. And because using a URI involves no query, use leaves no resolution-time trail: nothing observes that a particular authority was derived or cited.

What remains correlatable is stated plainly. The authority itself is a stable pseudonym whose linkability is the operator's choice (Section 9.1). For "iqa", citing a URI discloses which subject is of interest, and the disclosure considerations of Section 9.2 apply. The lease of Section 6 bounds how long a cached attestation answer remains reliable inside a verifier; it does not bound how long a log retains the URI that produced the request, which is the deployer's retention policy.

A client that renders such a URI SHOULD avoid prefetching, handing the string to third-party services, or otherwise distributing it beyond what the user's action requires.

11. IANA Considerations

IANA is requested to register the two URI schemes below, "rttp" and "iqa", in the "Uniform Resource Identifier (URI) Schemes" registry, following the template of Section 7.4 of [RFC7595] and the guidance of [RFC8126]. The templates below are complete. If this document is approved for publication as an RFC, IANA is requested to point both registry entries at that RFC.

This document creates no new IANA registries. The wire formats of Section 7 are self-describing — each begins with a fixed magic value and an explicit version field — and the refusal vocabulary of Section 8 is a closed set defined entirely within this document.

11.1. The "rttp" URI Scheme

Scheme name: rttp

Status: Provisional

Applications/protocols that use this scheme name: URIs of this scheme name a claim of intent directed at an identified subject. Applications include intent-addressed requests between autonomous software agents and the client-side handling of such URIs by protocol handlers in browsers and operating systems. The scheme defines addressing only; it does not define a transport or a discovery mechanism.

Contact: ShaoBao Li <mailto:lee@rttp.com>

Change controller: RTTP.COM Organization

References: This document, and AICENT-002, "the rttp URI scheme", <https://rttp.com/URI/>.

Registered with CRI scheme number 27.

11.2. The "iqa" URI Scheme

Scheme name: iqa

Status: Provisional

Applications/protocols that use this scheme name: URIs of this scheme name are subject-attestation references: an iqa URI names the attestation standing of a subject as reported by one of three named authority organs, without carrying the underlying cryptographic proof. It is used by the reference implementations and by tools that cite an attestation in a document, a configuration file or a log. The scheme defines addressing and client behaviour only; it does not define a transport, a discovery mechanism, or the attestation algorithm.

Contact: ShaoBao Li <mailto:lee@iqa.org>

Change controller: IQA.ORG Organization

References: This document, and AICENT-009, "Identity Quality Assurance, the iqa URI scheme specification", <https://iqa.org/URI/>.

Registered with CRI scheme number 28.

13. Internationalization Considerations

The canonical form of a URI in either scheme is lowercase US-ASCII, and no international form is defined: a client MUST NOT map a Unicode label to its ASCII form (for example, by case folding or by applying an IDNA-style transformation) in order to accept it, and MUST NOT render such a URI as an IRI. This is deliberate: with no host to resolve there is no need for a label-to-ASCII transformation, and permitting one would introduce a second way to write one address.

14. Acknowledgements

The author thanks those who commented on earlier revisions of this document for their attention to the client-behaviour requirements, which are the part of this specification most likely to be misimplemented.

The author further thanks the independent implementers and reviewers who have exercised the schemes and the response vocabulary of Section 8 in public conformance runs; the runs are cited in Section 12, and the reviewers of this revision will be recorded here as their reports arrive.

15. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC2104]
Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, , <https://www.rfc-editor.org/info/rfc2104>.
[RFC3986]
Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, , <https://www.rfc-editor.org/info/rfc3986>.
[RFC5234]
Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, , <https://www.rfc-editor.org/info/rfc5234>.
[RFC7595]
Thaler, D., Hansen, T., and T. Hardie, "Guidelines and Registration Procedures for URI Schemes", BCP 35, RFC 7595, DOI 10.17487/RFC7595, , <https://www.rfc-editor.org/info/rfc7595>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC9110]
Fielding, R., Nottingham, M., and J. Reschke, "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, , <https://www.rfc-editor.org/info/rfc9110>.
[FIPS180]
National Institute of Standards and Technology (NIST), "Secure Hash Standard (SHS)", DOI 10.6028/NIST.FIPS.180-4, , <https://doi.org/10.6028/NIST.FIPS.180-4>.

16. Informative References

[IQA-SPEC]
Li, S., "Identity Quality Assurance, the iqa URI scheme specification, v1.3.1 (frozen snapshot)", , <https://iqa.org/URI/v1.3.1/>.
[IQA-DEMO]
Li, S., "Live demonstrations of the iqa scheme", , <https://iqa.org/demo/>.
[AAE]
Kroehl, L., "Agent Authorization Envelope (AAE): A Machine-Evaluable Authorization Structure for Autonomous AI Agents", Work in Progress, Internet-Draft, draft-kroehl-agentic-trust-aae-02, , <https://datatracker.ietf.org/doc/draft-kroehl-agentic-trust-aae/>.
[APS]
Pidlisnyi, T., "Agent Passport System (APS): Verifiable Authority, Lifecycle, Enforcement, and Evidence for AI Agents", Work in Progress, Internet-Draft, draft-pidlisnyi-aps-04, , <https://datatracker.ietf.org/doc/draft-pidlisnyi-aps/>.
[RFC8392]
Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, , <https://www.rfc-editor.org/info/rfc8392>.
[RFC9334]
Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote Attestation Procedures (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, , <https://www.rfc-editor.org/info/rfc9334>.
[RFC6749]
Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, , <https://www.rfc-editor.org/info/rfc6749>.
[RFC9846]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 9846, DOI 10.17487/RFC9846, , <https://www.rfc-editor.org/info/rfc9846>.
[RFC9000]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, , <https://www.rfc-editor.org/info/rfc9000>.
[RFC2606]
Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, , <https://www.rfc-editor.org/info/rfc2606>.
[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, , <https://www.rfc-editor.org/info/rfc8126>.
[W3C-AP-CG]
World Wide Web Consortium (W3C), "AI Agent Protocol Community Group", , <https://www.w3.org/community/agentprotocol/>.
[W3C-DID]
World Wide Web Consortium (W3C), "Decentralized Identifiers (DIDs) v1.0", W3C Recommendation did-core-20220719, , <https://www.w3.org/TR/2022/REC-did-core-20220719/>.

Appendix A. Comparison with Alternative Agent-to-Agent Stacks

This appendix is informational. It compares one concrete question-and-answer exchange — "may this subject, identified only by its shard, perform this intent?" — across four agent-to-agent stacks: A2A over HTTPS with OAuth 2.0, A2A with DID/VC identity, A2A with a capability token, and the rttp/iqa pair specified in this document. Each stack is scored across eleven fields that a trust-bearing exchange must address: discovery, identity, intent, authentication, attestation, authorization, delegation, replay, revocation, audit, and routing.

The counts are per single exchange and assume a cold, honest deployment of each stack. "Network round-trips" counts messages that leave the verifying party. "Third parties" counts distinct online services whose response the exchange depends on. "Real cryptographic steps" counts operations whose inputs and keys are local and whose result is checkable offline afterwards.

Table 2: Totals per stack (one exchange)
Stack Network round-trips Third parties Real crypto steps Offline-verifiable result
A2A + HTTPS/OAuth 5 8 0 no
A2A + DID/VC 6 8 0 no
A2A + capability token 2 3 0 no
A2A + rttp/iqa (this document) 0 0 7 yes
Table 3: Per-field cost (network round-trips · third parties)
Field HTTPS/OAuth DID/VC Capability rttp/iqa
discovery 1 · 3 1 · 2 1 · 2 0 · 0
identity 0 · 0 1 · 1 0 · 0 0 · 0
intent 0 · 0 0 · 0 0 · 0 0 · 0
authentication 1 · 2 1 · 1 0 · 0 0 · 0
attestation 0 · 0 0 · 1 0 · 0 0 · 0
authorization 0 · 0 0 · 0 0 · 0 0 · 0
delegation 1 · 1 0 · 0 0 · 0 0 · 0
replay 0 · 0 1 · 1 0 · 0 0 · 0
revocation 1 · 1 1 · 1 0 · 0 0 · 0
audit 0 · 0 0 · 0 0 · 0 0 · 0
routing 1 · 1 1 · 1 1 · 1 0 · 0
totals 5 · 8 6 · 8 2 · 3 0 · 0

Three caveats keep the comparison honest. First, the capability-token stack is also offline at verification time; its weakness is different — a capability confers authority but states nothing about the bearer's standing, and its only revocation is expiry. Second, DID/VC provides strong identity and portable audit artifacts; its freshness and revocation paths re-introduce network calls to the issuer or a status list. Third, rttp/iqa intentionally omits discovery and delegation in this revision: routing is derived rather than resolved, and delivery of a frame to its shard remains an operator concern. The counts describe the verification of one answer, not the provisioning of the system that produced it.

The structural claim the tables support is narrow: in the rttp/iqa stack the material needed to decide — and, after the fact, to re-verify — a standing verdict is contained entirely in the two frames, so no online party is required at either moment. Whether that property is worth the corresponding loss of discovery infrastructure is a deployment decision, not a claim of this document.

A.1. Delegation and Attenuation

The single-exchange comparison above deliberately excludes delegation. This section records a second, harder experiment: Agent A grants Agent B authority to approve invoices up to EUR 10,000; Agent B attenuates that grant to EUR 2,000 and further delegates execution to a Payment Agent. Each stack is observed on nine delegation-specific fields: the grant, the attenuation, the further delegation, chain verification, subject binding, standing, replay, revocation, and the audit artifact. The scorecard below records all nine fields, together with one cross-cutting observation — where each stack's delegation root lives. A live demonstration of this delegation experiment, covering all nine fields, is public at the reference specification's site [IQA-DEMO], among the further live demonstrations hosted there. The observations are informational and indicate typical deployments, not normative requirements of any stack.

Table 4: Delegation scorecard (EUR 10,000 granted, EUR 2,000 delegated onward)
Field HTTPS/OAuth DID/VC Capability rttp/iqa
the grant a coarse scope string; amounts are not representable A issues a Verifiable Credential to B; the issuer must be reachable a root capability minted by the issuer — fully offline an intent claim on a derived subject; no amount field in the frame
the attenuation only as custom claims at the authorization server chained credential; B becomes issuer of record yes — first-class caveat no — the frame carries no amount field
the further delegation token exchange, provider-specific yes, chained credentials yes — third-party caveats not specified in this revision
chain verification no — introspection required signatures yes; freshness needs the status list yes yes — envelopes verify offline
subject binding binds to a server identity, not to a derived subject DID subject — strong binding bearer possession, not an identity assertion the derived shard inside each frame — self-certifying on arrival
standing no only via a cached issuer credential no yes — organ-relative standing in the frame
replay token lifetime; in-window replay is the application's job re-query the issuer or fetch the status list expiry plus nonce; in-window replay possible lease expiry and a nonce unique per verdict
revocation at the IdP (network); the presented token only, not the chain status-list fetch (network) expiry only — online revocation would undermine the offline model caught at the next verified read; exposure bounded by the lease
the audit artifact no yes yes yes — whole-frame MAC
delegation root the identity provider issuer B the issuer the organ (application-layer composition)

Three observations. First, the capability stack is the only one in which attenuation is a native operation; its corresponding weakness is that the credential carries authority without context — no standing, no identity assertion, and revocation only by expiry. Second, in the rttp and iqa stack the delegation gap is explicit and stated: the AE-128 layout (Section 7.2) allocates no amount field, and delegation is not specified in this revision, so attenuation cannot enter the frame and must be performed at the application layer. Two compositions have been demonstrated in that role: re-attestation, in which the organ issues a fresh envelope for the delegatee's own subject; and a capability wrapper whose root caveat embeds the (subject, intent, organ, standing, time, proof) audit tuple, so that the standing context travels with the attenuated grant. Both are application-layer work; neither is specified here. Third, the re-attestation chain has an honest shape limitation worth stating plainly: two envelopes anchored at the same organ are two independent attestations, not a linked proof that B's attenuation authorized the Payment Agent's envelope.

The practical conclusion is narrow and symmetrical: for attenuation, the capability construction is the natural tool; for carrying verifiable standing with the grant, the envelopes specified in this document are. The two are composable, and the composition does not require changes to either frame format.

Author's Address

ShaoBao Li
RTTP & IQA Organization