RTTP & IQA Organization

lee@iqa.org

Applications and Real-Time Independent Submission rttp iqa URI scheme attestation intent addressing trust lease 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. 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.

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:

• the address is derived by computation from the authority (Sections 4.4 and 5.1);
• there is no lookup: no DNS, no registry query, no fetch (Sections 4.5 and 5.5);
• the URI is a claim, not a proof (Sections 5.2 and 9);
• both schemes fail closed: non-conforming input is rejected, never repaired (Sections 4 and 5).

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.

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 when, and only when, they appear in all capitals, as shown here. This document uses the ABNF notation of and the URI syntax of . 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 . 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.

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.

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

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 ; operators use labels they control: rttp://f3b2a1c4.pillar.example/vessel rttp://organ.pillar.example/verify rttp://f3b2a1c4.pillar.example

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

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

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

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

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.

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.

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.

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)

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

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

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.

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

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.

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 .

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.

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.

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

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.

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.

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

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.

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.

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 : 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 , 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 and a key can verify with zero dependencies.

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

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

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.

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.

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.

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

• No lookup. Neither scheme resolves through DNS, and neither performs a lookup when a URI is used: there is no resolver to poison, no registration to hijack, and no query metadata to observe on a resolution path.
• No secrets in the URI. Neither scheme defines userinfo, so credentials cannot be carried in one. Operators and deployments MUST NOT place secrets in any component: a URI is expected to be logged, quoted, and rendered.
• Unknown actions carry unknown safety. The safe default operations of Sections 4.3 and 5.3 apply to the omitted-action forms only. An implementation MUST NOT infer safety for an unrecognised action verb; it MUST treat the verb as having unknown safety and either require explicit authorisation under the local security policy or reject it.
• No confidentiality, authentication, or transport security. Neither scheme protects a URI in transit, and neither turns a URI into a proof: signing is not encryption, and a URI is not a signature.
• Parsing establishes nothing. Neither the syntax nor any component of a URI of either scheme is evidence about its subject, and a client MUST NOT present a parsed or rendered URI as if it were evidence (Sections 4.5 and 5.5).
• Fail closed, everywhere. Both wire formats of Section 7 reject unknown versions, unknown fields, and wrong lengths rather than skipping them; the response semantics of Section 8 report an unreachable source as a refusal rather than as assent; and the lease of Section 6 expires by default. At no decision point does silence, absence, or an unrecognised input resolve to "yes".

The scheme-specific considerations follow.

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

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

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.

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 and the guidance of . 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.

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.

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.

This section positions the two schemes against the specifications they are most often compared with. None of the relationships below is a normative dependency. Decentralized Identifiers (DIDs) anchor a subject's identity in a resolvable, method-specific identifier, paired with Verifiable Credentials for portable claims. The schemes of this document answer different questions: an rttp address is not assigned and not resolvable — it is derived from the authority string and consulted through no method, no registry, and no network call — and an iqa answer is bound to a named organ rather than to a credential issuer. The two compose rather than compete: a deployment MAY anchor operator identity in DIDs while rttp addresses intents and iqa answers standing. Transport and authorization infrastructure. The schemes define addressing and verification semantics, not transport: the frames of Section 7 may be carried by HTTP , TLS , QUIC , gRPC, or any channel that preserves frame integrity; no transport is required and none is excluded. Deployment authorization machinery — identity providers, OAuth 2.0 scopes and grants , mTLS client authentication, or capability tokens — belongs to the calling layer (Section 6.2); the frames carry intent claims and verification answers, and no bearer credential. CBOR Web Token (CWT) and Remote Attestation procedures (RATS) solve portable attestation and evidence with general parser stacks and rich claim vocabularies. The attestation envelope of Section 7.2 trades expressiveness for fixed-offset determinism: a verifier with nothing but SHA-256 and a key can verify with zero dependencies. Where rich claims are needed, those formats remain the right tools. The W3C AI Agent Protocol Community Group has discussed the distinction this document's claims follow: evidence freshness, authority validity, and action-time authorization as three separately scoreable axes. This document claims the first two (Sections 6 and 8) and deliberately does not claim the third: authorization decisions belong to the calling layer, and the schemes' job is to make the verification answers trustworthy and cheap. Appendix A complements this section with a per-exchange cost comparison against alternative stacks. Agent Authorization Envelope (AAE) specifies a machine-evaluable authorization container for autonomous agents: what the agent is mandated to do, under what constraints, and for how long. AAE answers what an agent may do; the schemes of this document answer where intent is addressed and whether the claimant is verified. The two compose naturally — an authorization envelope can name actions on subjects addressed by rttp URIs and cite iqa attestations as evidence — and neither depends on the other. Agent Passport System (APS) specifies verifiable authority, lifecycle, enforcement and evidence for AI agents, separating agent identity, represented principal, delegated authority, policy approval and observed results. The attestation response vocabulary of Section 8 is stated in the form in which it was exercised by the lease-revocation-axes corpus of the Agent-Authority-Conformance laboratory of the Linux Foundation Decentralized Trust, whose initial corpus builds on this family of specifications; independent runs against that corpus, including the author's own, are public. The laboratory records runs and does not certify implementations; the citation reflects that posture.

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.

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.

Normative References National Institute of Standards and Technology (NIST) Informative References World Wide Web Consortium (W3C) World Wide Web Consortium (W3C)

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

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.

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 , among the further live demonstrations hosted there. The observations are informational and indicate typical deployments, not normative requirements of any stack. 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.