Network Working Group C. Rehfeld Internet-Draft 15 June 2026 Intended status: Standards Track Expires: 17 December 2026 APIX Quality Attestation Extension: Verifiable Product, Process, and Organisation Quality Claims for Discovered Services draft-rehfeld-apix-quality-00 Abstract The APIX Core ([APIX-CORE]) defines a three-dimensional trust model — Organisation Trust Level (O), Service Verification Level (S), and Liveness — that lets a consuming agent decide whether a discovered service is operated by a verified party, is technically reachable and consistent, and is currently alive. These dimensions do not describe the _quality_ of what a service produces. They cannot answer whether a manufacturing process is GMP-certified, whether a product carries an independent quality grade, or whether an organisation holds a domain quality certification, nor who attested any of these and with what strength. This document defines the APIX Quality Attestation Extension: a cross-cutting extension, docking via the structured extensions container of the APM ([APIX-CORE] Section 7.1), that records third- party and self-declared quality claims about a discovered service's Organisation, Process, or Product, each carried with an explicit assurance level, attestation provenance, validity state, and liability regime. The extension reuses and extends the Core Verification Basis Registry for provenance and mirrors the Core capability-taxonomy governance for its criterion vocabulary. It is the mechanism by which measurable quality enters the agentic purchase decision without re-introducing the central-arbiter and race-to-the- bottom failure modes the Core is designed to prevent. 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/. Rehfeld Expires 17 December 2026 [Page 1] Internet-Draft APIX Quality Attestation June 2026 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 17 December 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Relationship to APIX Core . . . . . . . . . . . . . . . . 3 1.2. Boundary with Core Evidence Channels (Normative) . . . . 4 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. The Quality Attestation Model . . . . . . . . . . . . . . . . 5 2.1. The Quality Assertion . . . . . . . . . . . . . . . . . . 5 2.2. Axis 1 — Quality Object . . . . . . . . . . . . . . . . . 6 2.3. Axis 2 — Assurance Level . . . . . . . . . . . . . . . . 7 2.4. Axis 3 — Claim Types and Temporal Binding . . . . . . . . 8 2.5. Attestation Provenance and the Verification Basis Registry . . . . . . . . . . . . . . . . . . . . . . . . 8 2.6. Validity and Revocation . . . . . . . . . . . . . . . . . 9 3. Relationship to Core Trust Fields (Normative) . . . . . . . . 9 4. The Quality Criterion Registry . . . . . . . . . . . . . . . 10 5. Discovery and Filtering . . . . . . . . . . . . . . . . . . . 10 6. Ranking, Weighting, and the Private Overlay . . . . . . . . . 11 6.1. Two Data Natures . . . . . . . . . . . . . . . . . . . . 11 6.2. Hard Invariant . . . . . . . . . . . . . . . . . . . . . 11 6.3. Relationship Depth as a Private Overlay . . . . . . . . . 11 6.4. Root Trust Policy and Recognition . . . . . . . . . . . . 12 6.4.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 12 6.4.2. Roots and Root Classes . . . . . . . . . . . . . . . 12 6.4.3. Recognition Expressed as Quality Assertions . . . . . 12 6.4.4. The Root Trust Policy . . . . . . . . . . . . . . . . 13 6.4.5. Assurance Resolution Algorithm (Normative) . . . . . 14 Rehfeld Expires 17 December 2026 [Page 2] Internet-Draft APIX Quality Attestation June 2026 6.4.6. Recognition Depth and Anti-Laundering . . . . . . . . 15 6.4.7. Bootstrapping and Default Policies . . . . . . . . . 15 6.4.8. Worked Example — GMP Recognition for CDMO Discovery . . . . . . . . . . . . . . . . . . . . . . 15 6.4.9. Security Considerations (Recognition-Specific) . . . 17 7. Structural Failure Modes and Mitigations . . . . . . . . . . 17 8. APM Integration . . . . . . . . . . . . . . . . . . . . . . . 18 9. Liability . . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 11. IANA / Registry Considerations . . . . . . . . . . . . . . . 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 12.1. Normative References . . . . . . . . . . . . . . . . . . 20 12.2. Informative References . . . . . . . . . . . . . . . . . 21 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction ## Motivation: The Quality Gap Federated, zero-prior-knowledge discovery lowers search and trust cost. Absent a verifiable quality layer, this has a structural side effect: the only machine-comparable parameter that remains is price, and the discovered market tends toward a race-to-the-bottom that structurally favours large aggregators able to source from a fragmented, commoditised supplier base. Two complementary mechanisms counter this: 1. A _public attestation layer_ prevents levelling on *measurable quality*. Attested, ideally independently verifiable properties let a small, high-quality provider justify a price premium rather than merely assert one. 2. A _private relationship overlay_ (Section 6.3) prevents *relational trust capital* ("know your supplier") from disappearing behind interchangeable criteria. Together they reconstruct, in machine-actionable form, what a competent procurement officer does: combine objective quality signals with hard-won relationship knowledge. 1.1. Relationship to APIX Core This extension does not modify the Core. It docks at the reserved docking points the Core defines for exactly this purpose: Rehfeld Expires 17 December 2026 [Page 3] Internet-Draft APIX Quality Attestation June 2026 * It is carried in the structured extensions container of the APM ([APIX-CORE] Section 7.1), under a registered extension identifier (Section 8). * It is a distinct axis from the Core trust dimensions ([APIX-CORE] Section 8): O/S/Liveness describe operator verification, technical endpoint verification, and operational availability; this extension describes attested quality of organisation, process, or product. * It reuses the Core Verification Basis Registry for attestation provenance, rather than defining a parallel root-type enumeration (Section 2.5). * It mirrors the Core capability-taxonomy governance ([APIX-CORE] Section 5.3) for its Quality Criterion Registry (Section 4). A consuming agent that does not implement this extension ignores its data; an index that does not understand the extension key MUST nonetheless preserve it verbatim per [APIX-CORE] Section 7.1. 1.2. Boundary with Core Evidence Channels (Normative) The Core already absorbs certain conformity attestations as _evidence channels for an O-level_. In particular, a Cyber Resilience Act conformity assessment is recorded as the cra_conformity channel substantiating O-5 ([APIX-CORE] Section 8.1). This extension MUST NOT duplicate, override, or re-express any attestation that the Core already records as an O-level or S-level evidence channel. This extension addresses the broader product- and process-quality space that the Core trust model does not represent — for example pharmaceutical GMP process certification, independent graded product testing, and domain-specific quality marks. Where an attestation could plausibly be expressed both ways, the Core evidence channel takes precedence and this extension MUST reference it rather than restate it. 1.3. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 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. _Quality Assertion_ — the atomic unit of this extension: an attested statement about a quality criterion of an Organisation, Process, or Product. Rehfeld Expires 17 December 2026 [Page 4] Internet-Draft APIX Quality Attestation June 2026 _Attestation Body_ — an entity that issues Quality Assertions about other entities. An Attestation Body is itself a registered Organisation in the APIX and carries its own Quality Assertions describing its accreditation. _Quality Criterion_ — a governed, registered definition of a measurable or assessable property, including (where applicable) a measurement method and scope. 2. The Quality Attestation Model 2.1. The Quality Assertion The Quality Assertion is the single primitive of this extension. Provider quality, attestation-body legitimacy, and private relationship depth are all expressed through it; they differ only in facet values. Consequently the accreditation chain is expressible in the same primitive: it is simply a set of Quality Assertions whose subject is an Attestation Body. A Quality Assertion has the following facets: Rehfeld Expires 17 December 2026 [Page 5] Internet-Draft APIX Quality Attestation June 2026 +====================+==========================================+ | Facet | Description | +====================+==========================================+ | subject | Identifier (e.g., DID) of the attested | | | entity or service | +--------------------+------------------------------------------+ | object_type | ORG | PROC | PROD (Section 2.2) | +--------------------+------------------------------------------+ | criterion | Reference to a Quality Criterion, incl. | | | measurement method and scope (Section 4) | +--------------------+------------------------------------------+ | claim | Value typed per Section 2.4: boolean, | | | ordinal, or quantitative | +--------------------+------------------------------------------+ | assurance_level | A0..A3 (Section 2.3) | +--------------------+------------------------------------------+ | attester | Reference to a registered Attestation | | | Body, or self | +--------------------+------------------------------------------+ | verification_basis | Reference into the Core Verification | | | Basis Registry (Section 2.5) | +--------------------+------------------------------------------+ | evidence | Link/hash to underlying evidence (e.g., | | | a [W3C-VC] credential) | +--------------------+------------------------------------------+ | subject_revision | Version/state of the assessed artefact | | | the claim refers to (Section 2.4) | +--------------------+------------------------------------------+ | validity | issued, valid_from, valid_until, status, | | | last_verified (Section 2.6) | +--------------------+------------------------------------------+ | visibility | public (index-recorded) | private | | | (requester-held overlay) (Section 6.3) | +--------------------+------------------------------------------+ | liability_regime | Liable party, governing framework, | | | coverage (Section 9) | +--------------------+------------------------------------------+ Table 1 2.2. Axis 1 — Quality Object Three orthogonal object types. A subject MAY carry assertions about each independently. The separation is not academic: a trustworthy organisation may ship mediocre products; a doubtful provider may ship an excellent product no one stands behind. Rehfeld Expires 17 December 2026 [Page 6] Internet-Draft APIX Quality Attestation June 2026 +========+===========================+========================+ | Object | What is attested | Real-world examples | +========+===========================+========================+ | ORG | The legal/operational | ISO 9001, domain | | | entity as a whole | quality marks | +--------+---------------------------+------------------------+ | PROC | A defined operated | GMP (pharma), ISO | | | process | 13485, ISO 14001 | +--------+---------------------------+------------------------+ | PROD | A specific service/output | independent graded | | | carries property X | product test, fitness- | | | | for-purpose report | +--------+---------------------------+------------------------+ Table 2 Note: organisational _trust_ (identity, compliance posture) remains the Core O-level. ORG here means organisational _quality_ attested by a third party, which is distinct from index-assigned O-level verification. 2.3. Axis 2 — Assurance Level A Quality Assertion without a declared assurance level is as dangerous as an organisation without an O-level: it suggests trust without a basis. +=======+===============+=========================+================+ | Level | Label | Meaning | Trust anchor | +=======+===============+=========================+================+ | A0 | Self-declared | Provider asserts it; no | provider | | | | external backing | reputation/ | | | | | liability only | +-------+---------------+-------------------------+----------------+ | A1 | Third-party | External party attests; | the attester | | | attested | not (necessarily) | | | | | accredited | | +-------+---------------+-------------------------+----------------+ | A2 | Accredited | Attester accredited | the | | | attestation | under a recognised | accreditation | | | | scheme | chain | +-------+---------------+-------------------------+----------------+ | A3 | Independently | Claim binds to a | the *method*, | | | verifiable | reproducible | not the | | | | measurement method | attester | +-------+---------------+-------------------------+----------------+ Table 3 Rehfeld Expires 17 December 2026 [Page 7] Internet-Draft APIX Quality Attestation June 2026 A3 is the gold standard: where reached, the issuer-pays failure mode (Section 7) collapses because the claim is auditable and challengeable independent of the attester. 2.4. Axis 3 — Claim Types and Temporal Binding The claim carries one of three value types: +==============+================+==============================+ | Type | Form | Example | +==============+================+==============================+ | boolean | conformance | { "type": "boolean", | | | yes/no | "conformant": true } | +--------------+----------------+------------------------------+ | ordinal | grade on a | { "type": "ordinal", | | | declared scale | "grade": "good", "score": | | | | 2.1, "scale": "" } | +--------------+----------------+------------------------------+ | quantitative | measured value | { "type": "quantitative", | | | + unit + | "value": 99.95, "unit": "%", | | | metric | "metric": "" } | +--------------+----------------+------------------------------+ Table 4 An ordinal claim MUST reference a registered scale (range, direction, meaning of steps). An agent MUST NOT order ordinal claims across different scales. Ordinal and product-bound claims are version- and time-bound. The subject_revision and the assessment time form part of the claim; a grade issued for a superseded product revision is a different claim from a current one. Agents MUST be permitted to discount assertions bound to a superseded revision when ranking. 2.5. Attestation Provenance and the Verification Basis Registry Provenance is expressed through the Core Verification Basis Registry, extended (not duplicated) by this document. The verification_basis facet identifies the evidence channel and its root, so that agents operating under a specific regulatory regime can filter by provenance — the same mechanism the Core uses for eIDAS 2 QEAA and GLEIF LEI at O-2. This extension registers additional verification-basis entries for quality attestation, each declaring a root class: Rehfeld Expires 17 December 2026 [Page 8] Internet-Draft APIX Quality Attestation June 2026 * root class accreditation — authority derived from an accreditation chain (e.g., a national accreditation body under [REG765] and its international peers). Used by accredited test/certification bodies. * root class statutory — authority derived directly from law (e.g., a competent authority issuing a GMP certificate). The chain terminates at a legal basis, not at an accreditor. * root class apix-governing-body — authority derived from the APIX Accredited Verifier model ([APIX-CORE] Section 8.6). This is the internal case and makes the Core Accredited Verifier model a special case of the general attestation layer defined here. *Self-reference.* An Attestation Body is itself a registered Organisation and carries ORG Quality Assertions describing its accreditation. The accreditation pyramid is therefore expressed in the same primitive. The index records and exposes the chain subject -> attester -> scheme -> root; it does not adjudicate legitimacy at any point. The consuming agent's policy decides which roots it trusts (Section 6). 2.6. Validity and Revocation status is one of active, suspended, revoked, expired. * valid_until in the past yields expired regardless of the last reported status. * Revocation MUST be checkable against a queryable status endpoint of the Attestation Body. An assertion whose revocation status is not checkable MUST be treated as at most A1, regardless of the declared level. * last_verified records when validity was last confirmed. 3. Relationship to Core Trust Fields (Normative) The Core requires that trust fields be set exclusively by the index operator and that a Service Owner MUST NOT assert its own trust level ([APIX-CORE] Section 7.1). Quality Assertions are NOT Core trust fields. They are a distinct field class: externally sourced or self- declared claims that the index _records with provenance_, not trust levels the index _assigns_. This mirrors how the Core already records O-level evidence channels as facts about how a level was substantiated. Accordingly: Rehfeld Expires 17 December 2026 [Page 9] Internet-Draft APIX Quality Attestation June 2026 * A self-attested Quality Assertion is permitted but MUST be carried at A0 and MUST be clearly distinguishable from any index-assigned O/S value. It MUST NOT be presented as, or promotable to, a Core trust level. * The index MUST NOT raise or lower a Core O/S level on the basis of a Quality Assertion in this extension. 4. The Quality Criterion Registry Comparability is the hardest sub-problem: self-defined, incomparable labels reproduce the eco-label proliferation failure where noise destroys signal. The governance of this registry mirrors the Core capability taxonomy ([APIX-CORE] Section 5.3) rather than inventing new machinery. * Criteria are *registered, not ad hoc*: stable ID, human-readable definition, and — where applicable — a measurement method. * Criteria are *hierarchically namespaced* by domain, e.g. pharma.gmp.sterile-fill, consumer.graded.overall, safety.product.<...>. A domain filter is thus a namespace filter. * Each criterion declares *scope disjunctness*: what it does NOT cover. An attestation without scope is not machine-meaningful. * Quantitative criteria MUST declare verb, unit, and threshold to permit A3. * Ordinal scales are registered with range, direction, and step meaning. * The registry follows the Core registry deprecation lifecycle (grace period, warning period, sunset). Registry governance MUST be federated, not centrally curated by the index operator, to avoid creating a second capture point (Section 7). 5. Discovery and Filtering Individual quality marks are NOT hard-wired top-level fields; that would be both a capture point and a brittleness source. Instead: * First-class is the _ability to filter over Quality Assertions_ as a query capability; marks are data addressed by Quality Criterion IDs. * A domain filter is a namespace prefix filter over criterion IDs. Rehfeld Expires 17 December 2026 [Page 10] Internet-Draft APIX Quality Attestation June 2026 * The Index API SHOULD allow filtering by any combination of object_type, criterion (or namespace prefix), assurance_level >= A2, status = active, verification_basis root class, and assessment validity date. 6. Ranking, Weighting, and the Private Overlay 6.1. Two Data Natures * *Attested quality* is about the subject, third-party attestable, belongs in the federated index (visibility: public). * *Relationship depth* is relational, specific to the requester- provider pair, confidential business intelligence. It MUST NOT enter the public index (visibility: private). Placing relationship depth in the public index would leak who does business with whom, and server-side ranking on such signals would itself be a manipulation/capture point. 6.2. Hard Invariant No signal that is not a verifiable public Quality Assertion (or a Core trust field) MAY influence server-side ranking. This follows the Core principle that the index exposes verifiable facts, not recommendations, and that trust decisions remain with the consuming agent ([APIX-CORE] Section 8). Weighting of relationship depth is therefore client-side by design, not by limitation. An index MAY offer stateless server-side scoring in which the agent supplies a weight vector over _criteria_ and the index sorts by _public_ data only; such scoring is a recomputable convenience and MUST NOT consider any private or relational signal. 6.3. Relationship Depth as a Private Overlay Relationship depth is modelled in the same primitive as a requester- held Quality Assertion with visibility: private — an overlay the agent merges locally with the public assertions before applying its weighting policy. The Core already establishes a private-state precedent: device instance trust state is never returned to unauthenticated queries ([APIX-CORE] Section 8.4). Without this overlay an agent would see only identically certified, interchangeable providers and relational trust capital would evaporate. The overlay is the second anti-commoditisation mechanism alongside the public attestation layer. Rehfeld Expires 17 December 2026 [Page 11] Internet-Draft APIX Quality Attestation June 2026 6.4. Root Trust Policy and Recognition 6.4.1. Purpose A Quality Assertion (Section 2.1) carries a verification_basis that resolves to a terminal root authority (Section 2.5). A consuming agent cannot enumerate every accreditation body and competent authority in the world, and it cannot delegate that judgement to the index without recreating the central-arbiter failure mode the Core forbids ([APIX-CORE] Section 8: the index exposes verifiable facts, not recommendations; trust decisions remain with the consuming agent). This section defines (a) how recognition relationships between roots are expressed as data in the federated index, and (b) how a consuming agent declares, in a *Root Trust Policy*, which roots it accepts — directly or through a recognition framework — and at what effective assurance. The separation is deliberate and follows Section 6.2: recognition _facts_ are federated, verifiable assertions; root trust _choices_ are a client-side policy. No part of recognition is adjudicated server-side. 6.4.2. Roots and Root Classes A *Root* is the terminal authority of a verification_basis chain. It has a stable identifier and a root class (Section 2.5): * accreditation — a national accreditation body (e.g., one operating under Regulation (EC) 765/2008) or its international peer structure. * statutory — a competent authority whose mandate derives from law (e.g., a GMP-inspecting authority). * apix-governing-body — the APIX Accredited Verifier root ([APIX-CORE] Section 8.6). 6.4.3. Recognition Expressed as Quality Assertions A recognition relationship is itself a Quality Assertion, reusing the single primitive (Section 2.1). A *Recognition Assertion* states that a root is a signatory of a recognition framework for a defined scope: * subject — the recognized Root (registered as an ORG) Rehfeld Expires 17 December 2026 [Page 12] Internet-Draft APIX Quality Attestation June 2026 * object_type — ORG * criterion — apix:qcrit:meta.recognition. whose scope is the recognition scope (e.g., testing, calibration, inspection, qms, gmp-inspection) * claim — { "type": "boolean", "conformant": true } * attester — the framework secretariat (e.g., the body administering an ILAC-MRA / IAF-MLA arrangement, a regional accreditation cooperation, or a competent authority administering a pharmaceutical MRA), itself a registered entity * verification_basis — the statutory or accreditation root of that secretariat * validity — the signatory status period; revocable per Section 2.6 The recognition framework is therefore just a well-known attester whose assertions say "Root X is my signatory for scope Y." Multilateral arrangements (one secretariat, many signatories) produce one Recognition Assertion per signatory. The index records and exposes these; it does not adjudicate them. 6.4.4. The Root Trust Policy A consuming agent expresses a Root Trust Policy as an ordered set of entries. Each entry is one of: * *Explicit root trust* — trust a named Root directly. * *Framework trust* — trust every signatory of a named recognition framework. Every entry MAY carry: * scope — a set of Quality Criterion namespaces to which the entry applies (e.g., pharma.gmp.*). An entry with no scope applies to all criteria. An entry MUST be ignored for any assertion whose criterion falls outside its scope. * assurance_cap — an upper bound on the effective assurance level contributed by assertions accepted under this entry. * max_recognition_depth — for framework entries, the maximum number of recognition edges the agent will traverse (Section 6.4.6). Default 1. Rehfeld Expires 17 December 2026 [Page 13] Internet-Draft APIX Quality Attestation June 2026 The policy is *default-deny*: an assertion whose root is not matched by any policy entry contributes no assurance and MUST be treated as if self-declared (effective A0), regardless of its declared level. The assertion data remains visible to the agent; it simply earns no third-party assurance. 6.4.5. Assurance Resolution Algorithm (Normative) For each Quality Assertion the agent computes an *effective assurance level* as follows: resolve(assertion, policy): if assertion.assurance_level == A0: return A0 # self-declared; roots irrelevant if assertion.assurance_level == A3: # method-anchored: trust is in the method, not the attester if agent can re-run assertion.criterion.method: return A3 # independent of root trust # else fall through and treat as attester-anchored R = resolve_root(assertion.verification_basis) # 1. direct match e = policy.explicit_entry_for(R) if e and in_scope(assertion.criterion, e.scope): return min(assertion.assurance_level, e.assurance_cap) # 2. recognition match, bounded by depth and scope at every edge for f in policy.framework_entries: if recognized(R, f, depth_limit=f.max_recognition_depth, scope=assertion.criterion): return min(assertion.assurance_level, f.assurance_cap) # 3. default deny return A0 recognized(R, f, depth_limit, scope) is true iff there exists a chain of at most depth_limit valid (non-expired, non-revoked) Recognition Assertions linking a Root trusted under framework f to R, where the recognition scope covers scope *at every edge*. Scope is checked at every hop; a chain that loses scope coverage at any edge does not recognize R for that criterion. Notes: * A0 never gains assurance from roots. Rehfeld Expires 17 December 2026 [Page 14] Internet-Draft APIX Quality Attestation June 2026 * A3 is self-verifying: an agent that executes the criterion's measurement method needs no root trust at all. Root policy therefore primarily governs A1/A2 (attester-anchored) assertions. * Effective assurance is always the minimum across the assertion's own level, any recognition cap, and the matched policy entry's cap. 6.4.6. Recognition Depth and Anti-Laundering Transitive recognition ("A recognizes B, B recognizes C") is a laundering surface: a weakly governed framework could relay trust from a strong one. The default max_recognition_depth is therefore *1* (direct recognition only). An agent MAY raise it but SHOULD NOT exceed a small bound, analogous to X.509 path-length constraints. Recognition chains MUST be acyclic; an agent MUST detect and reject cycles. 6.4.7. Bootstrapping and Default Policies An agent needs an initial trust anchor. The index MUST NOT supply it (that would make APIX the gatekeeper). Instead, baseline Root Trust Policies are published by parties whose authority is independent of the index — typically regulators or regional bodies. A jurisdiction- specific baseline policy is the point at which regulatory-regime preference becomes machine-actionable: an agent operating under a given regime loads that regime's baseline (for example one that trusts roots anchored in that regime's accreditation cooperation and its recognized MRAs) and extends it locally. This is the policy- layer counterpart to the Core's verification_basis provenance filtering ([APIX-CORE] Section 8.1). Baseline policies are themselves data, not code: an agent SHOULD obtain them as signed, versioned documents and SHOULD record which baseline and version it applied. 6.4.8. Worked Example — GMP Recognition for CDMO Discovery A procurement agent sourcing contract manufacturing capacity expresses: Rehfeld Expires 17 December 2026 [Page 15] Internet-Draft APIX Quality Attestation June 2026 { "root_trust_policy": { "version": "2026-06-12", "entries": [ { "type": "framework", "framework": "apix:framework:eu-accreditation-cooperation", "scope": ["pharma.gmp.*"], "assurance_cap": "A2", "max_recognition_depth": 1 }, { "type": "framework", "framework": "apix:framework:eu-gmp-mra", "scope": ["pharma.gmp.*"], "assurance_cap": "A2", "max_recognition_depth": 1 } ], "default": "deny" } } The agent trusts EU-cooperation-anchored GMP authorities directly, and GMP authorities of mutual-recognition partner jurisdictions through the EU-GMP MRA framework — one hop only, scoped strictly to pharma.gmp.*. Everything else is denied for pharma. The specific partner authorities are never hardcoded in the policy; they are carried as Recognition Assertions in the index, e.g.: { "subject": "did:apix:root:competent-authority-partner-yy", "object_type": "ORG", "criterion": { "id": "apix:qcrit:meta.recognition.eu-gmp-mra", "scope": "gmp-inspection" }, "claim": { "type": "boolean", "conformant": true }, "assurance_level": "A2", "attester": "did:apix:secretariat:eu-gmp-mra", "verification_basis": { "channel": "mra_secretariat", "root_class": "statutory" }, "validity": { "issued": "2025-01-01", "valid_until": "2027-01-01", "status": "active" } } Resolution trace for a CDMO whose GMP PROC assertion is rooted at competent-authority-partner-yy (claimed A2): Rehfeld Expires 17 December 2026 [Page 16] Internet-Draft APIX Quality Attestation June 2026 1. Assertion level A2, not A0/A3 → resolve root. 2. No explicit entry for that root. 3. Framework eu-gmp-mra is trusted; one valid Recognition Assertion links the partner authority to the framework, scope gmp- inspection covers pharma.gmp.* at the single edge, depth 1 OK. 4. Effective assurance = min(A2, cap A2) = *A2*. Accepted. A CDMO whose GMP assertion is rooted at an authority with no recognition chain to either trusted framework resolves to A0 and is excluded by any Trust Policy requiring >= A2 for pharma.gmp.*. 6.4.9. Security Considerations (Recognition-Specific) * *Recognition spoofing* — a forged Recognition Assertion. Mitigated by requiring the attester (secretariat) to resolve to a registered entity with its own verification_basis; an unresolved secretariat downgrades the recognition to ineffective. * *Scope creep* — a recognition valid for one scope relied upon for another. Prevented by per-edge scope checking (Section 6.4.5). * *Stale membership* — an expired or revoked signatory still relied upon. Prevented by Section 2.6 validity precedence; an unresolvable revocation status makes the recognition ineffective. * *Transitive laundering / cycles* — bounded by default depth 1 and the acyclicity requirement (Section 6.4.6). * *Baseline-policy substitution* — a tampered baseline. Mitigated by signed, versioned baselines and by recording the applied baseline version (Section 6.4.7). 7. Structural Failure Modes and Mitigations +=================+========================+=====================+ | Failure mode | Mechanism | Mitigation | +=================+========================+=====================+ | Issuer-pays / | Provider-paid body is | A3 verifiability + | | rating-agency | lax | accreditation layer | +-----------------+------------------------+---------------------+ | Goodhart | Optimising for the | measurement-method | | | label, not the quality | binding + scope | | | | disjunctness | +-----------------+------------------------+---------------------+ | Label | Inflation of | governed Quality | Rehfeld Expires 17 December 2026 [Page 17] Internet-Draft APIX Quality Attestation June 2026 | proliferation | incomparable labels | Criterion Registry; | | | | scope obligation | +-----------------+------------------------+---------------------+ | Accreditation | Index becomes the | index traverses | | capture | legitimacy gatekeeper | only; root trust at | | | | the agent | +-----------------+------------------------+---------------------+ | Relationship | "Know your supplier" | private overlay | | commoditisation | disappears | (Section 6.3); | | | | client-side ranking | +-----------------+------------------------+---------------------+ | Ranking capture | Server-side ranking on | hard invariant | | | purchased signals | (Section 6.2) | +-----------------+------------------------+---------------------+ Table 5 8. APM Integration A Quality Assertion set is carried under a single registered extension key in the APM extensions container ([APIX-CORE] Section 7.1). Example (illustrative; aligned to [W3C-VC] where applicable): Rehfeld Expires 17 December 2026 [Page 18] Internet-Draft APIX Quality Attestation June 2026 { "extensions": { "org.botstandards.quality.v1": { "assertions": [ { "subject": "did:apix:cdmo-example-7f3a", "object_type": "PROC", "criterion": { "id": "apix:qcrit:pharma.gmp.sterile-fill", "method": "EU-GMP Annex 1", "scope": "aseptic, lines 2-4" }, "claim": { "type": "boolean", "conformant": true }, "assurance_level": "A2", "attester": "did:apix:attester:competent-authority-xx", "verification_basis": { "channel": "gmp_authority", "root_class": "statutory" }, "validity": { "issued": "2025-09-01", "valid_until": "2028-09-01", "status": "active", "last_verified": "2026-06-12" }, "visibility": "public", "liability_regime": { "liable_party": "attester", "framework": "national pharma law" } } ] } } } A private overlay assertion carries the same shape with "visibility": "private", "attester": "self", "assurance_level": "A0", and is held by the requesting agent rather than submitted to the index. 9. Liability A price-justifying claim only holds if a party is liable when it is false; in agentic procurement a false, agent-relied-upon claim can trigger real damage chains. Every Quality Assertion MUST declare a liability_regime naming the liable party (attester / provider / none), the governing law or clause, and the coverage. The index records who attested what under which regime; the index itself bears no liability for the content of recorded attestations. Rehfeld Expires 17 December 2026 [Page 19] Internet-Draft APIX Quality Attestation June 2026 10. Security Considerations False or inflated attestations are the primary risk; the assurance ladder, the accreditation/verification-basis chain, and the requirement that revocation be checkable (Section 2.6) are the structural defences. Provenance spoofing is mitigated by requiring verification_basis to resolve to a registered Attestation Body and a registered root class; unresolved chains MUST downgrade the effective assurance level. Self-declared (A0) assertions carry no third-party assurance and MUST be treated by agents as provider claims only. Stale validity is handled by expired precedence and last_verified freshness. 11. IANA / Registry Considerations This document requests: * Registration of the org.botstandards.quality.v1 extension identifier in the APIX extension-identifier registry maintained by the governing body ([APIX-CORE] IANA Considerations; apix.example.org/registry/extensions). The identifier follows the Core format ..v. * Establishment of a Quality Criterion Registry under the governance rules of Section 4, mirroring the Core capability-taxonomy registry. * Reservation of the private.* criterion namespace as *client-side only*. Criteria under private.* (e.g., private.relationship.depth, Section 6.3) MUST NOT be registered in the public Quality Criterion Registry and MUST NOT be served by an index; they exist solely as requester-held overlay assertions (visibility: private). An index that receives a submission carrying a private.* criterion or visibility: private MUST reject it. This mirrors the reserved- namespace mechanism of [APIX-CORE] (contract.*, extension.*). * Additional Verification Basis Registry entries for quality attestation, each declaring a root class (accreditation, statutory, apix-governing-body), coordinated with [APIX-CORE]. 12. References 12.1. Normative References Rehfeld Expires 17 December 2026 [Page 20] Internet-Draft APIX Quality Attestation June 2026 [APIX-CORE] Rehfeld, C., "API Index (APIX): Core Infrastructure for Autonomous Agent Service Discovery", Work in Progress, Internet-Draft, draft-rehfeld-apix-core-07, n.d., . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 12.2. Informative References [CRA] "Regulation (EU) 2024/2847 (Cyber Resilience Act)", n.d.. [EIDAS2] "Regulation (EU) 2024/1183 (eIDAS 2)", n.d.. [REG765] "Regulation (EC) 765/2008 (Accreditation)", n.d.. [RFC9116] Foudil, E. and Y. Shafranovich, "A File Format to Aid in Security Vulnerability Disclosure", RFC 9116, DOI 10.17487/RFC9116, April 2022, . [W3C-VC] "W3C Verifiable Credentials Data Model", n.d.. Appendix A. Open Issues 1. Quality Criterion Registry governance details (who federates scale and metric definitions). 2. Private overlay storage: where and how visibility: private assertions are held client-side and protected against exfiltration. 3. Exact coordination procedure with the Core Verification Basis Registry to keep the O-5 cra_conformity boundary (Section 1.3) unambiguous. (Note: the former open issue on root-recognition policy format is resolved by Section 6.4.) Rehfeld Expires 17 December 2026 [Page 21] Internet-Draft APIX Quality Attestation June 2026 _End of draft-rehfeld-apix-quality-00. Composes with draft-rehfeld- apix-core-07 (co-submission cluster: core-07, services-04, iot-04, quality-00)._ Author's Address C. Rehfeld Email: carsten@botstandards.org Rehfeld Expires 17 December 2026 [Page 22]