APIX Quality Attestation Extension: Verifiable Product, Process, and Organisation Quality Claims for Discovered Services
draft-rehfeld-apix-quality-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Carsten Rehfeld | ||
| Last updated | 2026-06-14 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-rehfeld-apix-quality-00
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": "<scale-id>" } |
+--------------+----------------+------------------------------+
| quantitative | measured value | { "type": "quantitative", |
| | + unit + | "value": 99.95, "unit": "%", |
| | metric | "metric": "<metric-id>" } |
+--------------+----------------+------------------------------+
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.<framework> 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 <reverse-domain>.<extension-name>.v<major>.
* 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.,
<https://datatracker.ietf.org/doc/draft-rehfeld-apix-
core/>.
[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/rfc/rfc2119>.
[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/rfc/rfc8174>.
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,
<https://www.rfc-editor.org/rfc/rfc9116>.
[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]