IQA.ORG Organization

lee@iqa.org

Applications and Real-Time Independent Submission 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.

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 (, );
• the URI is a claim, not evidence. It carries no seal, no proof and no credential, and establishes nothing about the subject by itself (, );
• dereferencing a URI that omits the action is a read and MUST NOT change any subject's standing ().

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 . Its registration status is recorded in ; 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 ; an Internet-Draft for rttp is in progress (<>). 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.

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 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 <subject>.<organ>.<root> defined in . 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 ().

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 .

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 and require. Nothing in this specification depends on an AID registry or authority.

The iqa URI Scheme

Syntax The general form of an iqa URI is: ..[/] ]]> 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 ().
• 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: Examples (the examples use the root label of this specification and placeholder subjects): The fragment component is not part of this scheme and MUST NOT be used to address an action.

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

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 : 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 ; a client MUST NOT infer safety for an unrecognised verb ().

Action Safety Classes The four defined actions have the following classes: 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.

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 : an iqa URI may be supplied by an untrusted party, and its subject is a claim rather than a proof.

No Navigation to the URI The subject, organ, root and action components MUST NOT be used as a navigation target. A client that renders a link, redirect, or fetch derived from any part of an iqa 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.

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.

Consent, Never Silence The ability to handle 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.

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 .

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.

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 (), 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 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 .
• The scheme itself provides no confidentiality and no transport security. A URI is not a signature, and signing is not encryption.

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.

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.

IANA Considerations IANA is requested to register the URI scheme iqa in the "Uniform Resource Identifier (URI) Schemes" registry, following the template of and the guidance of .

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

Change controller:

IQA.ORG Organization

References:

This document, and the reference specification published at .

Security considerations:

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

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.

Normative References Informative References The reference specification for the iqa URI scheme, including the attestation algorithm, the standing vocabulary and the conformance material. The reference specification for the sibling rttp URI scheme, which addresses intent rather than attestation standing.

Examples

Valid forms

Invalid forms and the reason 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.