Internet-Draft	iqa URI Scheme	September 2026
Li	Expires 24 March 2027	[Page]

Workgroup:: Independent Submission
Internet-Draft:: draft-li-iqa-subject-attestation-00
Published:: 20 September 2026
Intended Status:: Informational
Expires:: 24 March 2027
Author:: S. Li

IQA.ORG Organization

Subject Attestation in the iqa URI Scheme

Abstract

This document specifies the "iqa" URI scheme, a subject-attestation scheme in which an "iqa" URI names the attestation standing of an identified subject, as reported by one of three named authority organs; the URI carries no proof and no credential, and no lookup service or name-resolution system is consulted when the URI is used. The document also states the requirements a client MUST satisfy when it handles such a URI, in order to avoid two failure modes that short, user-embeddable strings otherwise invite: using the authority as a navigation target (open redirect), and using a registered protocol handler as a general-purpose launcher. A third failure mode specific to this scheme is addressed as well: a parse that looks like a certification.¶

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

Copyright Notice

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

▲

1. Introduction

Most URI schemes name a location: the authority identifies a host to be contacted. This document specifies a subject-attestation scheme that names something else: the attestation standing of an identified subject, as reported by a named authority organ. What a client does with that answer 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.¶

Three properties follow from that choice and are normative in this document:¶

the subject, the organ and the root are names, never hosts: nothing in the URI is resolved through DNS or any other lookup (Section 3.1, Section 5);¶
the URI is a claim, not evidence. It carries no seal, no proof and no credential, and establishes nothing about the subject by itself (Section 3.2, Section 4);¶
dereferencing a URI that omits the action is a read and MUST NOT change any subject's standing (Section 3.3).¶

Naming note. IQA here denotes Identity Quality Assurance. It is not affiliated with the Institute of Quality Assurance (the historical body in the United Kingdom that became the Chartered Quality Institute in 2007), nor is it the computer-vision field of Image Quality Assessment.¶

The scheme is subject to registration with IANA under [RFC7595]. Its registration status is recorded in Section 8; as of 20 September 2026 the request is submitted and pending, and the name is not registered.¶

The rttp scheme, which addresses intent rather than attestation standing, is specified separately [RTTP]; an Internet-Draft for rttp is in progress (<https://datatracker.ietf.org/doc/draft-li-rttp-intent-addressing/>). The two schemes are registered independently of each other.¶

This document does not define the attestation algorithm, the seal format, the transport, or the vocabulary of standing values that an organ may return. It defines a URI scheme and the minimum client behaviour that makes the scheme safe to embed.¶

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 <subject>.<organ>.<root> defined in Section 3.1. It is a name, not a host name, and is never resolved.¶
subject: The entity whose standing the URI names, identified inside the authority. The subject is a claim about which identity is of interest; it is not a proof of that identity.¶
organ: The named component that answers for the subject. This document defines a closed set of three organ names (Section 3.1).¶
root: The root label of the scheme. It is a name and is not resolved.¶
action: The optional final path segment naming an operation requested of the organ.¶
standing: The attestation answer an organ returns for a subject. This document does not enumerate the values it may take; the vocabulary is defined by the reference specification [IQA-SPEC].¶
AID: A subject identifier defined outside this document. This document does not define AID, and makes no assumption about its length or encoding beyond what Section 3.2 and Section 5 require. Nothing in this specification depends on an AID registry or authority.¶

3. The iqa URI Scheme

3.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: either 8, 32 or 64 lowercase hexadecimal digits (a derived routing hash), or a readable label matching 1*( %x61-7A / DIGIT / "-" ). Both forms are opaque to a client. The hash form is a routing hint and carries no verification weight (Section 3.2).¶
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, matching 1*( %x61-7A / DIGIT / "-" ). It is iqa for this specification. As with the other segments, 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://" authority [ "/" action ]
authority    = subject "." organ "." root
subject      = hash-subject / name-subject
hash-subject = 8( lowhex ) / 32( lowhex ) / 64( lowhex )
name-subject = 1*( %x61-7A / DIGIT / "-" )
organ        = "forge" / "tss" / "gateway"
root         = 1*( %x61-7A / DIGIT / "-" )
action       = "verify" / "audit" / "attest" / "revoke"
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 fragment component is not part of this scheme and MUST NOT be used to address an action.¶

3.2. Reserved Characters and Exclusions

The canonical form is lowercase US-ASCII. Uppercase is invalid input, not a formatting difference: a parser MUST NOT normalise an uppercase string into a valid URI, because two distinct strings would then map onto one subject.¶
., / and :// are the delimiters defined by this scheme.¶
This scheme defines no userinfo, no port, no query, and no fragment. A URI containing any of them is not a valid iqa URI. In particular, credentials cannot appear in an iqa URI, and there is no field in which to exfiltrate data.¶
Percent-encoding follows Section 2.1 of [RFC3986]. Because no component requires characters outside the unreserved set, a canonical URI contains no percent-encoded octets; a parser MAY reject such input rather than normalising it.¶
There is no "iqas" scheme and no protocol fallback. A client that does not implement this scheme fails closed (Section 4).¶
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 5).¶

