Independent Submission S. Li Internet-Draft IQA.ORG Organization Intended status: Informational 20 September 2026 Expires: 24 March 2027 Subject Attestation in the iqa URI Scheme draft-li-iqa-subject-attestation-00 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 Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Li Expires 24 March 2027 [Page 1] Internet-Draft iqa URI Scheme September 2026 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 3. The iqa URI Scheme . . . . . . . . . . . . . . . . . . . . . 4 3.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Reserved Characters and Exclusions . . . . . . . . . . . 5 3.3. Default Operation . . . . . . . . . . . . . . . . . . . . 6 3.4. Action Safety Classes . . . . . . . . . . . . . . . . . . 6 4. Client Requirements . . . . . . . . . . . . . . . . . . . . . 7 4.1. No Navigation to the URI . . . . . . . . . . . . . . . . 7 4.2. Scheme Prefix Check . . . . . . . . . . . . . . . . . . . 8 4.3. Consent, Never Silence . . . . . . . . . . . . . . . . . 8 4.4. Parsing Is Not Attestation . . . . . . . . . . . . . . . 8 4.5. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 7. Internationalization Considerations . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 10. Normative References . . . . . . . . . . . . . . . . . . . . 12 11. Informative References . . . . . . . . . . . . . . . . . . . 12 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Valid forms . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Invalid forms and the reason . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 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: Li Expires 24 March 2027 [Page 2] Internet-Draft iqa URI Scheme September 2026 * 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 (). 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 .. Li Expires 24 March 2027 [Page 3] Internet-Draft iqa URI Scheme September 2026 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://..[/] 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. Li Expires 24 March 2027 [Page 4] Internet-Draft iqa URI Scheme September 2026 * 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. Li Expires 24 March 2027 [Page 5] Internet-Draft iqa URI Scheme September 2026 * 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: Li Expires 24 March 2027 [Page 6] Internet-Draft iqa URI Scheme September 2026 +===========+==========================+=====================+ | Action | Semantics | Class | +===========+==========================+=====================+ | (omitted) | Read the current | *SAFE*, read-only | | | standing. | | +-----------+--------------------------+---------------------+ | verify | Compare a presented seal | *SAFE*, read-only | | | against the subject. No | comparison | | | state is written. | | +-----------+--------------------------+---------------------+ | audit | Request a fidelity | *NOT SAFE*, a | | | measurement of the | failed measurement | | | subject's execution. | may change standing | +-----------+--------------------------+---------------------+ | attest | Request that a seal be | *NOT SAFE*, state | | | issued for the subject. | transition | +-----------+--------------------------+---------------------+ | revoke | Withdraw the subject's | *NOT SAFE*, state | | | standing. | transition | +-----------+--------------------------+---------------------+ Table 1: Action safety classes 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.1. 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. Li Expires 24 March 2027 [Page 7] Internet-Draft iqa URI Scheme September 2026 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.3. 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. 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://../ 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. Li Expires 24 March 2027 [Page 8] Internet-Draft iqa URI Scheme September 2026 * *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. Li Expires 24 March 2027 [Page 9] Internet-Draft iqa URI Scheme September 2026 * *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. Li Expires 24 March 2027 [Page 10] Internet-Draft iqa URI Scheme September 2026 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 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. Li Expires 24 March 2027 [Page 11] Internet-Draft iqa URI Scheme September 2026 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, . [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, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 11. Informative References [IQA-SPEC] Li, S., "RFC-009: Identity Quality Assurance, the iqa URI scheme specification", September 2026, . 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, . Li Expires 24 March 2027 [Page 12] Internet-Draft iqa URI Scheme September 2026 [RTTP] Li, S., "RFC-002: Resonant Time Transfer Protocol (RTTP), the rttp URI scheme specification", September 2026, . 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 +===============================+===============================+ | 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/ | No port component is defined. | | audit | | Li Expires 24 March 2027 [Page 13] Internet-Draft iqa URI Scheme September 2026 +-------------------------------+-------------------------------+ | iqa://3f9a1b2c.iqa | The authority does not have | | | exactly three segments. | +-------------------------------+-------------------------------+ | iqa://3f9a1b2c.tss.iqa/audit/ | The action is a single path | | extra | segment. | +-------------------------------+-------------------------------+ Table 2: Invalid input and why it is rejected Author's Address ShaoBao Li IQA.ORG Organization Email: lee@iqa.org Li Expires 24 March 2027 [Page 14]