Internet-Draft rttp and iqa URI Schemes September 2026
Li Expires 28 March 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 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" is in expert review. The registration status of both schemes is recorded in Section 9.

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

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 are defined by the reference specification [IQA-SPEC], not here. It carries the attestation algorithm, the standing vocabulary and the conformance material.
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 6 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

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

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 6:

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

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

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

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

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

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

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

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.

For "iqa", citing a URI also discloses which subject is of interest; the disclosure considerations of Section 6.2 apply.

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

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

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

9.2. The "iqa" URI Scheme

Scheme name: iqa

Status: Provisional

Applications/protocols that use this scheme name:

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

Submitted for registration; the scheme name is approved and the CRI number is in expert review.

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

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

12. Informative References

[IQA-SPEC]
Li, S., "Identity Quality Assurance, the iqa URI scheme specification", , <https://iqa.org/URI/>.
[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>.

Author's Address

ShaoBao Li
RTTP & IQA Organization