3.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 3.1 of [RFC3986]: 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 3.4; a client MUST NOT infer safety for an unrecognised verb (Section 5).¶

3.4. Action Safety Classes

The four defined actions have the following classes:¶

Table 1: Action safety classes
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

audit is not classified safe because the measurement it requests can itself change the outcome it measures: a failing measurement moves the subject onto a degraded path. A read can therefore change state, and that is precisely why audit, attest and revoke MUST be requested explicitly and MUST NOT be reachable by dereferencing a URI that omits the action.¶

4. Client Requirements

A client that handles an iqa URI (including a resolver page, a protocol handler, and a library that renders one) MUST satisfy the requirements below. They follow from Section 5: an iqa URI may be supplied by an untrusted party, and its subject is a claim rather than a proof.¶

4.2. Scheme Prefix Check

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

4.4. 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].¶

4.5. Rationale

iqa://<subject>.<organ>.<root>/<action> is a short, human-readable string that any page can embed in a link. Without the rules above, the scheme would hand third parties two primitive attacks: using this project's domain as a redirector, and using a registered handler as a launcher for URIs the user never intended to open. The fourth rule guards a third failure mode specific to this scheme, a parse that looks like a certification. All three are properties of the embedding context, not of the URI syntax, which is why they are stated as client requirements rather than as grammar rules.¶

5. Security Considerations

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, and a client MUST NOT present a parsed URI as if it were.¶
Seal forgery. Standing is carried by a keyed message authentication code computed over the subject's identity material and its deployment parameters, not by the URI. Key material is never present in an iqa URI, and there is no component in which to place it.¶
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.¶
Credential leakage. Because userinfo is not defined (Section 3.2), credentials cannot appear in an iqa URI. Deployments MUST NOT place secrets in any component: the URI is expected to be logged, quoted, and rendered.¶
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 with the same care 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.¶
No DNS dependency. This scheme performs no DNS resolution: the subject, organ and root do not map to IP addresses. Consequently there is no resolver to poison and no query metadata to observe on a resolution path. Resolution failure means no answer; there is no fallback path.¶
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; clients fail closed.¶
Unknown actions carry unknown safety. The safe default of Section 3.3 applies to the omitted-action form only. An implementation MUST NOT infer safety for an unrecognised verb from that statement; it MUST treat the verb as having unknown safety and either require explicit authorisation under the local security policy or reject it.¶
Detection of observers. A measurement requested by the audit action compares observed execution timing against an expected path; execution that is 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. A successor construction is planned; see the reference specification [IQA-SPEC].¶
The scheme itself provides no confidentiality and no transport security. A URI is not a signature, and signing is not encryption.¶

6. Privacy Considerations

