Internet-Draft APIX Quality Attestation June 2026
Rehfeld Expires 17 December 2026 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-rehfeld-apix-quality-00
Published:
Intended Status:
Standards Track
Expires:
Author:
C. Rehfeld

APIX Quality Attestation Extension: Verifiable Product, Process, and Organisation Quality Claims for Discovered Services

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

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.

▲

Table of Contents

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:

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

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:

Table 1
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)

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.

Table 2
Object What is attested Real-world examples
ORG The legal/operational entity as a whole ISO 9001, domain quality marks
PROC A defined operated process GMP (pharma), ISO 13485, ISO 14001
PROD A specific service/output carries property X independent graded product test, fitness-for-purpose report

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.

Table 3
Level Label Meaning Trust anchor
A0 Self-declared Provider asserts it; no external backing provider reputation/liability only
A1 Third-party attested External party attests; not (necessarily) accredited the attester
A2 Accredited attestation Attester accredited under a recognised scheme the accreditation chain
A3 Independently verifiable Claim binds to a reproducible measurement method the method, not the attester

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:

Table 4
Type Form Example
boolean conformance yes/no { "type": "boolean", "conformant": true }
ordinal grade on a declared scale { "type": "ordinal", "grade": "good", "score": 2.1, "scale": "<scale-id>" }
quantitative measured value + unit + metric { "type": "quantitative", "value": 99.95, "unit": "%", "metric": "<metric-id>" }

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:

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

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.

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:

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.

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)

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

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.

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

{
  "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):

  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

Table 5
Failure mode Mechanism Mitigation
Issuer-pays / rating-agency Provider-paid body is lax A3 verifiability + accreditation layer
Goodhart Optimising for the label, not the quality measurement-method binding + scope disjunctness
Label proliferation Inflation of incomparable labels governed Quality Criterion Registry; scope obligation
Accreditation capture Index becomes the legitimacy gatekeeper index traverses only; root trust at the agent
Relationship commoditisation "Know your supplier" disappears private overlay (Section 6.3); client-side ranking
Ranking capture Server-side ranking on purchased signals hard invariant (Section 6.2)

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

{
  "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.

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:

12. References

12.1. Normative References

[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, , <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, , <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, , <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.)

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