An iqa URI identifies the subject whose standing is at issue. It is pseudonymous at best and not anonymous, and it is expected to be logged, quoted, and rendered by whatever carries it.¶
Deployments that assign readable labels rather than derived hashes are choosing names that are meaningful to humans; that is a privacy trade-off made at assignment time, not a property of the scheme.¶
No component is defined for a query string, so the scheme provides no convenient channel for a page to smuggle unrelated data into a request.¶
Using an iqa URI does not by itself cause network traffic to a third party. Any traffic that follows is caused by the client's own, separately defined handling of the claim.¶
A client that renders an iqa URI SHOULD avoid prefetching, handing the string to third-party services, or otherwise distributing it beyond what the user's action requires.¶

7. Internationalization Considerations

The canonical form of an iqa URI is lowercase US-ASCII, and no international form is defined. Characters outside the permitted set are invalid input rather than input to be converted: 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 an iqa URI as an IRI.¶

This is deliberate. The scheme has no host to resolve, so there is no need for a label-to-ASCII transformation; permitting one would introduce a second way to write one subject.¶

8. IANA Considerations

IANA is requested to register the URI scheme iqa in the "Uniform Resource Identifier (URI) Schemes" registry, following the template of Section 7.4 of [RFC7595] and the guidance of [RFC8126].¶

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 the reference specification published at https://iqa.org/RFC-009/.¶
Security considerations:: See Section 5 of this document.¶

Registration status as of 20 September 2026: a registration request was submitted to IANA on 17 September 2026 (ticket #1459963); the request is pending, and the scheme is not registered. It is inaccurate to describe the scheme as "registered", "assigned", or "standardised" until IANA publishes the registration.¶

If this document is approved for publication as an RFC, IANA is requested to update the reference in the registry entry to point at that RFC.¶

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

10. Normative References

[RFC2119]: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/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, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC5234]: Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC7595]: Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines and Registration Procedures for URI Schemes", BCP 35, RFC 7595, DOI 10.17487/RFC7595, June 2015, <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, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

11. Informative References

[IQA-SPEC]: Li, S., "RFC-009: Identity Quality Assurance, the iqa URI scheme specification", September 2026, <https://iqa.org/RFC-009/>. The reference specification for the iqa URI scheme, including the attestation algorithm, the standing vocabulary and the conformance material.
[RFC8126]: Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RTTP]: Li, S., "RFC-002: Resonant Time Transfer Protocol (RTTP), the rttp URI scheme specification", September 2026, <https://rttp.com/RFC-002/>. The reference specification for the sibling rttp URI scheme, which addresses intent rather than attestation standing.

Examples

Valid forms

iqa://3f9a1b2c.gateway.iqa (routing hash, default operation)
iqa://3f9a1b2c.tss.iqa/audit (explicit fidelity audit)
iqa://master-authority.gateway.iqa/verify (readable label form)

Invalid forms and the reason

Table 2: Invalid input and why it is rejected
Input	Reason
IQA://3f9a1b2c.gateway.iqa	Uppercase scheme or components are invalid input, not normalisable.
iqa://subject@iqa.org	No userinfo component is defined, and the authority does not have three segments.
iqa://iqa.org/RFC-009/	No organ segment, and the action is not one of the four defined names.
iqa://3f9a1b2c.forgery.iqa	The organ name is outside the closed set.
iqa://3f9a1b2c.tss.iqa/ATTEST	Uppercase action; action names are lowercase.
iqa://3f9a1b2c.tss.iqa/	Trailing slash with an empty action is not a valid action.
iqa://3f9a1b2c.tss.iqa?v=1	No query component is defined.
iqa://3f9a1b2c.tss.iqa#top	No fragment component is defined.
iqa://3f9a1b2c.tss.iqa:80/audit	No port component is defined.
iqa://3f9a1b2c.iqa	The authority does not have exactly three segments.
iqa://3f9a1b2c.tss.iqa/audit/extra	The action is a single path segment.

Author's Address

ShaoBao Li

IQA.ORG Organization

Email: lee@iqa.org