Network Working Group J. Wei Internet-Draft Individual Intended status: Experimental 27 September 2026 Expires: 31 March 2027 Capability Language Core draft-wei-capability-language-core-00 Abstract This document defines the Capability Language Core (CLC), a minimal, executable language for describing what an agent is authorized to do. It defines the capability identifier grammar, the entailment relation between a grant and an operation, intersection of grants from multiple sources, the constraint model, and a deterministic decision function with stable reason codes and a three-valued verdict (allow, deny, allow_unresolved). The language is carrier-neutral: it defines what is evaluated, not how it is carried or trusted. Trust models, native verification, execution lifecycle, and receipt or token formats are out of scope (Section 11). Conformance is exercised by a published corpus of 123 vectors and 1184 property cases; three implementations (Go, Python, TypeScript) that share an author pass both. *Implementation conformance and this document's claim of a conformance class are separate.* An implementation conforms to CLC-A when it meets the obligations Section 12 lists for that class, and it may claim that conformance on its own, whatever other implementations exist. Section 12 additionally sets a maturity bar for _this document's_ claim — two independent implementations agreeing on verdict and reason. That bar is *not* met here: as Section 12 states under "Independence of implementations", the three implementations named in the README share an author, so their agreement is a regression test for the text, not independent validation. CLC-A is still claimed by this revision as the baseline authorization class, whose obligations are implementable and exercised by a published corpus; the independent-implementation threshold is recorded as unmet. The evidence-side class CLC-E is *not* claimed: its relations, value grammar, reference implementation and corpus ship here. Wei Expires 31 March 2027 [Page 1] Internet-Draft CLC-v1 September 2026 This revision also folds the delegation *containment* relation into the document (Section 13): Contains(parent, child) decides whether a child grant stays inside a parent's declared boundary — the single question a delegation chain asks at every hop that the core's entailment and intersection do not answer. It ships with the conformance class *CLC-D* and its own corpus, is strictly additive, and changes no CLC-A verdict, reason code, or vector. It absorbs the previously separate experimental containment extension, which is retired. 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 31 March 2027. 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Action . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Operation (authorization side) . . . . . . . . . . . . . 8 4.2. ObservedAction (evidence side) . . . . . . . . . . . . . 8 4.3. Identity . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Grant . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Wei Expires 31 March 2027 [Page 2] Internet-Draft CLC-v1 September 2026 6. Binding . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Entailment (authorization binding) . . . . . . . . . . . 11 6.2. Parameters . . . . . . . . . . . . . . . . . . . . . . . 11 6.3. Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 15 6.4. Match (evidence binding) . . . . . . . . . . . . . . . . 16 6.5. Extended parameter bounds (param_bounds) . . . . . . . . 16 6.6. Intersection of bounds (BoundMeet) . . . . . . . . . . . 20 7. Intersection (∩) . . . . . . . . . . . . . . . . . . . . . . 22 7.1. ConstraintUnion (derived projection) . . . . . . . . . . 25 8. Constraint . . . . . . . . . . . . . . . . . . . . . . . . . 26 8.1. Authorization-side constraints . . . . . . . . . . . . . 26 8.2. Evidence-side constraints . . . . . . . . . . . . . . . . 29 8.3. Unified constraint grammar . . . . . . . . . . . . . . . 29 8.4. Recognized but not evaluated (residual-obligation channel) . . . . . . . . . . . . . . . . . . . . . . . . 29 8.5. Resolving residual obligations (Resolve) . . . . . . . . 30 9. Decision Function (Authorization Side) . . . . . . . . . . . 32 9.1. Resolved Reason Ordering (normative) . . . . . . . . . . 34 9.2. Reason Codes (normative) . . . . . . . . . . . . . . . . 38 10. Satisfaction Function (Evidence Side) . . . . . . . . . . . . 42 11. Semantic Boundary . . . . . . . . . . . . . . . . . . . . . . 43 12. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 44 12.1. Language Revision . . . . . . . . . . . . . . . . . . . 47 13. Delegation Containment . . . . . . . . . . . . . . . . . . . 51 13.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 51 13.2. Terminology and Notation . . . . . . . . . . . . . . . . 52 13.3. Relation Signature . . . . . . . . . . . . . . . . . . . 52 13.4. Containment Algorithm . . . . . . . . . . . . . . . . . 53 13.4.1. Layer 1: Grant validity . . . . . . . . . . . . . . 53 13.4.2. Layer 2: Identifier coverage . . . . . . . . . . . . 53 13.4.3. Layer 3: Parameter narrowing . . . . . . . . . . . . 54 13.4.4. Constraints are outside the relation . . . . . . . . 55 13.4.5. Delegation-mode lattice (binding-profile pre-check) . . . . . . . . . . . . . . . . . . . . . 56 13.5. Reason Codes . . . . . . . . . . . . . . . . . . . . . . 56 13.6. Conformance Class CLC-D . . . . . . . . . . . . . . . . 57 13.7. Corpus . . . . . . . . . . . . . . . . . . . . . . . . . 58 13.8. AIC-JWT / AIC Certificate Binding . . . . . . . . . . . 59 13.8.1. Profile contract (for any binding profile) . . . . . 60 13.9. Related Work and Positioning . . . . . . . . . . . . . . 61 13.9.1. The gap CLC fills . . . . . . . . . . . . . . . . . 62 13.9.2. What containment is for . . . . . . . . . . . . . . 62 13.9.3. How CLC relates to adjacent work . . . . . . . . . . 62 13.9.4. Where the demand actually is . . . . . . . . . . . . 71 13.9.5. Adoption risks . . . . . . . . . . . . . . . . . . . 71 13.9.6. Positioning statement . . . . . . . . . . . . . . . 72 13.10. Open Issues . . . . . . . . . . . . . . . . . . . . . . 72 13.10.1. Parameter model rigidity (closed in CLC-1.10) . . . 72 Wei Expires 31 March 2027 [Page 3] Internet-Draft CLC-v1 September 2026 13.10.2. Consumer obligations for allow_unresolved (closed in CLC-1.11) . . . . . . . . . . . . . . . . . . . . . . 73 13.10.3. Constraints as a union axis (closed in CLC-1.12) . 73 13.10.4. Containment as evidence, not authorization (closed in CLC-1.13) . . . . . . . . . . . . . . . . . . . . . . 74 13.11. AuthorizeWithChain (fused chain authorization) . . . . . 74 13.12. Revision and Governance . . . . . . . . . . . . . . . . 75 14. Security Considerations . . . . . . . . . . . . . . . . . . . 75 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 77 16. Privacy Considerations . . . . . . . . . . . . . . . . . . . 78 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 78 17.1. Normative References . . . . . . . . . . . . . . . . . . 78 17.2. Informative References . . . . . . . . . . . . . . . . . 79 Appendix A. Consumption Mapping . . . . . . . . . . . . . . . . 81 Appendix B. Reference Vectors . . . . . . . . . . . . . . . . . 83 B.1. Syntax (9 vectors) . . . . . . . . . . . . . . . . . . . 83 B.2. Entailment (8 vectors) . . . . . . . . . . . . . . . . . 84 B.3. Params (39 vectors) . . . . . . . . . . . . . . . . . . . 85 B.4. Intersection (10 vectors) . . . . . . . . . . . . . . . . 90 B.5. Decision (34 vectors) . . . . . . . . . . . . . . . . . . 91 B.6. Combined (11 vectors) . . . . . . . . . . . . . . . . . . 95 B.7. Containment (external corpus) . . . . . . . . . . . . . . 97 B.8. Extended parameter bounds (external corpus) . . . . . . . 97 B.9. Resolve (external corpus) . . . . . . . . . . . . . . . . 98 B.10. ConstraintUnion (external corpus) . . . . . . . . . . . . 98 B.11. AuthorizeWithChain (external corpus) . . . . . . . . . . 98 B.12. BoundMeet (external corpus) . . . . . . . . . . . . . . . 98 Appendix C. Containment Carrier Vocabulary and Reason-Code Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 99 C.1. Vocabulary . . . . . . . . . . . . . . . . . . . . . . . 99 C.2. Failure-code mapping . . . . . . . . . . . . . . . . . . 100 C.3. Profile obligations exercised by the corpus . . . . . . . 102 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 102 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 102 1. Introduction CLC-v1 is a *universal minimal language* that can be consistently presented on either the authorization side or the evidence side. The two sides share five foundational abstractions: Wei Expires 31 March 2027 [Page 4] Internet-Draft CLC-v1 September 2026 +==============+====================+=======================+ | Foundation | Authorization Side | Evidence Side | +==============+====================+=======================+ | *Action* | Operation | ObservedAction | | | (concrete request) | (asserted effect) | +--------------+--------------------+-----------------------+ | *Identity* | CapabilityId | ActionId (instance- | | | (class-level) | level) | +--------------+--------------------+-----------------------+ | *Binding* | Entailment (grant | Match (evidence ↔ | | | ⊆ operation) | action) | +--------------+--------------------+-----------------------+ | *Constraint* | Grant params / | Evidence requirements | | | limits | / freshness | +--------------+--------------------+-----------------------+ | *Verdict* | allow / deny / | SATISFIED / | | | allow_unresolved | UNSATISFIED | +--------------+--------------------+-----------------------+ Table 1 *Conventions.* The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. "UTC instant" is an [RFC3339] timestamp. "JCS" is the JSON Canonicalization Scheme [RFC8785]; "I-JSON" is [RFC7493]. The language structure is identical on both sides; only the direction differs: * Authorization: "I grant you permission to do X" * Evidence: "I have evidence that X was done" The design principles behind this core — including what the language *deliberately refuses* (no control flow, no mutable state, no general-purpose policy language) — are stated in capability-language- core-principles-v1.md (in [CLC-CORPUS]): P1 minimal core · P2 no control flow · P3 immutable values · P4 domains, not types · P5 deterministic and terminating · P6 fail- closed · P7 define once, consume everywhere · P8 carriers separate from semantics · P9 local decidability · P10 bounded work · P11 composition narrows only · P12 ≥2 independent implementations Wei Expires 31 March 2027 [Page 5] Internet-Draft CLC-v1 September 2026 2. Terminology +================+==========================================+ | Term | Definition | +================+==========================================+ | *Action* | The thing being referenced — an abstract | | | operation class (auth) or a concrete | | | asserted effect (evidence). | +----------------+------------------------------------------+ | *CapabilityId* | Structured name identifying a class of | | | actions within a scheme. | +----------------+------------------------------------------+ | *Operation* | Concrete action request: a CapabilityId | | | plus parameters. | +----------------+------------------------------------------+ | *Grant* | Principal's authorization of a | | | CapabilityId with optional params and | | | constraints. | +----------------+------------------------------------------+ | *Binding* | Abstract concept connecting an Identity | | | to an Action. Entailment (auth) and | | | Match (evidence) are concrete instances. | +----------------+------------------------------------------+ | *Entailment* | Authorization-side binding: "Grant G | | | covers operation O" (⊆). | +----------------+------------------------------------------+ | *Match* | Evidence-side binding: "Evidence E is | | | bound to exact action A". | +----------------+------------------------------------------+ | *Constraint* | Bound on how an action may be used | | | (auth) or what evidence is required | | | (evidence). | +----------------+------------------------------------------+ | *Intersection* | Combining multiple grant sources into an | | | effective set (∩). | +----------------+------------------------------------------+ | *Verdict* | Outcome of evaluation: allow/deny/ | | | allow_unresolved (auth) or SATISFIED/ | | | UNSATISFIED (evidence). | +----------------+------------------------------------------+ | *Decision* | Authorization-side verdict: allow, | | | allow_unresolved, or deny + reason (+ | | | additive unresolved). | +----------------+------------------------------------------+ | *Satisfaction* | Evidence-side verdict: SATISFIED or | | | UNSATISFIED. | +----------------+------------------------------------------+ Wei Expires 31 March 2027 [Page 6] Internet-Draft CLC-v1 September 2026 Table 2 Note: *Binding* in CLC-v1 denotes the identity↔action relation (coverage on the authorization side, match on the evidence side). It is *not* key binding (cnf / DPoP / mTLS sender constraint), which belongs to the native artifact's specification (see Section 11). Verdicts are written lowercase on the authorization side (allow/deny/ allow_unresolved) and uppercase on the evidence side (SATISFIED/ UNSATISFIED), following the EMILIA/AEB convention. 3. Grammar capability-id = scheme ":" action [ ":" wildcard ] wildcard = "*" scheme = vendor "/" product "-v" major vendor = 1*( ALPHA / DIGIT / "-" ) product = 1*( ALPHA / DIGIT / "-" ) major = 1*DIGIT action = segment *( ":" segment ) segment = 1*( ALPHA / DIGIT / "-" / "_" / "." ) The trailing wildcard is part of the identifier grammar (the optional final ":" "*" above), so std/database-v1:query:* is a well-formed capability-id; only that shape is a wildcard (Section 3, below). *Unambiguous scheme.* Because product may contain -, the -v suffix is the *last* occurrence of -v followed by digits. A product that itself contains the two-character sequence -v is invalid (invalid_capability_id), so a/b-v1-v2 is rejected rather than parsed two ways; b-v1 as a product name is not expressible. A scheme in use before this rule that relies on such a product is out of grammar in v1. A v1 identifier is scheme:action (e.g. std/database-v1:query:SELECT). Trailing * as a complete segment matches *one or more* remaining segments (it does not match the empty remainder: std/database- v1:query:* does not cover std/database-v1:query). *Wildcard scope for v1*: CLC-v1 core defines exactly one wildcard shape: the complete trailing segment *. Partial (std/crm-v1:re*), bare *, **, {a,b}, [a-z] are *reserved for v2*; a v1-conforming implementation MUST reject them (unsupported_wildcard). If a capability scheme declares its own extended grammar, that scheme's conforming implementation may accept it; but CLC-v1 core conformance neither requires nor authorizes those forms (see Section 12). Wei Expires 31 March 2027 [Page 7] Internet-Draft CLC-v1 September 2026 *Wildcard detection precedes grammar conformance.* A forbidden wildcard shape is reported as unsupported_wildcard even when the same string also violates the base grammar (Section 3 segment): the wildcard-shape checks run before the generic invalid_capability_id test. +==========================+========================+ | Examples: std/database- | database:query invalid | | v1:query:SELECT valid | | +==========================+========================+ | std/database-v1:query:* | std/database- | | valid | v1:query:SEL* invalid | +--------------------------+------------------------+ Table 3 4. Action An action is the thing being referenced. CLC-v1 defines two concrete forms: 4.1. Operation (authorization side) A concrete action request: CapabilityId + parameters. { "id": "std/database-v1:query:SELECT", "params": {"tables":["customers"], "limit":{"max":50}} } Missing id → deny("missing_capability_id"). 4.2. ObservedAction (evidence side) The material action constructed by the effect boundary from executor- controlled facts. CLC-v1 defines the interface, not the construction algorithm. An ObservedAction carries: * action_type: the action type name declared by the relying-party- pinned type definition (the class this projection belongs to) * material_fields: every field the type definition declares *material* * digest: computed over the canonical *material projection* (below) The material projection is deterministic and normative: Wei Expires 31 March 2027 [Page 8] Internet-Draft CLC-v1 September 2026 * The action type declares a *material field set* (required and optional-but-included). Only that set enters the digest. * Canonical serialization is the JSON Canonicalization Scheme (JCS) [RFC8785]; the one suite defined in v1 is jcs-sha256 (Section 4.3). * The projection identity is the language's own, not a CAID: clc- action:1:::. A CAID [CAID] covers the *complete* Action Object under its own suite registry and identifies the action object, not an occurrence; this projection covers only the declared material set. The two are related by a relying-party-pinned Action-Mapping Profile (Section 6.4), never by treating the strings as interchangeable. * A field the type does not declare as material MUST be excluded from the digest and MUST NOT affect Match: an ObservedAction carrying undeclared fields is not invalidated, but those fields carry no action identity. * A type-declared material field that is *missing* makes the ObservedAction non-matchable: coverage MUST NOT be inferred, defaulted, or repaired (UNSATISFIED, Section 10). This is the evidence-side mirror of key closure (Section 6.2): the absence of a governing field is fail-closed, never fail-open. The effect boundary MUST construct the ObservedAction from facts it controls. It MUST NOT copy a requester-supplied action digest without deriving or checking the corresponding fact. 4.3. Identity Two identity levels, corresponding to the two Action forms: Wei Expires 31 March 2027 [Page 9] Internet-Draft CLC-v1 September 2026 +========+============+===========+=================================+ |Level |Identity |Scope | Example | +========+============+===========+=================================+ |Class |CapabilityId|Covers a | std/database-v1:query:* | | | |class of | | | | |actions | | +--------+------------+-----------+---------------------------------+ |Instance|ActionId |Identifies | clc- | | |(projection |the | action:1:payment.release.1:jcs- | | |digest) |material | sha256:... | | | |content of | | | | |one | | | | |action, | | | | |*not* an | | | | |occurrence | | +--------+------------+-----------+---------------------------------+ Table 4 A CapabilityId covers a class; an ActionId identifies the material content of one action. It does not identify an *occurrence*: ActionId binds the declared material content, and correlation to a particular occurrence additionally requires an occurrence discriminator defined and checked by the consuming profile. CAID-03 Section 4.6 carries such a discriminator as the optional occurrence_id of an action object; when a profile uses one, it MUST appear among the declared material fields for it to affect the digest. Allocating unique occurrences and proving one-time consumption or execution stay outside both documents (CAID-03 Section 7). Entailment checks class coverage; Match checks content binding. 5. Grant A grant = CapabilityId + optional params + optional constraints. grant = capability-id [ params ] [ constraints ] constraint = scheme ":" type [ ":" params ] Constraints are deny-when-declared: explicitly empty bound (e.g. zero max, empty allowlist) denies the class; omitted bound uses scheme default. 6. Binding Binding is the abstract concept of connecting an Identity to an Action. CLC-v1 defines two concrete instances: Wei Expires 31 March 2027 [Page 10] Internet-Draft CLC-v1 September 2026 6.1. Entailment (authorization binding) Grant G covers operation O if: 1. *Literal*: G = O (byte-for-byte after normalization). 2. *Trailing wildcard*: G = scheme:prefix:* and O has *at least one* segment after scheme:prefix: (segment-boundary comparison, not lexical prefix). +=========================+======================+===============+ | Grant | Operation | Result | +=========================+======================+===============+ | std/database-v1:query:* | std/database- | yes: wildcard | | | v1:query:SELECT | matches | +-------------------------+----------------------+---------------+ | std/database-v1:query:* | std/database- | yes: matches | | | v1:query:SELECT:deep | multi-segment | +-------------------------+----------------------+---------------+ | std/database-v1:query:* | std/database- | no: different | | | v1:admin:DDL | namespace | +-------------------------+----------------------+---------------+ | std/database- | std/database- | no: literal | | v1:query:SELECT | v1:query:INSERT | mismatch | +-------------------------+----------------------+---------------+ Table 5 6.2. Parameters +=========+===============================+=====================+ | Type | Rule | Example | +=========+===============================+=====================+ | number | op ≤ grant | 50 ≤ 100 (holds) | +---------+-------------------------------+---------------------+ | string | exact | "a" = "a" (holds) | +---------+-------------------------------+---------------------+ | boolean | exact | true = true (holds) | +---------+-------------------------------+---------------------+ | array | set of allowed values (enum): | {"station":[1,2,3]} | | | request scalar must equal a | ⊇ 2 (holds); ⊇ 9 | | | member; request array — every | (does not hold) | | | element must equal a member | | +---------+-------------------------------+---------------------+ | object | every grant key in op, values | {"t":["id"]} ⊆ | | | recurse | {"t":["id","name"]} | | | | (holds) | +---------+-------------------------------+---------------------+ Wei Expires 31 March 2027 [Page 11] Internet-Draft CLC-v1 September 2026 | other | exact equality | — | +---------+-------------------------------+---------------------+ Table 6 *Boolean parameters are exact only.* A boolean grant value is matched by exact equality (true covers true only). Booleans are *not* numbers: an implementation MUST NOT interpret true/false as 1/0 and MUST NOT run them through the numeric-bound rule (op ≤ grant). They also play no role in numeric comparisons or bounds. (Boolean GRANT- side bounds are rare in practice; the setting that matters — an operation-side boolean value under key closure — is pinned by undeclared-001.) Table rows map to vectors: number → params-001/params-002; array scalar member → params-009 (holds) / params-010 (fails); array element-wise → params-011 (holds) / params-012 (fails); object recursion allow → params-015, deny-direction → params-005; categorical guard → params-014. Under the old (pre-v1.1) array-as- bound rule the object example read (does not hold); with the v1.1 enum rule the request-side element id is a member of the granted set, so the row is (holds) (see clc-v1-ambiguities.md Section 2). *Enum semantics of arrays (v1.1).* An array-valued grant parameter is the *set of allowed values*, not an order. The request MAY supply a single scalar (must be a member of the set) or an array (every element must be a member). Members compare by *exact equality*: a number inside a granted array denotes that exact value, not a bound. This is what keeps categorical identifiers safe — grant {"station":[3]} does *not* cover station 2 (failure → deny("not_in_enum")). Scheme authors SHOULD encode categorical parameters (station, cell, batch, tool id) as arrays; a scalar number in the grant keeps upper-bound (bound) semantics for ordered quantities (max_rows, speed, angle). An explicitly empty grant array [] denies the class (empty_bound_denies_class). Grant with no params — or with an *empty {} params object* — covers any operation params (unconstrained). An absent params and "params":{} are semantically equivalent — consistent across entailment (Section 6.3) and intersection (Section 7 rule 6; Section 9.1). A null parameter value is invalid in v1 → reject (invalid_params_null). Absent ≠ explicitly empty (see Section 8). Wei Expires 31 March 2027 [Page 12] Internet-Draft CLC-v1 September 2026 *Key closure (Plan A).* A bounded grant governs its declared keys: an operation carrying a parameter key the grant does not declare is rejected → deny("undeclared_param") (fail-closed, Section 9.1 layer 7 request side). An unconstrained grant (no params, or params:{}) accepts any operation params, so no key closure applies there. Within layer 7 the missing-key check (params_missing) resolves *before* the undeclared-key check (undeclared_param); both are key- level and run before the enum/bound value checks (layers 8–9). *Params representation and input normalization (v1.1).* Before any Section 9.1 layer runs, the params object is normalized at the input boundary: 1. *Canonical serialization.* Params are normalized to the JSON Canonicalization Scheme form (JCS, RFC 8785): object members sorted by code unit, numbers in the ECMAScript Number::toString form, no insignificant whitespace. The original key order, number spelling and spacing are *not* preserved — canonicalization replaces them with the deterministic form (this is what the size cap in step 4 and the material digest are measured on). Evaluation never guesses; a lossy re-serialization (e.g. a map that drops duplicate keys) is not used for decisions. 2. *Duplicate keys.* A params object with a duplicate JSON key is rejected: deny("invalid_params_duplicate_key"). 3. *Number shape.* A numeric param is rejected with deny("invalid_params_number") when it is *non-finite or out of IEEE-754 range* (e.g. 1e400, an exponent beyond the representable maximum — it is an overflow, not an over-precision case) or *over-precision* (more than 17 significant decimal digits, e.g. 1.0000000000000001). The digit count operates on the *JSON token as received* — the raw digit-character sequence at the input boundary, before it enters any storage / float / decimal representation — so float64 and decimal/bignum implementations MUST NOT diverge: the judged input is always the raw token text (params-* number probes in the corpus; near-limit forms such as 1.0000000000000001 extend the probes without changing the rule). Malformed params text that cannot be parsed as an object is refused with the same code (see step 7). 4. *Size and depth.* Params whose canonical length exceeds 512 *UTF-8 octets* — measured in octets, never in code points or UTF-16 code units (rev CLC-1.4) — or whose nesting depth exceeds 32, are rejected: deny("invalid_params_size"). Nesting depth counts *both* objects and arrays, with the outermost object as level 1 (31 nested arrays inside the top-level object therefore = depth 32). Wei Expires 31 March 2027 [Page 13] Internet-Draft CLC-v1 September 2026 5. *Order of checks.* Size/depth (4) precede duplicate keys (2), which precedes number shape (3); the first failing check wins. All five run before Section 9.1 layer 1, so normalized params are the only view the layers see. The size in step 4 is measured with every token in its JCS spelling (numbers re-spelled per ECMAScript Number::toString, strings per JCS Section 3.2.2.2) but *without* requiring key uniqueness, so it is defined even when a duplicate key makes full JCS undefined; this is why an over-limit input that also has a duplicate key reports invalid_params_size (params-025/params-026). 6. *Decoded-object path.* A caller that supplies params already decoded (no raw_params text) cannot reproduce the original byte stream; in that case the size check (4) applies to a *canonical serialization* (the JCS form of the decoded object: sorted keys, compact), and the depth check (4) applies to the decoded structure directly. Byte-exactness against a specific original text is guaranteed only for the raw path; but *both* entry points MUST reject the caps — an oversized/deep params object is denied whichever way it arrives. 7. *Malformed Unicode is a property of the received text.* A lone surrogate escape, or an octet that is not valid UTF-8, has no JCS form (Section 3.2.2.2): step 1 cannot normalize it, so the input is refused. The refusal reuses invalid_params_number (Section 9.2), whose scope is *"the params input is not representable in canonical form"* — a numeric param that is non- finite / over-precision _or_ text that is not well-formed Unicode / not parseable as a JSON object. (One stable code, not one per malformation: introducing a second code would change the reason for inputs already pinned to invalid_params_number, which the additive rule forbids.) That check is defined over the octets as received and MUST run *before* any decoding step, because a general-purpose JSON decoder does not preserve the distinction. Go's encoding/json, for example, replaces both a lone surrogate escape and an invalid octet with U+FFFD, so {"s":"\ud800"}, {"s":"\ufffd"} and a literal invalid octet arrive at the decision function as the same value — {"s":"\ufffd"} — and the refusal cannot be recovered afterwards. Therefore: * the party that receives the input MUST run steps 1-5 on the received text, not on a re-serialization of a decoded value; Wei Expires 31 March 2027 [Page 14] Internet-Draft CLC-v1 September 2026 * an implementation that exposes *only* a decoded-value entry point MUST NOT be described as refusing malformed Unicode: its verdict is defined over the value it was handed, which may already be a repaired one. The entry point that takes the text is the normative one, and an implementation SHOULD name the two so a caller cannot mistake one for the other; * two parties that must agree on the verdict MUST agree on the received text, or on a digest of it. 6.3. Algorithm Entails(G, O) → bool: 1. G.namespace ≠ O.namespace → false (namespace = scheme + action Class, Section 9.1 layer 3) 2. G.id doesn't cover O.id → false (path coverage, Section 9.1 layer 4) 3. G declares no key → true (both `params` and `param_bounds` absent/empty → grant unconstrained, absent ≡ empty object) 4. O.params absent → false (bounded grant, request omits it → fail-closed, except a declared key marked `optional`, Section 6.5) 5. params_subset(O.params, keys(params) ∪ keys(param_bounds), param_bounds) (compare declared set incl. Section 6.5 bounds, Section 9.1 layers 5–9) Step 5 is the Section 9.1 layers 5–9 comparison over the grant's *declared key set* (keys(params) ∪ keys(param_bounds), Section 6.5): params values follow Section 6.2 value subset, and a param_bounds key additionally enforces its Bound (inclusive min/max, step, enum cardinality, optional, nested). A grant with no param_bounds reduces step 5 to the params-only comparison of earlier revisions. Steps 3 and 4 read the declared key set, so a grant whose only declarations are param_bounds is still "bounded" for presence purposes. When more than one check fails, the reported reason follows the fixed resolved-reason ordering of Section 9.1. The remaining rules of this section are unchanged. *Rule for missing operation params*: If the grant has a params bound (step 3 does not apply) and the operation has *no params field at all* (not merely a key missing, but the entire field absent), step 4 applies: Entails → false → deny("params_missing"). This covers both "operation omits the entire params object" and "operation omits a single bounded key" — both fail closed. If a capability scheme declares a default value for a parameter, the implementation MUST apply that scheme default to O before step 4; absent such a declared default, step 4 denies. Wei Expires 31 March 2027 [Page 15] Internet-Draft CLC-v1 September 2026 *Layer 6 (null) resolves before presence.* If the grant's params carry a null value (or the operation's params do), the failure is invalid_params_null (Section 9.1 layer 6) and is reported even when the operation omits the params field entirely — i.e. layer 6 resolves *before* step 4's params_missing. This is the fixed Section 9.1 ordering; it shadows the literal step order of the algorithm above, which lists presence before the null checks. 6.4. Match (evidence binding) Evidence E is bound to exact action A if: 1. E carries a valid ActionId in the language's projection form (clc-action:1:…, Section 4.3). A CAID is a different object and relates to it only through a pinned Action-Mapping Profile. 2. E's ActionId equals the recomputed ActionId of the ObservedAction. 3. The ActionId was computed under the relying-party-pinned suite and definition source. Match is content correlation only. It does not validate a native artifact and does not authorize execution. It also does not identify an occurrence: correlation to a particular occurrence additionally requires an occurrence discriminator defined and checked by the consuming profile (CAID-03 Section 4.6), and a profile that uses one MUST pin how it is obtained and that the language sees it among the declared material fields. Cross-format mapping (E's native format ≠ A's canonical form) uses an Action-Mapping Profile: a hash-identified projection pinned by the relying party, with results EQUIVALENT_UNDER_PROFILE, NOT_EQUIVALENT, or INDETERMINATE. 6.5. Extended parameter bounds (param_bounds) params (Section 6.2) stays exactly as defined: a scalar number is an upper bound, an array is a membership set, an object recurses per key, and there is no lower bound, no step, no cardinality bound and no optional-key marker. This subsection adds those as a *separate, optional grant field*, param_bounds, so that *no existing params input changes meaning*: a grant without param_bounds behaves exactly as before, and every params verdict is unchanged. *Binding rule (one authoritative representation per key).* A parameter key MUST be declared in *at most one* of params and param_bounds. Declaring the same key in both is rejected: Wei Expires 31 March 2027 [Page 16] Internet-Draft CLC-v1 September 2026 deny("invalid_params_binding"). The *declared key set* of a grant is keys(params) ∪ keys(param_bounds); key closure (Section 9.1 layer 7) and the params:{}≡absent rule are read over that set. *Four distinct layers — do not collapse them in a decoder.* A bare {} has different meaning at each layer, and an implementation must keep them separate before normalizing: 1. *Container presence* — "params" absent vs "params":{}. Both are *unconstrained* (no declared keys); {} is not "declares nothing and denies". 2. *Declaration site* — a key is declared via params *or* param_bounds (never both). The site decides which value algebra applies to the key. 3. *Value constraint* — inside params, an empty value *is* a restriction ({"tables":[]} denies the class; deny-when-declared, Section 6.2); inside param_bounds, an empty Bound {} declares the key with *no* value constraint (it only participates in key closure). Same {}, opposite reading, because the layer differs. 4. *Request value* — what O supplies (or a materialized default), evaluated per the key's family at layers 7–9. A decoder that maps {}→"absent" or {}→"empty set" uniformly across these layers will disagree with the language on at least one of them. *Bound grammar (closed).* param_bounds maps a key to a Bound object: Bound = { // a closed JSON object, at most one family // numeric family "min": , // inclusive lower bound "max": , // inclusive upper bound "step": 0>, // value must be an integer multiple of step // enum family "enum": [ ], // allowed values (membership set) "min_items": = 0>, // request cardinality lower bound "max_items": = 0>, // request cardinality upper bound // nested family "nested": { : Bound }, // recursion for an object-valued key // orthogonal to all families "optional": // request MAY omit the key (default false) } (Bound is JSON, not ASN.1: the members above are JSON keys and the comments are notation only.) Wei Expires 31 March 2027 [Page 17] Internet-Draft CLC-v1 September 2026 Every member is optional and the object is *closed* — a member outside this set is rejected (invalid_params_binding). A Bound carries *at most one value family*, plus optional which is orthogonal: * *numeric family* — any of min, max, step; * *enum family* — enum, and/or min_items/max_items; * *nested family* — nested. Mixing families (e.g. enum with max, or nested with min) is rejected (invalid_params_binding). An *empty* Bound {} declares the key with no value constraint (it still participates in key closure). min > max, step ≤ 0, min_items > max_items, or a negative min_items are rejected (invalid_params_binding). The whole param_bounds object is subject to the same input normalization as params (Section 6.2): canonical serialization, duplicate keys, number shape, size (512 octets) and depth (32), checked at layer 2. *Entailment semantics (grant G vs operation O).* * *Presence (layer 7).* A declared key with optional: true MAY be absent from O; a declared key with optional absent or false MUST be present (params_missing otherwise). An operation key not in the declared key set is undeclared_param. (Unchanged behavior for grants that declare no param_bounds, where every declared key is required.) * *Enum family (layer 8).* If enum is declared, the request value must be a member (not_in_enum, unchanged rule): a scalar request must equal a member; an array request must have every element equal to a member. Equal here is *JSON type-sensitive equality*: two values are equal only when they have the same JSON type _and_ the same value — true equals neither 1 nor 0 (the Section 6.2 rule that booleans are never numbers applies to set membership as well), and the string "1" equals neither the number 1 nor true. Numbers are compared after the Section 6.2 canonicalization of the input boundary (one IEEE-754 binary64 value, rendered per ECMAScript Number::toString under JCS [RFC8785]), so 1 and 1.0 — the same value in two spellings — *are* equal. The same equality is used by Section 6.2 array membership, by the Section 6.6 enum intersection, and by Section 13.4.3 enum narrowing; implementations MUST NOT substitute a host-language equality that coerces across JSON types (e.g. a language where true == 1). If min_items / max_items are declared, the *request cardinality* (an array's length; a scalar counts as 1) must satisfy min_items ≤ n ≤ max_items, else params_cardinality. Wei Expires 31 March 2027 [Page 18] Internet-Draft CLC-v1 September 2026 * *Numeric family (layer 9).* min/max are *inclusive*: a numeric request value must satisfy min ≤ v ≤ max (each bound, when declared), else params_out_of_range. step requires the request value to be an integer multiple of step, evaluated in IEEE-754 binary64 as let q = v / step in q == floor(q) && q * step == v (deterministic across implementations, since both operands arrive at the boundary as binary64), else params_not_multiple. A numeric-family bound applied to a non-number request value is fail-closed (params_exceed_grant). * *Nested family (layer 8/9).* nested recurses the value comparison on an object-valued request key with the same rules, including symmetric key closure and optional at each depth. A nested bound applied to a non-object request value is fail-closed (params_exceed_grant). *Scheme defaults.* A capability scheme (Section 3 scheme grammar; data/std/...) MAY declare param_defaults, a map from a parameter key to its *default value*. The consumer obligation of Section 6.3 is thereby made concrete: before evaluating Entails(G, O), an implementation MUST materialize, for every key O omits that the scheme declares a default for, that default into O's params; precedence is *explicit operation value > scheme default > absent*. A default is applied only when it is needed to satisfy a grant- declared key; it never adds a key the grant does not declare (the key-closure check is unchanged). *optional closes the default interaction (no recursion).* The presence of the key is decided *first*, by the grant's optional marker, and only then is a default consulted — so there is no "is the default needed?" loop: * a *required* declared key (no optional/optional:false) that O omits: materialize param_defaults[key] if the scheme declares one (the key is then present with that value), else deny("params_missing"); * an *optional:true* declared key that O omits: the default is *not* materialized — optional is the explicit "may be absent" marker and wins over the default, so the key is simply absent (and satisfies presence); * either way, an explicitly supplied O value wins over the default. Defaults are *scheme configuration, not language semantics*: the relation itself takes no scheme argument, and two consumers that load the same scheme reach the same verdict (a deployment that omits the scheme's defaults is a different input, and the difference is Wei Expires 31 March 2027 [Page 19] Internet-Draft CLC-v1 September 2026 attributable to the input, not to Entails). In the containment relation a default is resolved *before* the grants are compared (Section 13.8.1 obligation 1), so containment compares resolved declared sets. A param_defaults entry is *not* part of a grant's declared set and does *not* enter the containment lattice: Contains narrows over keys(params) ∪ keys(param_bounds) and the optional markers alone, so a parent's default never widens or inverts the optional→required narrowing direction (Section 13.4.3). *Containment (Section 13).* Section 13.4.3 narrows a child grant against its parent using this grammar: a param_bounds bound of the child must be within the parent's bound for the same key (numeric min raised or equal, max lowered or equal, step refined to an integer multiple, enum a subset, cardinality bounds tightened, optional not widened from required to optional, nested recursed). A parameter declared in one of params/param_bounds and not the other is a key-set difference and fails key closure (params_not_narrower). 6.6. Intersection of bounds (BoundMeet) Intersect (Section 7) combines the param_bounds of its sources with a *meet*, over the same "value → authorization set" denotation Section 7 uses for params. The families are those of Section 6.5; the meet is defined per key declared in param_bounds by two or more sources. * *optional* is orthogonal and combines by *conjunction*: the result key is optional only if every source marks it optional (optional := AND); a key required by any source stays required. * *numeric family* (min/max/step): min is the *greatest* declared minimum, max the *least* declared maximum (undeclared means unbounded). step: if both declare one and one is an exact multiple of the other (the Section 6.5 multiple predicate), the meet's step is the *coarser* (larger) of the two — the coarser grid is a subset of the finer, so it is the meet. If neither declared step is an exact integer multiple of the other, the meet *fails closed* (invalid_params_binding). The two grids may still share values — the common grid of step:5 and step:7 is the set of multiples of 35, so the intersection is not empty — but the meet's step must be one of the two *declared* steps: neither 5 nor 7 is an integer multiple of the other, so neither declared grid is a subset of the other, and the language does not synthesize an undeclared grid (such as the least common multiple) — no single step member of the two Bounds denotes both grids. One declared step is carried through. min > max after combining → the meet is *empty* → no_overlap. Wei Expires 31 March 2027 [Page 20] Internet-Draft CLC-v1 September 2026 * *enum family* (enum/min_items/max_items): the enum member sets intersect (exact equality — the JSON type-sensitive equality Section 6.5 layer 8 defines, so 1, true and "1" are three distinct members); if both sources declare enum and the intersection is empty → no_overlap; min_items is the *greatest* declared value, max_items the *least*; max_items < min_items → no_overlap. * *nested family* (nested): the two objects MUST have the *same key set*, else no_overlap (exactly as object-valued params, Section 7); the result recurses BoundMeet per key, with optional combining as above at every depth. * *numeric ∩ enum (either source order)*: *refused — fails closed* (invalid_params_binding). A sound meet would have to carry both the numeric side's shape constraint (min/max/step, which Section 6.5 layer 9 applies to numeric scalar request values only) and the enum side's member set (which Section 6.5 layer 8 applies to scalars *and* to arrays whose elements are all members) in one Bound — two families, which the closed Section 6.5 grammar deliberately does not express. Filtering the member list by the numeric bound (the rev CLC-1.14 rule, removed here) was *broader than either source*: for numeric {min:2,max:4} ∩ enum {enum:[1,3,5]} the filtered result enum{3} accepts the array [3] (Section 6.5 layer 8: every element is a member), while the numeric source fail-closes that same request (Section 6.5 layer 9: a numeric-family bound applied to a non-number request value is params_exceed_grant). Refusing the whole combination agrees with the rest of the language: Section 6.5 rejects _declaring_ two families in one Bound ("Mixing families … is rejected (invalid_params_binding)"), and Section 13.4.3 rejects _narrowing_ into a family the other side does not declare ("a child Bound that *adds a family the parent does not declare* … is params_not_narrower"). The refusal covers every numeric × enum pair — with or without a member list on the enum side (a cardinality-only enum is the same cross-family clash), and regardless of whether any member happens to fall inside the numeric range: the family clash is decided *before* any member or range math, and it is symmetric in the two sources. Wei Expires 31 March 2027 [Page 21] Internet-Draft CLC-v1 September 2026 * *scalar ∩ nested* (numeric or enum vs. nested), in either order: a cross-family meet, refused with invalid_params_binding *before* any value math — no single-family Bound can carry both a scalar shape (a value presence) and the object recursion; the refusal is symmetric in the sources and holds regardless of the nested side's contents, exactly like the numeric × enum case (design-notes D12). A CLC-1.14 draft read this pair as an empty meet (no_overlap, since no request value is both a scalar and an object); rev CLC- 1.15 adjudicates it to the unrepresentable-meet code so that the empty-meet code stays reserved for genuinely empty meets _within one value family_. * *empty Bound* {} is the identity for the value families ({} ∩ X = X); its optional still participates. The result always carries *at most one* value family, so it is a valid Section 6.5 Bound. All failure modes are the Section 9.2 codes already associated with Intersect (no_overlap for an empty meet _within one value family_, such as min > max or disjoint enums; invalid_params_binding for an unrepresentable one — every cross- family pair in either order, including scalar ∩ nested, and incommensurable step grids); no new reason code is introduced. *Key site.* A key's *declaration site* (params vs param_bounds) must agree across the sources of one Intersect. A key declared in params by one source and in param_bounds by another is refused (invalid_params_binding). This can only arise for independent authority sources, never for a delegation chain: Section 13.4.3 already requires the sites to match at every hop (a site difference is a key-set difference). A key that no source declares in param_bounds stays in params and follows the Section 7 params meet unchanged. 7. Intersection (∩) P_effective = P_principal ∩ C_agent ∩ P_gateway. Rules: 1. Each source provides a grant set. 2. Effective grant MUST be covered by at least one grant from every source. Wei Expires 31 March 2027 [Page 22] Internet-Draft CLC-v1 September 2026 3. Same-capability constraints merged by *union*: every source's constraint strings are kept (constraints are conjunctive — each is independently checked, so a tighter bound of the same type binds by construction). The merge is a set union of normalized constraint strings, *not* a meet that discards a looser one; dropping a source's constraint would drop its restriction. 4. Any source missing a capability → capability absent from effective set. 5. *Zero or absent sources fail closed.* An intersection over *no* sources at all — an empty source list, or every source absent — has no effective set: deny("absent_source"). (A source that _exists_ but carries no grant for the capability is rule 4, not rule 5.) 6. *Empty params declares no constraint.* A source whose grant has a present-but-empty params object contributes no restriction. The accumulated bound is preserved: bounded-then-empty and empty- then-bounded must give the same result — source order MUST NOT change the outcome (consistent with direct-grant params:{} ≡ absent, Section 6.3 step 3). *Identifier comparison is params-free (rule 2).* The effective identifier is the *narrowest* one covered by every source, chosen by the Section 6.1 identifier rules alone. It MUST NOT be resolved by routing grants through Entails with params — a bounded grant faced with a params-less sibling would trigger presence handling (Section 6.3 step 4) and wrongly fail this open; the identifier is compared, params merge separately (rule 3). *Property: composition narrows only.* If Intersect succeeds, the result MUST be covered by every source and MUST NOT depend on the order of the sources; otherwise it MUST deny with a normative reason code and MUST never raise. This meet-law is what the Section 6.2 param-subset algebra preserves across sources; it is pinned by property-cases.json (1184 cases, Section 12). *Notation in this section*: params are JSON objects (e.g. {"tables":["a"]}); constraints use colon-notation triples (e.g. varwof/constraint-v1:time:window:[{"start":"00:00","end":"01:00"}]). The example tables below use compact shorthand for readability; each row shows the relevant params or constraints only. *Deny-when-declared*: {"tables":[]} (explicitly empty) = deny the class. Omitted = scheme default. A null value is invalid in v1 → reject (invalid_params_null). Canonicalization MUST NOT broaden (segment-boundary comparison, not lexical prefix). Wei Expires 31 March 2027 [Page 23] Internet-Draft CLC-v1 September 2026 +====================+=============================================+================+ |Source A |Source B |Result | +====================+=============================================+================+ |{"tables":["a","b"]}|{"tables":["a"]} |{"tables":["a"]}| | | |(holds) | +--------------------+---------------------------------------------+----------------+ |{"tables":["a"]} |{"tables":[]} |deny | +--------------------+---------------------------------------------+----------------+ |(unconstrained) |(no grant) |deny | +--------------------+---------------------------------------------+----------------+ |{"limit":100} |{"limit":50} |{"limit":50} | | | |(holds) | +--------------------+---------------------------------------------+----------------+ |(unconstrained) |constraint |recognized, not | | |time:window:[{"start":"00:00","end":"01:00"}]|evaluated by | | | |core (→ | | | |allow_unresolved| | | |+ unresolved) | +--------------------+---------------------------------------------+----------------+ |{"tables":["a"]} |{"tables":["b"]} |deny | +--------------------+---------------------------------------------+----------------+ Table 7 *The meet is over authorization sets, not JSON values.* Neither Intersect nor Section 6.2 compares JSON values directly; each value denotes an *authorization set* and the meet is set intersection on that denotation. A number denotes (-∞, v] (an upper bound), an array denotes a membership set, a string/boolean denotes the singleton {v}, and an object denotes the product of its keys' denotations. So {"a":1} is not the set {1} but (-∞,1], and {"a":1} ∩ {"a":2} = (-∞,1] = {"a":1} — a minimum, not an empty set. A meet is *empty* (→ deny("no_overlap")) only when the denotations are genuinely disjoint: two enum sets with no common member (a numeric params meet is always a minimum, since params has no lower bound), or divergent key sets (next paragraph). *Object-value intersection requires identical key sets.* Two object values intersect key-by-key only when their key sets are the same; object values with different key sets → no_overlap deny. Merging "shared keys" would drop the keys the other source constrains, so the result would not be covered by that source (P11 composition narrows only): {"a":1} ∩ {"b":1} → deny(no_overlap). When the key sets *are* the same the values recurse under the Section 6.2 rules, so a numeric leaf intersects to its *minimum* ({"a":1} ∩ {"a":2} → {"a":1}, not a deny — matching the {"limit":100} ∩ {"limit":50} row above), and {"a":1} ∩ {"a":1} → {"a":1}. Wei Expires 31 March 2027 [Page 24] Internet-Draft CLC-v1 September 2026 *param_bounds merges by a defined meet.* Intersect combines each key declared in param_bounds with the meet of Section 6.6: numeric min/max/step, enum member intersection and cardinality, and nested recursion, with optional combined by conjunction. An empty meet is no_overlap; an unrepresentable one is invalid_params_binding — any cross-family pair in either order (numeric × enum, including a cardinality-only enum and regardless of whether any member falls inside the numeric range; and scalar × nested), or two step grids where neither declared step is an exact integer multiple of the other (Section 6.6). A key declared in params by one source and param_bounds by another is refused (invalid_params_binding, Section 6.6 "Key site"). The Section 7.1 ConstraintUnion projection is separate and unaffected. 7.1. ConstraintUnion (derived projection) A consumer that has established a delegation chain often needs the chain's *whole constraint burden* without computing an effective grant. That is exactly the constraint projection of chained Intersect (rule 3), exposed as a named function: ConstraintUnion(chain) → string[] // chain = ordered Grant[] It returns the *normalized union* of every constraint string carried by the grants in chain — duplicates folded, result deterministically ordered. "Lexically sorted" is pinned to *UTF-8 byte order*: the normalized strings are compared octet by octet over their UTF-8 encodings. For well-formed Unicode text this equals code-point order, and it is identical in every implementation whatever the host language's native string representation is — notably it is *not* UTF-16 code-unit order, which places supplementary-plane characters (encoded as surrogate pairs, first unit U+D800–U+DBFF) before characters in U+E000–U+FFFF, so an emoji would sort before a private- use-area character although its code point is higher. This collation sits _after_ Section 6.2 canonicalization, not instead of it: JCS [RFC8785] Section 3.2.3's UTF-16 code-unit order governs object *member* order inside a canonical serialization, while this section's UTF-8 byte order governs the emitted constraint-string *list*; the two artefacts keep their own pinned collations and neither re-orders the other. The union is the same normalization Intersect applies, so the two never disagree. The residual-obligation list of Section 8.4 (and the ordered Resolve output of Section 8.5) re-uses this same collation; the collation is defined here once, not restated there. ConstraintUnion is a *projection, not a meet*: it does not compare identifiers or parameters, does not read or validate constraint values, and does not check containment. It asserts nothing about authority; the chain's per-hop Contains check (Section 13) and the Wei Expires 31 March 2027 [Page 25] Internet-Draft CLC-v1 September 2026 operation's Authorize/Resolve (Section 9, Section 8.5) remain separate steps. Because it is not an effective-set computation, it carries no membership semantics of its own — an *empty chain fails closed* with absent_source (the same refusal Intersect gives over zero sources, Section 7 rule 5), so a caller that lost the chain cannot mistake "nothing to union" for "no constraints". This function is why Contains stays pure (Section 13.4.4): containment answers "is the child's declared boundary inside the parent's?", and the union answers "what does the chain collectively require?". Folding the union into Contains would make the relation no longer a subset on the declared tuple and would let a null constraint check hide a broken boundary. 8. Constraint Constraints are shared between authorization and evidence sides. 8.1. Authorization-side constraints Limit how a capability may be used. Constraints use colon-notation triples: scheme:type[:params], where *type is the second :-delimited segment* (scheme : type, optionally followed by : and params): * varwof/constraint-v1:max_rows:100 — type max_rows, param 100 * varwof/constraint-v1:time:window:[{"start":"00:00","end":"01:00"}] — type time, param window: array of UTC window segments (a single window = a one-element array). A scalar form (time:window:3600, the sliding-duration/freshness concept) is not a legal time:window value in v1 → invalid_constraint. * varwof/constraint-v1:network:cidr:["10.0.0.0/8"] — type network, param cidr: JSON array (≤ 32 elements, each a legal IPv4/IPv6 CIDR string) v1 core *recognizes constraints by (scheme, type) pair*, not by type name alone: the identity of a constraint is *two* things — the declaring scheme and the type. The core recognizes exactly these pairs: varwof/constraint-v1 : max_rows varwof/constraint-v1 : time varwof/constraint-v1 : network Any other (scheme, type) — including foo/database-v1:max_rows — is *not* core-recognized: it is rejected as unknown_constraint (fail- closed), never handed to a core evaluator. This kills cross-scheme Wei Expires 31 March 2027 [Page 26] Internet-Draft CLC-v1 September 2026 semantic pollution: the type name alone never selects an evaluator, so a scheme that defines its own max_rows cannot have its semantics hijacked by Core's max_rows evaluator (§P7 define once, consume everywhere — scoped per declaring scheme). Scheme-defined constraint types belong to the v2 / profile layer (evaluated by the declaring scheme); core's non-recognition of them is fail-closed (unknown_constraint). A recognized constraint MUST also conform to that type's *value grammar* (table below); a recognized type with a non-conforming value is rejected as invalid_constraint — never silently skipped, never passed through. Intersection itself neither evaluates nor validates constraint values (it only merges constraint strings; the Section 8.1 value grammar is enforced at the decision boundary, Section 9, and in the constraint merge rules below). The core defines an evaluator for max_rows only; evaluation of time/ network bounds is the declaring capability scheme's responsibility (the scheme evaluates, the core owns only what the Section 8.1 value grammar _is_, not whether a moment/address currently hits it; Section 11). A recognized-but-unevaluated constraint is carried on the decision's additive unresolved field — never silently dropped (Section 8.4). A non-recognized (scheme,type) → deny("unknown_constraint") (fail-closed). +========+==========================================+==================+ |type |value grammar (v1) |core behavior | +========+==========================================+==================+ |max_rows|strict non-negative integer (JSON number |evaluated against | | |grammar: no leading +, no 0x, no trailing |op params; the | | |characters) |*operation-side | | | |value domain* is a| | | |finite non- | | | |negative integer —| | | |an absent param, a| | | |string, a boolean,| | | |a negative, a | | | |fractional or a | | | |non-finite value, | | | |or a value above | | | |the bound → | | | |max_rows:violated | | | |(cannot be shown | | | |conforming = fail-| | | |closed; rev CLC- | | | |1.4); constraint | | | |value out of | | | |grammar → | Wei Expires 31 March 2027 [Page 27] Internet-Draft CLC-v1 September 2026 | | |invalid_constraint| +--------+------------------------------------------+------------------+ |time |non-empty JSON array (≤ 32 elements), |recognized only → | |(window)|elements |allow_unresolved +| | |{"start":"HH:MM[:SS]","end":"HH:MM[:SS]"},|unresolved | | |UTC, repeated daily, single window = one- |(Section 8.4) | | |element array; each endpoint is a | | | |*seconds-of-day* value (parsed from | | | |HH:MM[:SS]), with the reserved endpoint | | | |"00:00" in the end position read as | | | |*86400* (next-day midnight, 24:00) — so a | | | |segment is the half-open [startSec, | | | |endSec) and MUST satisfy startSec < endSec| | | |(*not* lexical string order, which would | | | |wrongly reject the canonical 22:00→00:00 | | | |segment, since "22:00" > "00:00" as text);| | | |a single segment *must not cross | | | |midnight*, so a crossing window is split | | | |into two same-day segments (22:00→00:00 + | | | |00:00→06:00); the segment list MUST be | | | |ascending by (startSec,endSec) and *non- | | | |overlapping* | | +--------+------------------------------------------+------------------+ |network |legal IPv4/IPv6 CIDR strings (addr/mask), |recognized only → | |(cidr) |syntax-level check only; JSON array ≤ 32 |allow_unresolved +| | |elements |unresolved | | | |(Section 8.4) | +--------+------------------------------------------+------------------+ Table 8 The expressible window set has no empty window and no full-day window; a declaring scheme that needs such windows extends the grammar (Section 11). Merge rules in v1: numeric → minimum wins; allowlist → intersection; unknown → deny. The allowlist is the array-enum set (Section 6.2); intersecting it takes the shared members. v1 core defines *no denylist constraint* — merging applies only to the varwof/ constraint-v1 types the core itself evaluates; it does not define or merge scheme-defined types (Section 11). Constraint-set merging is always *normalized and deterministically ordered* (duplicate strings collapsed, result ordered) — the same input yields the same constraint sequence in any implementation. v1 does not tighten time/ network bounds at intersection: intersection keeps only the constraint strings it encounters (no evaluation, no tightening, Section 8.4). Wei Expires 31 March 2027 [Page 28] Internet-Draft CLC-v1 September 2026 8.2. Evidence-side constraints Require specific evidence properties: freshness, consumption, quorum, initiator-exclusion, etc. These are structurally identical to authorization constraints — a type plus optional params — but evaluated against evidence artifacts rather than operation parameters. 8.3. Unified constraint grammar constraint = scheme ":" type [ ":" params ] Both sides use the same grammar. The validator (authorization) or evidence evaluator (evidence) interprets the type-specific params. 8.4. Recognized but not evaluated (residual-obligation channel) A recognized constraint whose value conforms to its Section 8.1 value grammar but for which the v1 core defines *no evaluator* — v1: time, network; evaluation belongs to the declaring scheme (Section 11) — MUST NOT be silently dropped: it must appear in the decision's additive unresolved list (Section 9), and the verdict must be *allow_unresolved* (not allow): Decision = { verdict: "allow"|"deny"|"allow_unresolved", reason, unresolved: string[] } *Fail-closed boundary*: allow_unresolved is an *independent enum value*, never equal to allow. A consumer (PEP / profile / declaring scheme) MUST evaluate or confirm every unresolved constraint before allowing; *if it cannot execute or confirm, it MUST deny* (AAC Section 6.6: "when it cannot perform or confirm, it should be treated as deny"). A consumer that only writes if decision.verdict == "allow" cannot, on the literal enum, release a residual obligation as an already-satisfied allow — a path that leaves obligations unconfirmed must explicitly handle allow_unresolved to pass. *"the caller is supposed to check unresolved" is not sufficient defense*: the verdict itself must refuse the two-value short-circuit. Wei Expires 31 March 2027 [Page 29] Internet-Draft CLC-v1 September 2026 unresolved semantics and ordering: [] for deny and for fully evaluated allow; for allow_unresolved the normalized constraint strings with duplicates folded — *the conditional collation order of Section 7.1 (#-separated, then by UTF-8 byte sequence), the same comparison the ConstraintUnion payload uses* (rev CLC-1.15). The order is deterministic: the same input yields the same byte sequence in any implementation — in particular NOT the ECMAScript default string order (UTF-16 code-unit order); join the residual obligations across all sources and sort exactly once, before emitting the decision. *Combined obligations (consumer side)*: multiple unresolved constraints of the same (scheme,type) form a conjunction (AND) — satisfying A and B satisfies all; OR, any-one, first-wins, and ignoring some entries are all *forbidden*. Constraints of different (scheme,type) do not interact; each evaluates under its own declaring scheme (P11 composition narrows only: conjunction only narrows). The core owns only the *value grammar* ("what it is"); "whether this window/CIDR currently forms a boundary" ("how to evaluate") belongs to the declaring scheme (Section 11) — but the *boundary-moment semantics are part of the grammar* (Section 8.1: half-open [start, end), single segment within one day, crossing split into segments), and a scheme MUST NOT change that interpretation, only evaluate on top of it. 8.5. Resolving residual obligations (Resolve) Section 8.4 delivers residual obligations but leaves the consumer's feedback loop undefined. Resolve closes it: a consumer reports, per obligation, whether it is satisfied, violated, or still unknown, and the core collapses the result to a fresh decision. Resolution = { constraint: string, status: "satisfied" | "violated" | "unknown" } Resolve(decision, resolutions, now?) → Decision decision is a Section 9 Decision; resolutions is an ordered list (possibly empty) of Resolution; now is an optional UTC instant (RFC3339, Z). now is the only input that lets the core tick a residual itself. Algorithm, in order: 1. *Terminal verdicts are fixed.* If decision.verdict is deny or allow, Resolve returns decision unchanged and ignores resolutions: a deny is never revived and an allow carries nothing to discharge. Wei Expires 31 March 2027 [Page 30] Internet-Draft CLC-v1 September 2026 2. *Malformed input fails closed.* An entry that violates the grammar above (unrecognized status, empty/non-string constraint) → deny with invalid_resolution; a now that is not a valid instant → deny with invalid_timestamp. 3. *Discharge on allow_unresolved.* Let O = decision.unresolved (already normalized and sorted, Section 8.4). For each o ∈ O, a status in {satisfied, violated, unknown} is computed by combining the sources below under the order *violated ≻ satisfied ≻ unknown* (the most restrictive source wins — a consumer that reports violated is never overridden by a lenient one, and the core clock is never overridden by a lenient assertion): * *Core clock* — if o is a core-recognized varwof/constraint- v1:time obligation whose value is a Section 8.1 window array, *and now is supplied*, the core evaluates it: now inside a segment → satisfied; outside every segment → violated. This is the obligation's *TTL*: the discharge horizon is the end of the segment containing now, so re-invoking Resolve with a later now re-evaluates to violated once the window has passed — a cached allow does not outlive its window. * *Consumer resolution* — a Resolution for o contributes its status; the most restrictive of the two wins. * Absent everywhere → unknown. 4. *Repeated entries* for the same constraint combine under the same violated ≻ satisfied ≻ unknown order. 5. *Unrelated resolutions are ignored.* A Resolution whose constraint is not in O cannot widen the outcome; O is authoritative. 6. *Result*: * any o has status violated → deny, reason = that constraint's {type}:violated (time:violated for a core-clock violation; otherwise the type segment of the constraint string), unresolved = []; * every o is satisfied → allow, reason null, unresolved = []; * otherwise → allow_unresolved, reason null, unresolved = the still- unknown subset (normalized + sorted, Section 8.4). Wei Expires 31 March 2027 [Page 31] Internet-Draft CLC-v1 September 2026 Without now, the core attaches no TTL to a time:window obligation: a consumer may report it satisfied (its declaring scheme owns its clock), but that discharge is only as fresh as the call, and a consumer that needs a core-enforced horizon MUST pass now. *Acting on a result (caching rule).* Resolve returns a plain decision; it does *not* carry an expiry field, so a core-clock discharge is only valid for the instant of the call. A consumer that acts on a Resolve result involving a core-evaluated time:window obligation MUST either re-invoke Resolve with a current now immediately before acting, or not cache the result beyond the current segment's end (the discharge horizon, Section 8.5 step 3) — it MUST NOT hold a cached allow past that horizon. Equivalently: a suite that needs a mechanically enforceable "valid until" value derives it from the segment end itself, not from the returned Decision. (The obligation carried on an allow_unresolved decision remains the Section 8.4 object a consumer evaluates; this rule is only about not outliving a clock-based discharge.) Resolve is deterministic and fail-closed; it is idempotent (Resolve(Resolve(d, r, now), r, now) = Resolve(d, r, now)) and monotone (adding a violated never turns a deny into an allow; removing one never turns an allow into a deny). It neither invents nor drops obligations. It subsumes the coarser identity-level consumer gate (the reference implementations' Discharge, which only answers "do I understand and commit to every obligation?"): confirming an obligation is the satisfied case. It defines no policy about _how_ the consumer evaluates an obligation (P2) — that is the declaring scheme's (Section 11). 9. Decision Function (Authorization Side) Authorize(grants, operation) → Decision Decision = { verdict: "allow"|"deny"|"allow_unresolved", reason: string|null, unresolved: string[] } // additive, Section 8.4 Algorithm. One precedence rule governs the whole function: *the grant-side pre-check resolves before operation validation.* An absent or empty grant set denies with capability_not_authorized even when the operation is absent as well (Section 9.1 layer 10; Appendix B.5, row D15, pins it), so a caller that passes neither input gets that reason and not missing_capability_id. The algorithm below therefore runs the grant-side pre-check *first*, ahead of the numbered operation steps — the numbering mirrors Section 9.1's layer order for what follows, not the precedence of the pre-check. Wei Expires 31 March 2027 [Page 32] Internet-Draft CLC-v1 September 2026 1. (Pre-check) An absent or empty grant set → deny("capability_not_authorized") (Section 9.1 layer 10), before any operation check; this is why the absent-grant / absent- operation pair resolves here and not to a layer-1 code. 2. Validate operation: missing/invalid id → deny with stable reason. The operation's *specific layer-1 code* is reported — missing_capability_id (no id), unsupported_wildcard (v1-forbidden wildcard shape) or invalid_capability_id (other grammar violation) — and is *not* collapsed to a generic code. 3. Find covering grants via Entailment (Section 6.1). No covering grant → deny("capability_not_authorized") (Section 9.1 layer 10); the absent/empty case was already resolved by step 0. 4. For each covering grant: evaluate constraints (Section 8.1): non- recognized (scheme,type) → unknown_constraint; recognized but non-conforming value → invalid_constraint; recognized with a core evaluator (varwof/constraint-v1:max_rows) and violated → {type}:violated; recognized without a core evaluator (time, network) → residual obligation (Section 8.4). 5. *Aggregate* (multi-grant set, Section 9.1): * Any covering grant that "allows" (no params/constraint rejection) → overall allow; * Residual obligations = the unresolved *union across the covering grants that also allow* (normalized + sorted). A covering grant that is rejected at the params/constraint layer contributes *no* obligations: it does not authorize, so its residuals are not carried. The union is nevertheless order- independent, because every covering-and-allowing grant is visited; * When no covering grant allows: if at least one covering grant rejects at the params/constraint layer → use the rejection reason of the *first covering grant in canonical order* (deterministic, Section 9.1); if no grant covers at all → capability_not_authorized. 6. Allow with non-empty residual obligations → verdict = allow_unresolved; allow with empty obligations → verdict = allow. Wei Expires 31 March 2027 [Page 33] Internet-Draft CLC-v1 September 2026 The grant set may be *absent or empty* — e.g. an integrator calls Authorize with no grant value or with an empty capability record. A safe evaluator MUST NOT raise; it MUST resolve such input to deny("capability_not_authorized") (falling out of layer 10/step 2). An absent operation resolves to deny("missing_capability_id") (layer 1); the evaluator MUST NOT raise there either. Properties: deterministic (same input → same output), fail-closed, stable reason codes. 9.1. Resolved Reason Ordering (normative) When more than one condition fails for a grant/operation pair, the *resolved reason* (the single code reported) is the first applicable layer in this fixed order. It applies to Entails (Section 6.3), Intersect (Section 7) and Authorize (this section). +==+=============+===============+==================================+ |# |Layer |Checks |Reason code(s) | +==+=============+===============+==================================+ |1 |CapabilityId |Section 3 |invalid_capability_id, | | |validity |grammar, |missing_capability_id, | | | |wildcard shape |unsupported_wildcard | +--+-------------+---------------+----------------------------------+ |2 |Params |Duplicate JSON |invalid_params_duplicate_key, | | |normalization|keys; non- |invalid_params_number, | | | |normalizable |invalid_params_size, | | | |numbers (non- |invalid_params_binding | | | |finite / out- | | | | |of-range / | | | | |over- | | | | |precision) and | | | | |malformed- | | | | |Unicode text; | | | | |size/depth | | | | |limits | | | | |(Section 6.2); | | | | |param_bounds | | | | |well- | | | | |formedness and | | | | |the one- | | | | |representation | | | | |binding rule | | | | |(Section 6.5) | | +--+-------------+---------------+----------------------------------+ |3 |Namespace = |Grant vs |different_namespace | | |scheme + |operation | | | |action Class |scheme and | | Wei Expires 31 March 2027 [Page 34] Internet-Draft CLC-v1 September 2026 | | |Class | | +--+-------------+---------------+----------------------------------+ |4 |Path coverage|Literal path |literal_mismatch, | | |(same |segments, |wildcard_requires_trailing_segment| | |namespace) |trailing- | | | | |wildcard depth | | +--+-------------+---------------+----------------------------------+ |5 |Explicit |Any grant/ |empty_bound_denies_class | | |empty bound |intersection | | | | |source | | | | |declares a | | | | |*parameter | | | | |value* that is | | | | |[]/{} (a | | | | |present-but- | | | | |empty params | | | | |object is _no_ | | | | |constraint, | | | | |Section 7 rule | | | | |6) | | +--+-------------+---------------+----------------------------------+ |6 |Null values |Any null |invalid_params_null | | | |parameter | | | | |value | | +--+-------------+---------------+----------------------------------+ |7 |Param |Grant bounds a |params_missing, undeclared_param | | |presence |param the | | | | |operation | | | | |omits (or | | | | |operation has | | | | |no params); | | | | |operation | | | | |carries a key | | | | |the grant does | | | | |not declare. | | | | |A param_bounds | | | | |key with | | | | |optional:true | | | | |is exempt from | | | | |the omission | | | | |half | | | | |(Section 6.5) | | +--+-------------+---------------+----------------------------------+ |8 |Enum |Request value |not_in_enum, params_cardinality | | |membership |not a member | | | |and |of a granted | | | |cardinality |array set | | | | |(Section 6.2); | | Wei Expires 31 March 2027 [Page 35] Internet-Draft CLC-v1 September 2026 | | |request | | | | |cardinality | | | | |outside a | | | | |param_bounds | | | | |min_items/ | | | | |max_items | | | | |(Section 6.5) | | +--+-------------+---------------+----------------------------------+ |9 |Bound |Numeric/bound |params_exceed_grant, | | |comparison |exceeded; |params_out_of_range, | | | |param_bounds |params_not_multiple | | | |min/max out of | | | | |range; step | | | | |not an integer | | | | |multiple | | | | |(Section 6.5) | | +--+-------------+---------------+----------------------------------+ |10|Coverage |Intersection |no_overlap, absent_source, | | |emptiness |result empty; |capability_not_authorized | | | |zero sources; | | | | |no grant | | | | |covers the | | | | |operation | | +--+-------------+---------------+----------------------------------+ |11|Constraint |Non-recognized |unknown_constraint, | | |evaluation |(scheme,type); |invalid_constraint, | | | |recognized |{type}:violated | | | |type value out | | | | |of Section 8.1 | | | | |grammar; | | | | |recognized | | | | |type violated | | +--+-------------+---------------+----------------------------------+ Table 9 Notes: * *Namespace* is scheme:action_class (the first two :-delimited segments). Identifiers in the same namespace differ only below the Class; such mismatches are path-level (literal_mismatch / wildcard_requires_trailing_segment), not different_namespace. * *Params normalization fires at the input boundary*: duplicate keys, over-precision/non-finite numbers, and size/depth overruns (Section 6.2) are detected before any grant-vs-operation comparison and therefore before every other layer of this table. Wei Expires 31 March 2027 [Page 36] Internet-Draft CLC-v1 September 2026 * *Deny-when-declared*: layer 5 is evaluated on the grant/ intersection side — an explicitly empty [] or {} param value denies the class regardless of the request, before any member or bound check. * *params:{} ≡ absent*: the params constraint looks only at the *set of declared param names*, independent of carrier form — an absent params and "params":{} both mean "no param names declared" = *no param constraint* (consistent across entailment and intersection; the same representation cannot have different semantics in different functions). Therefore: - Direct grant: a grant with params:{} *allows* an op carrying any params (.{x:1} does not trigger undeclared_param); - Intersection: a params:{} source *contributes no param constraint* ({limit:50} ∩ {} = {limit:50}); - Key closure (next bullet) applies only when the grant declares a *non-empty* set of param names. * *Layer 7 key closure runs both directions*: granted keys must be present in the operation (params_missing) and operation keys must be declared by the grant (undeclared_param); the missing-key check resolves first, and both precede the layer 8–9 value checks. (Applies only to a non-empty set of declared names, see the bullet above.) * *Layer 11 runs last by construction*: constraints are evaluated only after coverage and parameters pass. * *Multi-grant aggregation (normative)*: Authorize operates on a *ordered list of grants*, not a single grant. Authorization semantics are order-independent; only reason selection (rule 4) uses the input order. Rules: 1. *Any one covering-and-allowing grant allows* (∃ g: Entails(g,op) ∧ no params-layer rejection ∧ no constraint- layer rejection); 2. Residual obligations = unresolved *union across the covering grants that allow* (normalized + sorted). A covering grant rejected at the params/constraint layer contributes none — it does not authorize, so its residuals are not carried (they are never silently dropped from a decision it does not produce); 3. No grant covers → capability_not_authorized; op layer-1 errors always precede any coverage/aggregation decision; Wei Expires 31 March 2027 [Page 37] Internet-Draft CLC-v1 September 2026 4. Some grant covers but all covering grants reject at the params/constraint layer → deny, reason = the layer 5–11 rejection reason of the *first covering grant in canonical order* (deterministic). *Canonical order* = the appearance order in the input grant list (the capability-record body order); an implementation MUST NOT choose the reason by internal hash/iteration order. Counter-examples pinned (forbidden): NOT any-one-allows — otherwise, with multiple grants held, a narrow grant would wrongly deny the legal operation of a broad grant; NOT first-match-wins — otherwise grant order would change the authorization outcome; NOT all- must-pass — synonymous with "any-one-covers authorizes", letting a narrow grant's existence invalidate a broad grant. * *Op-ID validation errors propagate their specific layer-1 code* (missing_capability_id / unsupported_wildcard / invalid_capability_id), never capability_not_authorized and never an invented catch-all: step 1 reports the very code that describes the operation id. Only *coverage* failures (layers 3–4 and 10) collapse to capability_not_authorized. * *Layer 1 validates the operation id only.* A malformed id in a *grant* makes that grant non-matching for every operation: Entails reports the specific layer-1 code as its false reason, and Authorize folds the non-match into coverage (capability_not_authorized) — the grant's own code is not surfaced by the decision. * An *absent/empty effective grant* drops straight to layer 10 (capability_not_authorized); the evaluator MUST return this decision rather than raising. An absent operation drops to layer 1 (missing_capability_id). * A *language revision mismatch* (Section 12.1) is resolved before any layer and reports unsupported_language_revision (fail-closed, no downgrade). * *Resolve (Section 8.5) is post-decision, not a layer.* It consumes a Decision and never re-runs Authorize; only invalid_resolution / invalid_timestamp (Section 9.2) and a {type}:violated obligation result are introduced by it, and only on an allow_unresolved input. 9.2. Reason Codes (normative) Reason codes are stable identifiers. v1 defines: Wei Expires 31 March 2027 [Page 38] Internet-Draft CLC-v1 September 2026 *Canonical code = everything before the first :*. An implementation MAY append : (e.g. the offending parameter name) as a diagnostic suffix; the canonical code is unchanged. All tooling and compatibility checks MUST compare the canonical prefix only. +====================================+==============================+ | Reason code | Meaning | +====================================+==============================+ | unsupported_wildcard | Wildcard shape forbidden in | | | v1 (bare *, partial | | | segment, **, {a,b}, [a-z]) | +------------------------------------+------------------------------+ | invalid_capability_id | CapabilityId does not | | | conform to the Section 3 | | | grammar | +------------------------------------+------------------------------+ | missing_capability_id | Operation has no id (layer | | | 1) | +------------------------------------+------------------------------+ | invalid_params_duplicate_key | Params contain a duplicate | | | JSON key (Section 6.2 | | | representation, Section 9.1 | | | layer 2) | +------------------------------------+------------------------------+ | invalid_params_number | The params input has no | | | canonical form: a numeric | | | param is non-finite, out of | | | IEEE-754 range, or over- | | | precision (> 17 significant | | | decimal digits) | | | (Section 6.2 step 3), or | | | the text is not well-formed | | | Unicode / not parseable as | | | a JSON object (Section 6.2 | | | step 7). One stable code | | | covers every "cannot be | | | normalized" params failure | | | (Section 6.2 | | | representation, Section 9.1 | | | layer 2) | +------------------------------------+------------------------------+ | invalid_params_size | Params exceed the 512-byte | | | serialized size or the | | | depth-32 nesting limit | | | (Section 6.2 | | | representation, Section 9.1 | | | layer 2) | +------------------------------------+------------------------------+ Wei Expires 31 March 2027 [Page 39] Internet-Draft CLC-v1 September 2026 | invalid_params_binding | A param_bounds bound is | | | malformed (unknown member, | | | mixed families, min > max, | | | step ≤ 0, min_items > | | | max_items), or a key is | | | declared in both params and | | | param_bounds (Section 6.5, | | | Section 9.1 layer 2) | +------------------------------------+------------------------------+ | different_namespace | Grant and operation differ | | | in namespace (scheme + | | | action Class, Section 9.1 | | | layer 3) | +------------------------------------+------------------------------+ | literal_mismatch | Literal identifiers differ | +------------------------------------+------------------------------+ | wildcard_requires_trailing_segment | Wildcard has no remaining | | | segment (...:* does not | | | cover ...) | +------------------------------------+------------------------------+ | capability_not_authorized | No grant in the effective | | | set covers the operation | +------------------------------------+------------------------------+ | no_overlap | Intersection of multiple | | | sources is empty | +------------------------------------+------------------------------+ | absent_source | Intersection over zero | | | sources — no effective set | | | (Section 7 rule 5) | +------------------------------------+------------------------------+ | params_exceed_grant | Request parameters exceed | | | the granted bound | +------------------------------------+------------------------------+ | params_missing | Grant bounds a parameter | | | but the request omits it, | | | or the request has no | | | params field at all (fail- | | | closed, Section 6.3 step 4) | +------------------------------------+------------------------------+ | undeclared_param | Operation parameter key not | | | declared by the grant's | | | params (key closure, | | | Section 6.2; Section 9.1 | | | layer 7 request side) | +------------------------------------+------------------------------+ | empty_bound_denies_class | An explicitly empty bound | | | at a parameter value | | | ([]/{}) denies the class. | Wei Expires 31 March 2027 [Page 40] Internet-Draft CLC-v1 September 2026 | | params:{} is not an empty | | | bound: it is equivalent to | | | an absent params (Section 7 | | | rule 6) | +------------------------------------+------------------------------+ | not_in_enum | Request value is not a | | | member of the allowed set | | | granted as an array | | | (Section 6.2 enum rule) | +------------------------------------+------------------------------+ | params_cardinality | Request cardinality is | | | outside a param_bounds | | | min_items/max_items | | | (Section 6.5) | +------------------------------------+------------------------------+ | params_out_of_range | Request value is outside a | | | param_bounds min/max | | | inclusive bound | | | (Section 6.5) | +------------------------------------+------------------------------+ | params_not_multiple | Request value is not an | | | integer multiple of a | | | param_bounds step, per the | | | IEEE-754 rule (Section 6.5) | +------------------------------------+------------------------------+ | invalid_params_null | null parameter value | | | (rejected in v1) | +------------------------------------+------------------------------+ | unsupported_language_revision | Declared CLC revision is | | | incompatible with the | | | implementation | | | (Section 12.1; fails | | | closed, no silent | | | downgrade) | +------------------------------------+------------------------------+ | unknown_constraint | Unknown constraint type | | | (fail-closed) | +------------------------------------+------------------------------+ | invalid_constraint | Recognized type whose value | | | fails its Section 8.1 value | | | grammar | +------------------------------------+------------------------------+ | {type}:violated | A known constraint is | | | violated (e.g. | | | max_rows:violated); also | | | reported by Resolve for a | | | discharged-as-violated | | | obligation (Section 8.5) | Wei Expires 31 March 2027 [Page 41] Internet-Draft CLC-v1 September 2026 +------------------------------------+------------------------------+ | invalid_resolution | A Resolve resolution entry | | | is malformed (unknown | | | status, non-string/empty | | | constraint) (Section 8.5) | +------------------------------------+------------------------------+ | invalid_timestamp | The Resolve now argument is | | | not a valid UTC instant | | | (Section 8.5) | +------------------------------------+------------------------------+ Table 10 Other schemes MAY define additional codes, but MUST NOT redefine these. 10. Satisfaction Function (Evidence Side) Satisfy(evidence_set, requirement) → Satisfaction Satisfaction = { verdict: "SATISFIED"|"UNSATISFIED", reason: string|null } Algorithm: 1. Verify each evidence artifact under its native rules. 2. For each required evidence role, check that an artifact fills it. 3. Check that each artifact is bound to the exact action via Match (Section 6.4). 4. Evaluate freshness, consumption, and role constraints. The evidence-side value grammar is defined in this revision: varwof/ evidence-v1:freshness:sec:, :consumption:once, :quorum:distinct:, :exclusion:initiator|executor (Section 8.2). A recognized constraint whose evaluation belongs to the enforcement point (consumption) evaluates to unknown, which at the top level yields UNSATISFIED (never SATISFIED) — the evidence side has no allow_unresolved; unresolved is an authorization-side channel (Section 8.4, Section 11). 5. All required roles filled and bound → SATISFIED. 6. Any role unfilled, unbound, or violated → UNSATISFIED. *Tri-state evaluation, binary report.* A recognized evidence-side constraint is evaluated three-valued (satisfied / violated / unknown). Satisfaction itself is binary. A constraint that evaluates to unknown at the top level — including one whose Wei Expires 31 March 2027 [Page 42] Internet-Draft CLC-v1 September 2026 evaluation belongs to the enforcement point (consumption) — MUST produce UNSATISFIED with a stable reason, never SATISFIED. unknown is an internal evaluation result, not a third top-level verdict. Properties: deterministic, fail-closed, stable reason codes. 11. Semantic Boundary CLC-v1 defines the *shared minimal vocabulary* and *evaluation algorithms* for both authorization and evidence. CLC-v1 does NOT define: * *Trust models*: who signs what, issuer trust, delegation chains (belongs to AIC-JWT [AIC-JWT], OAuth, SPIFFE, etc.) * *Native verification*: signature checking, schema validation, freshness enforcement (belongs to each native artifact's spec) * *Execution lifecycle*: consumption, invocation, reconciliation, outcome classification (belongs to EMILIA AEB [EMILIA-AEB] or equivalent) * *Receipt or token formats*: the wire formats for carrying grants, evidence, or bindings (belongs to protocol-specific specs) The boundary is: * CLC-v1 defines *what* to evaluate (grant ⊆ operation, evidence ↔ action) * Consumers define *how* to evaluate (native verification, trust anchors) * CLC-v1 defines *what* the output means (allow/deny/ allow_unresolved, SATISFIED/UNSATISFIED) — *allow and allow_unresolved are distinct enum values*; a consumer MUST NOT treat allow_unresolved as allow (Section 8.4) * Consumers define *what to do* with the output (invoke, record, reconcile) * CLC-v1 defines each known type's *value grammar* (what counts as a legal constraint value); the declaring scheme defines *how* that value is evaluated (whether this window/CIDR currently forms a boundary) Wei Expires 31 March 2027 [Page 43] Internet-Draft CLC-v1 September 2026 * *allow_unresolved is an authorization result, not evidence.* It marks an unresolved authorization (or policy) condition. A consumer that can evaluate the obligation under a pinned rule may release it; one that cannot MUST refuse. It takes on an evidence role only where a relying party separately defines one together with the native verifier for it (AEB); the language itself makes no such claim, and unresolved MUST NOT be read as "evidence still required" * *A Section 6.2 refusal does not transfer to a decoded value.* The input-boundary checks are defined over the text as received (Section 6.2). A deployment that must reproduce a refusal, or that applies a permit to a request it did not evaluate, therefore anchors the decision to the *received octets* or to a digest of them (Section 4.3) — never to a value a decoder has already normalized. A pipeline that can apply a permit to a request whose text was never checked has left the CLC boundary * CLC-A stays the *scope language*: material-action identity is referenced from CAID [CAID], heterogeneous evidence evaluation from AEC [AEC], the boundary lifecycle from AEB [EMILIA-AEB], and durable consumption/accounting from BCR [BCR]; the narrow crosswalk between them is the composition point * Principal/agent delegation and token attenuation stay with PAP [PAP] and AAT [AAT]; CLC consumes their authorization outcome rather than redefining it 12. Conformance CLC-v1 defines *three conformance classes*: *CLC-A (authorization side)* — the v1 baseline. A conforming implementation MUST implement: grammar (Section 3), entailment (Section 6.1), intersection (Section 7), decision function (Section 9), rejection of non-recognized (scheme,type) constraints (unknown_constraint, Section 8.1), rejection of non-conforming recognized-type values (invalid_constraint, Section 8.1), exposure of recognized-but-unevaluated constraints via the decision's unresolved field on an independent allow_unresolved verdict (never silently dropped, Section 8.4), multi-grant aggregation (Section 9.1), and stable reason codes (Section 9.2). *CLC-D (delegation side)* — the containment relation, defined in *Section 13*. A conforming implementation MUST implement Contains(parent, child) with its ordered layers, the relation's two stable reason codes (child_exceeds_parent, params_not_narrower) and its profile contract (Section 13.8.1), and MUST pass containment- Wei Expires 31 March 2027 [Page 44] Internet-Draft CLC-v1 September 2026 vectors.json. The third CLC-D code, delegation_mode_not_narrower, is produced by the binding profile's delegation-mode pre-check (Section 13.4.5) — never by Contains, which takes no mode argument — and belongs to the profile's obligations. A delegation policy that requires each hop to stay inside the previous hop's boundary reads Contains, not Section 7: entailment and intersection over the *declared* sets are necessary but not sufficient, because they do not compare a child's boundary against a parent's. An operation fitting a grant proves nothing about a child staying inside its parent, and where containment cannot be established a binding profile MUST NOT authorize the delegation. Contains is a language relation over grant values, not a wire format; the effective subset a delegation record carries is still the profile's to define. *CLC-E (evidence side)* — optional conformance profile, *implemented and pinned by a corpus in this revision, but NOT claimed*. Section 6.4 (match) and Section 10 (satisfaction) define the evidence-side relations; this revision also defines the evidence-side constraint value grammar (varwof/evidence-v1:freshness:sec:, :consumption:once, :quorum:distinct:, :exclusion:initiator|executor) and ships a reference implementation and a corpus. The class is withheld *on principle, not for lack of material*: agreement is the bar, and the bar is two _independent_ implementations (Section 12 of the principles document, P12; Section 12 here, "Independence of implementations"). Parity between implementations that share an author does not meet it. A second precondition is stewardship: the evidence-side semantics are the subject of joint review with EMILIA, so no claim is made ahead of that review. A future revision that claims CLC-E would carry these obligations, and an implementation that claims it today MUST: * evaluate the four evidence-side types over eligible evidence facts, returning a three-valued result (satisfied / violated / unknown) where unknown is never read as satisfied, and report a recognized constraint whose evaluation belongs to the enforcement point (consumption) as unknown rather than satisfied; * take eligibility from integrity-protected native results only: a fact that did not reach VERIFIED, or whose protected subject identifier is absent, MUST NOT be counted for quorum or exclusion; * implement instance identity and binding (Section 4.2/Section 6.4): an ActionId is the digest of the JCS canonical serialization of the *declared material projection*, an undeclared field MUST NOT Wei Expires 31 March 2027 [Page 45] Internet-Draft CLC-v1 September 2026 affect it, a missing declared material field makes the action non- matchable (never inferred or defaulted), and a comparison across suites or action types is INDETERMINATE — a mapping problem, never a match — unless a relying-party-pinned Action-Mapping Profile projects it; * implement CLC-REQUIREMENT-v1 as a *closed* object (an undefined member is rejected) whose expression uses the bounded grammar — AND/OR with equal binding strength, evaluated strictly left to right, parentheses as the only precedence mechanism — and treat an identifier with no eligible component as false; * take the requirement from relying-party configuration: a requirement supplied by the presenter MUST NOT be accepted or weakened; * pass evidence-vectors.json (Section 12 conformance corpora). An implementation that implements only CLC-A MUST NOT claim CLC-E. CLC-E does not add a wire format: carriers that need one (e.g. an Action Evidence Envelope) profile Section 6.4/Section 10 themselves. *Conformance corpora.* The suites below are published in the repository tree pinned as [CLC-CORPUS]; repository paths written as capability/... throughout this document are relative to that pinned tree, so the exact vectors named here are retrievable. CLC-A conformance is exercised by two machine-readable reference suites at capability/data/_vectors/clc-v1/: vectors.json — 123 vectors mapped to Appendix B — and property-cases.json — 1184 cases pinning the Section 7 meet-law, identifier narrowing and source-order independence. Their syntax is defined by vectors.schema.json; offline-vectors.json is a timestamped snapshot mirror. A conforming implementation MUST pass both suites. CLC-D conformance (Section 13) is exercised by containment-vectors.json — 64 vectors mapped to Section 13 — together with containment-property-cases.json (784 cases pinning the Section 13.3–Section 13.7 narrowing laws). containment- crosswalk-vectors.json carries 44 cross-vendor vectors that map six adjacent capability representations into CLC grants through pinned profiles and assert the containment verdict the unchanged relation reaches (Appendix C). *Genericity is exercised, not asserted.* crosswalk-vectors.json in the same directory carries 13 vectors in both directions: 5 that project a CLC decision into the members an AEB crossing record asks of a native source (the members CLC can establish, and the ones it explicitly does not), and 8 that map five foreign capability representations — OAuth RAR authorization_details, an AIC-JWT delegation authorization, an Action Evidence Graph capability class, Wei Expires 31 March 2027 [Page 46] Internet-Draft CLC-v1 September 2026 a UCAN {with, can} capability, and a delegation chain — into CLC grants through pinned cross-walk profiles and assert the decision the unchanged core reaches. A profile is a few lines of mapping written by whoever owns the foreign format; the core is not modified for any of them. The evidence side ships evidence-vectors.json in the same directory — 32 vectors covering the four evidence-side constraint types, their value-grammar rejections, requirement-expression binding, the closed requirement object, ActionId computation (Section 4.2: declared material projection, undeclared fields excluded, missing material field non-matchable, suite-tagged identifiers) and Match verdicts (Section 6.4: MATCH / NOT_EQUIVALENT / INDETERMINATE). Its runner ships with the reference implementation (register), and its syntax mirrors vectors.json. Implementations MUST NOT: redefine semantics, accept v1-forbidden wildcards, or broaden bounds during canonicalization. *Independence of implementations (honest scope).* The three implementations named in this repository's README (Go, Python, TypeScript) are *not independent evidence*: they share an author, and their agreement is a regression test for the specification, not third-party validation. An independent implementation is invited; until one exists, the parity claim in this document is scoped to "same-author, three languages, one corpus". Reviewers SHOULD treat a single-author parity claim as evidence that the text is _implementable_, not that it has been independently _interpreted_. *Experimental neighbours are not CLC.* The WIT/WPT interop study in varwof/aic-jwt (wit-wpt-interop/) is an *experimental* research artifact that implements a _different_, wider wildcard surface (**, {a,b}, [a-z]) which this revision rejects as unsupported_wildcard (Section 9.2). It is not a CLC-A implementation and MUST NOT be cited as one; it exists to study WIT/WPT provisioning and carries its own EXPERIMENTAL banner. 12.1. Language Revision Every implementation declares a language revision CLC-. — this document declares *CLC-1.15*. A capability input (grant, operation, or OCM) SHOULD carry the revision it was authored against; an input without a declared revision is treated as CLC-1.0. * *Compatible reading*: an implementation MAY evaluate an input whose declared major equals its own AND whose declared minor is ≤ its own (so an implementation of CLC-1.3 reads a CLC- 1.0/1.1/1.2/1.3 input, but not CLC-1.4 or CLC-2.0). Wei Expires 31 March 2027 [Page 47] Internet-Draft CLC-v1 September 2026 * *CLC-1.2 is additive*: it adds the unresolved field to the Decision shape and the invalid_constraint reason code without changing v1 verdicts on existing inputs; a CLC-1.1 implementation MAY claim CLC-1.1 against this document but is not CLC-A conformant (Section 12) until it exposes unresolved and rejects non-conforming recognized-type values. * *CLC-1.3 is additive, with one verdict value re-scoped*: it adds the allow_unresolved verdict value, closes the decision loop for residual obligations, and re-scopes allow to mean "fully enforced" only; allow/deny outputs on inputs with *no* residual obligations do not change. A CLC-1.2 implementation MAY claim CLC-1.2 against this document but is not CLC-A conformant (Section 12) until it emits the allow_unresolved value and applies the Section 8.1 (scheme,type) identity and cross-midnight window grammar. * *CLC-1.9 is additive*: it adds the containment relation and conformance class CLC-D (Section 13) without changing any CLC-A verdict, reason code or vector. A CLC-1.8 implementation that does not claim CLC-D MAY claim CLC-1.8 against this document and remains CLC-A conformant; an implementation that claims CLC-D MUST pass containment-vectors.json (Section 12). * *CLC-1.10 is additive with a minor gate*: it adds the optional param_bounds field and its four reason codes (Section 6.5). Every input that declares no param_bounds is unchanged, so a CLC-1.10 implementation reads every CLC-1.x input. An input that *uses* param_bounds MUST declare CLC-1.10 or later; an implementation that does not implement Section 6.5 MUST refuse such an input through the minor gate (unsupported_language_revision) and MUST NOT ignore the field — silently dropping bounds would grant more than the input declares (fail-closed). * *CLC-1.11 is additive*: it adds the Resolve function (Section 8.5) and its two input-error reason codes (invalid_resolution, invalid_timestamp) without changing any Authorize verdict, reason code or vector. A CLC-1.10 implementation that does not implement Resolve MAY claim CLC-1.10 against this document and remains CLC-A conformant; Resolve is exercised only when a consumer feeds a decision back, so no input shape is reinterpreted. A time:window obligation is still delivered as allow_unresolved (Section 8.4) — the core clock evaluator of Section 8.5 runs only inside Resolve with a supplied now. * *CLC-1.12 is additive*: it adds the derived function ConstraintUnion (Section 7.1) without changing any other relation, verdict, reason code or vector. The function is exactly the constraint projection of Intersect rule 3, so Intersect's output Wei Expires 31 March 2027 [Page 48] Internet-Draft CLC-v1 September 2026 is unchanged; an implementation that does not implement ConstraintUnion MAY claim CLC-1.11 against this document and remains CLC-A conformant. * *CLC-1.13 is additive and CLC-D-scoped*: it adds AuthorizeWithChain (Section 13.11), a CLC-D function that fixes the order of Contains and Authorize over an effective-chain Intersect. It changes no CLC-A verdict, reason code or vector; an implementation claiming only CLC-A is unaffected, and a CLC-D implementation adds it to its CLC-1.9-era Contains surface. * *CLC-1.14 is additive*: it defines the intersection of param_bounds (BoundMeet, Section 6.6) so that Intersect can combine a grant carrying the bounds Section 6.5 defines. It changes no verdict, reason code or vector for an input without param_bounds; it changes the refusal of an input *with* param_bounds from invalid_params_binding to the correct meet or empty-meet result. An implementation that does not implement Section 6.6 MUST refuse a param_bounds input through the minor gate rather than intersect it wrongly. *Honest scope of that change (noted in rev CLC-1.15).* One subset of inputs does *not* evaluate identically across the CLC-1.10→1.14 minor range: the inputs that declare param_bounds _and_ reach a relation that meets them — Intersect (Section 7) or AuthorizeWithChain step 3 (Section 13.11) — with two or more sources declaring a Bound for the same key. On that subset the direction of the change is *deny → allow*: what CLC-1.10–1.13 uniformly refused (invalid_params_binding) becomes the correct meet result (usually an allow-side effective grant); where the meet is empty, the denial's reason changes from invalid_params_binding to no_overlap. Entailment against a single grant (Entails/Authorize), containment, and every input without param_bounds are verdict- stable across the whole 1.x range. The compatible-reading rule above is therefore intact — it governs _readability_, not verdict stability — but verdict stability across minor revisions does not hold for that one subset, and a consumer MUST NOT assume it. (Rev CLC-1.15 moves the same subset again, in the opposite direction, for cross-family meets only; see its entry below.) * *CLC-1.15 is a corrective revision* (review-driven; see the Revision History): the cross-family numeric ∩ enum meet exception of CLC-1.14 is removed, so every numeric × enum meet refuses with invalid_params_binding in either source order (Section 6.6); enum membership equal is defined as JSON type-sensitive equality (Section 6.5 layer 8); ConstraintUnion's deterministic ordering is pinned to UTF-8 byte order (Section 7.1); delegation_mode_not_narrower is attributed to the binding profile's mode pre-check and moved out of the core reason Wei Expires 31 March 2027 [Page 49] Internet-Draft CLC-v1 September 2026 commitments (Section 13.4.5, Section 13.5, Section 13.6, Section 13.11); Contains antisymmetry is stated on semantic equivalence classes (Section 13.3); and AuthorizeWithChain states the caller's complete-authenticated-root-first-chain obligation (Section 13.11). It changes no verdict, reason code or vector for an input without param_bounds. On the Section 6.6 meet subset the direction *partly reverses* CLC-1.14: a cross-family numeric × enum intersection that CLC-1.14 reduced to a filtered enum — an allow-side effective grant — now refuses (*allow → deny*, invalid_params_binding), because the filtered enum was broader than either source (Section 6.6); same-family meets are unchanged. The same review adjudicated the scalar × nested pair (numeric or enum vs. object, either order) to the same cross-family refusal: that pair was already denied in CLC-1.14 (as no_overlap), so the direction there changes the *reason code only* (→ invalid_params_binding), not the verdict (Section 6.6, design- notes D12). The Section 8.4 residual-obligation list and the Resolve output re-use the Section 7.1 UTF-8 byte-order collation; an implementation whose native default ordering is UTF-16 code- unit order MUST apply the pinned comparison explicitly. An implementation that does not apply this revision MUST declare CLC- 1.14 or earlier and let the minor gate (Section 12.1) resolve any input that relies on the corrected behavior. * *CLC-A conformance and the minor gate are the two sides of one rule.* Claiming CLC-A (this section) means implementing the CLC- A-relevant semantics of the revision claimed — so an implementation that advertises CLC-1.15 MUST implement param_bounds (grammar and the Section 6.6 meet), Resolve, ConstraintUnion and the Section 6.2 canonicalization, not merely tolerate their inputs. The minor gate is the complement for an implementation that *lags*: it declares an older revision and refuses any input that uses a field or function introduced after it. The two MUST agree — an implementation MUST NOT claim a revision higher than it implements (which would silently evaluate newer inputs), nor claim CLC-A while refusing a well-formed input of its own declared revision. * *Incompatible reading MUST fail closed* with deny("unsupported_language_revision"). An implementation MUST NOT silently evaluate under a different revision — no downgrade, no warning-then-allow. * The revision check resolves *before any Section 9.1 layer* and yields the single resolved reason code unsupported_language_revision. Wei Expires 31 March 2027 [Page 50] Internet-Draft CLC-v1 September 2026 Vectors: revision-001 (input CLC-1.0 against an implementation declaring CLC-1.3 → eval normally, allow); revision-002 (input CLC- 2.0 → deny unsupported_language_revision). 13. Delegation Containment This section defines *containment*, the third grant-level relation of CLC-v1 alongside entailment (Section 6.1) and intersection (Section 7), and the conformance class *CLC-D* that exercises it. It is additive: it changes no CLC-A verdict, reason code or vector, and a CLC-A implementation that does not claim CLC-D is unaffected. It was folded into this document from the formerly separate containment extension, which is retired. 13.1. Motivation The two relations the core defines answer different questions: * *Entailment* (Section 6.1): does an _operation_ fit inside a _grant_? * *Intersection* (Section 7): what is the effective set when several grants cover one authority? Neither answers the question a delegation chain asks of every hop: *is the child's _declared_ grant inside the parent's _declared_ grant?* Intersection delivers a set that is necessarily common to the sources, but a result fitted to two grants proves nothing that one of the grants' boundaries would not also authorize on its own — it reasons about the _combined set_, not about a _child_ that must be a subset of a _specific parent_. The AIC ecosystem needs the child-parent question at two concrete boundaries: 1. *Delegation* (DelegationAuthTBS vs. a principal's grant): a sub- agent's requested capabilities, constraints and delegation mode must lie inside what the principal authorized. Without a shared relation this obligation is the _profile's_ job and is re- implemented per profile, so two profiles can differ on the same sub-agent grant. 2. *Publication bound* (rule signing): a rule a certificate holder publishes must not exceed the holder's own grant. This section states the general relation; register/ruleexec already applies the same idea in one instance (RuleWithinSignerGrant), and is a candidate early adopter. Wei Expires 31 March 2027 [Page 51] Internet-Draft CLC-v1 September 2026 Containment is intentionally *additive, not a CLC-v2 feature*: it does not change any CLC-A verdict, does not touch the CLC-A corpus, and can be adopted by any implementation that claims CLC-A without breaking compatible reading of existing inputs. 13.2. Terminology and Notation Grant and Operation are as defined in Section 2/Section 5 (identifier per Section 3, parameters per Section 6.2, constraints per Section 8). Contains(GP, GC) names the relation parent GP × child GC. * *Declared set* — the parameters a grant carries as constraints on operations (Section 6.2 value semantics: numbers bind as upper bounds, arrays as membership sets, objects recursively per key, explicit empty []/{} deny the class, {}≡absent). * *Bound* — a declared constraint value as interpreted by Section 6.2/Section 8.1 value semantics. * *Narrower* — a child grant is narrower than its parent when every value it declares is within the parent's declared bounds and its key set is closed by the parent's. Where the carrier defines a delegation mode, the child's mode must not widen the parent's either — that half is the binding profile's pre-check, not part of the language relation (Section 13.4.5). * *Mode lattice* — an abstract carrier-defined order over delegation modes, exercised by the binding profile's pre-check (Section 13.4.5), never by Contains; the AIC-JWT ordering is pinned in Section 13.8. 13.3. Relation Signature Contains(GP: Grant, GC: Grant) -> ContainmentResult ContainmentResult = { // JSON object (not ASN.1) "contains": , // false <=> one of the Section 13.4 layers failed "reason": // resolved reason code (core Section 9.2 code) } * contains is true *only when* every layer of Section 13.4 passes. * reason on success is empty; on failure it carries the *first failing layer's* reason code, per Section 13.4 layer order (deterministic: input order of the two grants never influences which layer reports first). Wei Expires 31 March 2027 [Page 52] Internet-Draft CLC-v1 September 2026 * The relation is *antisymmetric on semantic equivalence classes*, not on Grant objects: Contains(A,B) and Contains(B,A) both hold exactly when A and B fall in the same class — they denote the same identifier coverage, the same declared parameter key set and the same bounds under the Section 6.2/Section 6.5 value semantics, with surface-equivalent spellings identified (params:{} ≡ absent, Section 6.2). Two syntactically different Grant objects in one class (an equivalence, not an identity of JSON text) therefore contain each other; containment of grants in two _distinct_ classes in both directions is a contradiction and MUST NOT be reported. Delegation modes are not part of the relation (Section 13.4.5), so mode equality is neither required nor observable here — where a carrier binds modes, the profile's pre- check owns that comparison. 13.4. Containment Algorithm The relation resolves layers strictly in order; the first failure determines the reason code. Every layer is fail-closed: any doubt yields false. 13.4.1. Layer 1: Grant validity * If a grant identifier is malformed per Section 3, Contains returns false with the matching CLC-A syntax code (invalid_capability_id / missing_capability_id). Validation errors are reused from the core, not re-invented. * If GC.Params violates the grant-side parameter grammar (Section 6.2), the child is not a valid grant and Contains yields false (invalid_params_ codes as in the core). * An invalid parent grant also yields false: a boundary that cannot itself be evaluated must not authorize a child. 13.4.2. Layer 2: Identifier coverage The child identifier must be covered by the parent identifier using *exactly the CLC-v1 path-coverage relation* (the rules Entails applies to identifiers, Section 6.1/Section 6.3, with parameters excluded — the identical keyset empty-object edge is not relevant here because parameters are excluded from this layer by construction): * same namespace (scheme:action-class) — else different_namespace; Wei Expires 31 March 2027 [Page 53] Internet-Draft CLC-v1 September 2026 * same segment depth with equal literal segments, OR parent trailing * wildcard covering the child's trailing segments ("*" matches one or more segments, never zero) — else child_exceeds_parent. Mid-identifier wildcards remain unsupported_wildcard per Section 3: this section does not enlarge the v1 wildcard surface. 13.4.3. Layer 3: Parameter narrowing Every parameter the child declares must be _within_ the parent's declared bounds, using the Section 6.2 value-subset semantics, *and the key sets must be identical* (symmetric closure). The child and parent key sets are each the union of params and param_bounds keys (Section 6.5): * *number (from params)*: child value ≤ parent bound (upper bound only in params; richer bounds are expressed in param_bounds, below); * *string / boolean*: exact equality with the parent's value; * *array (enum)*: every child element must equal a member of the parent's set; a child empty array inside a non-empty parent enum is vacuously within it (child denotes "nothing", which is inside anything) — but a *parent* empty set denies the class (deny-when- declared), and a child empty set under a parent empty set is therefore false (params_not_narrower): the class is denied, not "narrowed to nothing"; * *object*: recursion per shared key, with the same symmetric key closure at every depth (a child object may not add a key the parent object does not declare, and may not omit one the parent declares); Wei Expires 31 March 2027 [Page 54] Internet-Draft CLC-v1 September 2026 * *param_bounds bound (Section 6.5)*: for a key with a Bound on the parent's side, the child's Bound for that key must be within it — a numeric family bound must have min raised or equal and max lowered or equal (min_child ≥ min_parent / max_child ≤ max_parent, and the child MUST declare a min/max the parent declares), a step must be an integer multiple of the parent's step (a coarser-or- equal grid whose values are a subset of the parent's allowed values), an enum family must be a subset with min_items/max_items tightened or equal, and a nested bound recurses. A parent key that is required (optional absent or false) forces the child's key to be required; a child MAY keep an optional key optional or make it required, but MUST NOT turn a required parent key optional. A child Bound that adds a family the parent does not declare, or omits a bound the parent declares, is params_not_narrower (the child would allow a value the parent denies); * *key closure*: the child key set MUST equal the parent key set, both ways. A child that omits a parent-declared key would allow operations the parent denies (the missing key is params_missing in entailment); a child that adds a key the parent does not declare allows operations the parent denies (undeclared_param). Either failure is params_not_narrower. This is the same symmetric closure Section 6.2 layer 7 applies to an operation vs. a grant, carried over to grant-vs-grant comparison; * *extra rule*: the parent's {} (or absent) params object is unconstrained and contains any child params; a child {} under a _bounded_ parent is false (params_not_narrower) — declaring nothing is not the same as declaring a subset of the parent's bounds. The presence semantics match Section 6.2 exactly: a grant (parent or child) whose params are present-but-empty {} is unconstrained, identical to an absent params object (Section 9.2/Section 6.2). 13.4.4. Constraints are outside the relation Constraints are *not* part of Contains. A grant carries constraints (Section 8), but they are a separate axis with a different composition rule: * *Constraints compose by union (conjunction), not by subset.* Along a delegation chain the effective constraint set is the _union_ of every link's constraints (Section 7 Intersect already unions them). A child therefore need not re-declare its parent's constraints, and adding or tightening a constraint only narrows. Wei Expires 31 March 2027 [Page 55] Internet-Draft CLC-v1 September 2026 * *Contains compares identifier and parameters only.* It does not read, compare, or validate the constraints field: a constraint difference never changes the Contains verdict. * *Constraint grammar and evaluation stay where they already are.* Whether a constraint identity is recognized, whether its value is in grammar, and whether an operation satisfies it are the CLC-A concern of the consumer and Intersect/the decision function (including the allow_unresolved residual-obligation channel, Section 8.4). This section neither re-decides nor weakens them. Consequences a reviewer should take as intended: Contains(P, C) does *not* by itself assert that C's operation set is inside P's when constraints are in play — the parent's constraints are carried forward by the chain's union (Intersect), and a consumer that uses Contains as its _only_ gate must compose the chain's intersections as well (Section 13.8). This is the honest reading: containment is a relation over the declared *identifier and parameter* boundary, and constraints are enforced by the union, not by this relation. 13.4.5. Delegation-mode lattice (binding-profile pre-check) Where a carrier defines a delegation mode, the child's mode must not widen the parent's. This check is a *required binding-profile pre- check*, not a layer of the language relation: as with constraints (Section 13.4.4), mode is a carrier-level concept — Grant values carry no mode, and the relation Contains(GP, GC) takes no mode argument, so a core Contains verdict can never express a mode decision. A binding profile (Section 13.8.1) that maps a mode- carrying carrier MUST run the mode-lattice check itself, before or alongside each Contains call, and MUST report delegation_mode_not_narrower *from the profile* when the child's mode widens the parent's; it MUST NOT rely on Contains for that check and MUST NOT present a Contains verdict as evidence that the mode narrowed. The lattice order is carrier-defined (CLC-D does not invent modes); the AIC-JWT order is authorized < representative — a child may be authorized under a representative parent, never the reverse. A carrier without a mode concept has no pre-check to run. 13.5. Reason Codes CLC-D registers exactly three child-level reason codes; *two of them are returned by the relation*, and everything else a Contains result carries reuses CLC-A codes. The third is produced only by the binding-profile delegation-mode pre-check (Section 13.4.5): the relation takes no mode argument and MUST NOT return it. An implementation MAY collapse child_exceeds_parent for identifier failures into the core's capability_not_authorized at a boundary that Wei Expires 31 March 2027 [Page 56] Internet-Draft CLC-v1 September 2026 must not reveal policy shape (Section 11), but MUST NOT collapse params_not_narrower; a profile that maps a mode-carrying carrier MUST NOT collapse delegation_mode_not_narrower either. +==============================+=================+=================+ | Code | Produced by | Meaning | +==============================+=================+=================+ | child_exceeds_parent | Contains, layer | child | | | 2 (Section | identifier not | | | 13.4.2) | covered by | | | | parent | | | | identifier | +------------------------------+-----------------+-----------------+ | params_not_narrower | Contains, layer | a child | | | 3 (Section | parameter is | | | 13.4.3) | not within the | | | | parent's | | | | declared bounds | | | | / key set | +------------------------------+-----------------+-----------------+ | delegation_mode_not_narrower | binding-profile | child | | | pre-check | delegation mode | | | (Section | (a carrier | | | 13.4.5) — never | concept) widens | | | by Contains | the parent's | +------------------------------+-----------------+-----------------+ Table 11 There is deliberately no constraint reason code: constraints are not part of the relation (Section 13.4.4). 13.6. Conformance Class CLC-D *CLC-D* is an optional conformance class stacked on CLC-A. A conforming implementation: * MUST implement Contains (Section 13.4) and the relation's two Section 13.5 reason codes, and pass the CLC-D corpus (Section 13.7); where the implementation also ships a binding profile for a mode-carrying carrier, that profile owns the delegation_mode_not_narrower pre-check (Section 13.4.5); * MUST (rev CLC-1.13) implement AuthorizeWithChain (Section 13.11) and pass the authorize-chain-vectors.json corpus, so the one-call chain check is exercised by the same class that owns containment; Wei Expires 31 March 2027 [Page 57] Internet-Draft CLC-v1 September 2026 * MUST NOT alter any CLC-A verdict, reason code, or the CLC-A corpus — this section is strictly additive; * MUST treat containment as *declared-set comparison*: it declares no consequence about execution lifecycle, time windows after the fact, or post-hoc bounds; where a binding profile cannot establish containment at delegation time, the profile MUST NOT authorize. An implementation claiming CLC-A does *not* claim CLC-D. A delegation profile (a binding profile (Section 13.8), an AIC-JWT DA validator, a certificate-issuance stack) that needs the boundary check SHOULD require CLC-D of the module it delegates to, and MUST NOT substitute intersection (Section 7) for containment. *Implementation status (single-author parity).* Contains is implemented in all three reference implementations (Go: register/ semantics.Contains; Python: aic-capability-demo/clc_semantics.py contains; TypeScript: ts/clc_semantics.ts contains) and mirrors the cases this section pins. Agreement between implementations that share an author is a regression test for this text, not independent validation — the Section 12 honesty rule applies unchanged to CLC-D (see Section 13.7). 13.7. Corpus Because CLC-D is a new relation, its corpus is new and independent of the CLC-A suites (vectors.json / property-cases.json / crosswalk- vectors.json / evidence-vectors.json). The corpus ships as capability/data/_vectors/clc-d/containment-vectors.json (*64* vectors) and a forward-closure property file capability/data/_vectors/clc-d/containment-property-cases.json (*784* cases × 39 shared operations, generated by capability/scripts/gen- contain-property-cases.py), plus a cross-walk corpus capability/data/_vectors/clc-d/containment-crosswalk-vectors.json (*44* vectors) that maps a carrier's native representation (AIC-JWT DA, OAuth RAR, UCAN, delegation chain, and the adjacent agent drafts ATN, AAT, AIP, AAE, AOA, AEGIS) to a grant on each side and asserts Contains (Section 13.9.3). Rev CLC-1.13 adds capability/data/_vectors/clc-d/authorize-chain-vectors.json (*15* vectors) pinning the fused AuthorizeWithChain relation (Section 13.11). The vectors cover: * *identifier coverage* (layer 2): trailing-wildcard coverage, namespace mismatch, depth mismatch, same-length literal mismatch, unsupported_wildcard kept stable, wildcard-requires-a-trailing- segment; Wei Expires 31 March 2027 [Page 58] Internet-Draft CLC-v1 September 2026 * *parameter narrowing* (layer 3): number upper bound at/under/over, enum subset / element-absent / scalar-member, empty child enum under non-empty parent, parent empty set deny-class, key-closure violation in both directions (child omits, child adds), nested object recursion and nested key closure, child {} under bounded parent, child null (layer-1 grammar), unconstrained parent {}; * *constraint non-participation* (Section 13.4.4): a tighter, wider, added, dropped, or differently-identified child constraint, and a child constraint the parent lacks — every one MUST leave the verdict unchanged (all assert contains); * *validity* (layer 1): malformed parent/child identifiers, null params; * *symmetry*: both-directions containment identity, antisymmetry probe pair (contain-040/041), a fully-narrower combined grant. The *delegation-mode lattice* is _not_ part of the language-level corpus: the relation Contains(GP, GC) takes no mode, so a profile that binds a carrier mode (the AIC-JWT DA validator, Section 13.8) exercises it itself. The language corpus therefore ships no mode vectors; a carrier adopting CLC-D MUST add mode vectors to its own profile corpus. The *property* the property corpus checks is _forward closure_: for every (parent P, child C) and every operation o in the shared sample, Contains(P, C) MUST NOT raise, and Contains(P, C) ∧ Entails(C, o) ⟹ Entails(P, o). This is the declared-set consequence that makes a delegation boundary sound, and the reason the Section 13.5 collapse of layer-2 failures into child_exceeds_parent cannot weaken the boundary. On the shipped corpus the Go and Python/TS runs report the same 120 contained pairs and 30576 operation checks with zero violations. The parity bar and the "independence of implementations" honesty rule of Section 12 apply unchanged to CLC-D: until two _independent_ implementations agree, the corpus is evidence that this text is implementable, not that it has been independently interpreted. 13.8. AIC-JWT / AIC Certificate Binding This subsection is a _cross-walk profile of the relation_, not part of the language. At the AIC delegation boundary the parent grant is produced from the principal's authorization and the child grant from the DelegationAuthTBS/AIC-JWT DA capabilities: Wei Expires 31 March 2027 [Page 59] Internet-Draft CLC-v1 September 2026 * *Parent grant* GP: the principal's capability entry (scheme:id params), plus principal-level authorizationConstraints projected as parent constraints, plus the principal's own delegation mode. * *Child grant* GC: the sub-agent's requested capability (Capability.SchemeId:CapabilityId, Parameters), its authorizationConstraints, and its DelegationMode. * *Boundary result*: P_effective = P_principal ∩ C_agent ∩ P_gateway keeps its intersection meaning — intersection determines the _effective_ set; containment (Section 13.4) is the _per-child_ admission predicate that runs before the intersection is composed, on each (parent-capability, child-capability) pair. The child's constraints are *not* compared by containment; they are carried forward by the intersection's union (Section 13.4.4), so the principal's constraints remain in force in P_effective. * A sub-agent that requests a capability the principal did not grant fails at layer 2 (child_exceeds_parent); a sub-agent whose requested params exceed the principal's declared bounds fails at layer 3; a sub-agent that widens the carrier's delegation mode fails the lattice (Section 13.4.5). Binding profiles MUST surface the reason code into their audit trail, and MUST compose the intersection so the principal's constraints stay in force. 13.8.1. Profile contract (for any binding profile) A *binding profile* maps a carrier's native authorization structure to the CLC grants Contains compares (Section 13.9.3). The profile is the carrier's, not the language's (a carrier's field names appear in its own profile, never in the language text). Because every Section 13.9.3 mapping is a profile, this subsection states the obligations a conforming profile carries. It adds no CLC-A or CLC-D verdict and changes no relation. 1. *Resolve the carrier's own inheritance and defaults before mapping.* The language has no inheritance, no default values and no "absent means inherit" rule (Section 13.10.1). A carrier that resolves an absent dimension against an ancestor (AIP Section 4.4) MUST do so in the profile and emit the _resolved_ declared set. Contains is defined over the grants the profile emits, so an unresolved default is a profile defect, not a containment result. 2. *Preserve every identity dimension the carrier treats as identity.* If the carrier treats two artifacts with the same name but different metadata as distinct capabilities (ATN Section 9.1: same id, different schema.digest), the profile MUST carry that Wei Expires 31 March 2027 [Page 60] Internet-Draft CLC-v1 September 2026 metadata into the mapped grant — here, a trailing identifier segment — so a mismatch fails closed. A profile MUST NOT drop an identity dimension and then compare the artifacts as equal. 3. *Residualize semantics the relation cannot see; never drop them silently.* Dimensions the mapped grant has no field for (AEGIS allowed_roles, environment, risk_level; AAE validity) are not compared by Contains. The profile either models them in its own document and enforces them outside the relation, or declares them out of scope — but it MUST NOT report containment as if they had been checked (fail-closed: what the relation cannot see, it does not permit). 4. *Do not invent carrier semantics the carrier does not state.* A profile must not widen what the carrier leaves undefined into an allow. AEGIS's dotted ids are hierarchical, but AEGIS grants capabilities individually and does not define domain-level containment, so the profile does not turn a bare domain into a namespace wildcard (ccx-042 fails closed). 5. *Non-goals (recorded, not prohibitions on carriers).* Three properties are deliberately outside both the relation and the profile contract: * *union of authority sources* — a sub-agent that combines narrow delegated authority with broad independent authority (AEGIS Section 5.1, AOA) composes over a _set_ of grants, which is carrier composition governance, not a per-pair predicate; * *chain-level verification* — Contains is a per-pair predicate, not a transitive closure; a chain check is the profile's iteration of Contains over hops (Section 13.9.3, delegation- chain->clc-v1); * *cross-carrier identity* — CLC defines no equivalence between two carriers' capability names; a profile MAY publish its own mapping, but the language asserts none. 13.9. Related Work and Positioning This subsection is *informative* and carries no requirements. It records why a language-level containment relation is needed at all, how CLC relates to the authorization work already in flight, and what the adoption risks are. Wei Expires 31 March 2027 [Page 61] Internet-Draft CLC-v1 September 2026 13.9.1. The gap CLC fills CLC *does not define a carrier* — it is not a credential format, a transport, or a policy store. It defines the _evaluation semantics_ that carrier-facing work leaves open: a deterministic decision, stable reason codes, and (here) a containment relation. The recurring shortfall in today's landscape is not "how do I carry an authorization" but "how do two independent implementations agree on what a carried authorization _means_, and on whether a delegated one stayed inside its parent". 13.9.2. What containment is for 1. *A standardizable evaluation core.* Structured authorization payloads exist, but their semantics are pinned by each profile's own type vocabulary, so cross-implementation agreement is not guaranteed. CLC supplies the deterministic decision function and the stable reason-code registry those profiles can reference instead of re-inventing. 2. *Verifiable attenuation.* A delegation chain must only narrow. Declaring attenuation is easy; _verifying_ it at the receiving endpoint requires a shared relation. Contains (Section 13.4) plus its reason codes (child_exceeds_parent et al., Section 13.5) turn "only narrows" from an application-layer assumption into a checkable language-level fact. 3. *One model for authorization and evidence.* The core deliberately uses the same identifier and constraint model on the authorization side (the grant) and, prospectively, on the evidence side (the observed action), so an audit trail can be reasoned about with the same relation that authorized it. 13.9.3. How CLC relates to adjacent work The comparison below is by role, not by feature count: the other works are carriers, profiles, or architecture, whereas CLC is the semantic layer. Two principles keep the relationship complementary rather than competitive: 1. *CLC defines evaluation, not carriage.* CLC does not define token formats, trust models, or policy languages. The mapping from a carrier's native authorization structure to a CLC grant is the *carrier profile's responsibility*; CLC only fixes what the mapped grant then _means_. Wei Expires 31 March 2027 [Page 62] Internet-Draft CLC-v1 September 2026 2. *The core already ships consumption mappings.* Appendix A ("Consumption Mapping") lists example consumers (AIC-JWT DA, RAR authorization_details, EMILIA AEB, delegation chains), and capability/data/_vectors/clc-v1/crosswalk-vectors.json pins executable cross-walk cases for the oauth-rar->clc-v1, aic-jwt- da->clc-v1, emilia-aeg->clc-v1, ucan->clc-v1, and delegation- chain->clc-v1 profiles. A carrier adopting CLC-D adds a containment case to that crosswalk rather than a new mapping mechanism. CLC-D ships its own such corpus: capability/data/_vectors/clc-d/containment-crosswalk-vectors.json maps a native representation (AIC-JWT DA, OAuth RAR, UCAN, delegation chain, and the adjacent drafts ATN, AAT, AIP, AAE, AOA, AEGIS) to a grant on each side and asserts Contains — the attenuation analogue of the CLC-A cross-walk. The mappings that are already pinned, and the ones a carrier would add, are: +=====================+===================================+=====================================+============+ |Carrier / native form|Maps to CLC |Relation |Status | +=====================+===================================+=====================================+============+ |AIC-JWT DA |one Grant per entry |Entailment; CLC-D Contains for the |pinned (aic-| |capability[] ({id, | |C_agent ⊆ P_grants boundary |jwt-da->clc-| |params, constraints})| | |v1, ccx- | | | | |001..005, | | | | |ccx-013) | +---------------------+-----------------------------------+-------------------------------------+------------+ |OAuth RAR |one Grant per action (type:action) |Entailment |pinned | |authorization_details| | |(oauth-rar- | |({type, actions[], | | |>clc-v1, | |params}) | | |ccx- | | | | |006..007) | +---------------------+-----------------------------------+-------------------------------------+------------+ |UCAN {with, can} |Grant {with:can} |Entailment |pinned | | | | |(ucan->clc- | | | | |v1, ccx- | | | | |008..009) | +---------------------+-----------------------------------+-------------------------------------+------------+ |EMILIA AEG |Grant {capability_class} |Entailment |pinned | |capability_class | | |(emilia-aeg-| | | | |>clc-v1) | +---------------------+-----------------------------------+-------------------------------------+------------+ |Delegation chain |Intersect of the links |Intersection; CLC-D Contains per hop |pinned | |(per-hop granted | |for attenuation |(delegation-| |sets) | | |chain->clc- | | | | |v1, ccx- | | | | |010..012) | +---------------------+-----------------------------------+-------------------------------------+------------+ Wei Expires 31 March 2027 [Page 63] Internet-Draft CLC-v1 September 2026 |ATN Capability |one Grant per capability: atn/ |CLC-D Contains is the per-capability |pinned (atn-| |Manifest (draft- |manifest- |form of ATN's intersection; ATN's |manifest- | |somoza-dmsc-atn- |v1::[:];|identity rule (same id *and* same |>clc-v1, | |agent-trust- |resource_bounds and numeric |schema digest) is carried by the |ccx- | |negotiation Section |conditions → params |digest path segment; preconditions |014..017, | |5.1/Section 9.1/ | |are a *union* axis (Section 9.2), |ccx- | |Section 9.2) | |never compared |043..044) | +---------------------+-----------------------------------+-------------------------------------+------------+ |Attenuating Agent |one Grant per tool: aat/toolset- |CLC-D Contains for tools(derived) ⊆ |pinned (aat-| |Tokens I4 (draft- |v1:; the argument-constraint |tools(parent) and the per-type |i4->clc-v1, | |niyikiza-oauth- |map → params |constraint subsumption |ccx- | |attenuating-agent- | | |018..023) | |tokens Section 4.5) | | | | +---------------------+-----------------------------------+-------------------------------------+------------+ |AIP attenuation walk |Grant aip/scope-v1:; |CLC-D Contains for the per-dimension |pinned (aip-| |(draft-prakash-aip |budget ceiling → params |narrower-or-equal walk (scope, |attenuation-| |Section 4.4) | |budget) |>clc-v1, | | | | |ccx- | | | | |024..029) | +---------------------+-----------------------------------+-------------------------------------+------------+ |AAE mandates and |Grant aae/mandate-v1:; |CLC-D Contains for AAE's per-element |pinned (aae-| |CONSTRAINTS (draft- |unwrapped CONSTRAINTS values → |"equal to or more restrictive" |constraint- | |kroehl-agentic-trust-|params | |>clc-v1, | |aae Section 2.3/ | | |ccx- | |Section 3) | | |030..034) | +---------------------+-----------------------------------+-------------------------------------+------------+ |AOA operation scope |Grant aoa/scope-v1: |CLC-D Contains for the "scope string |pinned (aoa-| |(draft-liu-agent- | |containment" the AS validates |scope->clc- | |operation- | | |v1, ccx- | |authorization | | |035..037) | |Section 6.2) | | | | +---------------------+-----------------------------------+-------------------------------------+------------+ |AEGIS AIAM-1 |Grant aegis/action- |CLC-D Contains for monotonic |pinned | |delegation (aegis- |v1::; numeric |authority narrowing; |(aegis- | |initiative/aegis- |context bounds → params |allowed_roles/environment/risk_level/|delegation- | |governance, AIAM1- | |scope have no CLC field and are left |>clc-v1, | |DEL-010) | |to the carrier, not compared (see |ccx- | | | |Appendix C) |038..042) | +---------------------+-----------------------------------+-------------------------------------+------------+ |W3C ZCAPs capability |Grant (delegation schema/type → id;|Entailment; CLC-D Contains for |profile to | |document |caveats → params/constraints) |chained delegation |be written | | | | |by the ZCAPs| | | | |adopter | +---------------------+-----------------------------------+-------------------------------------+------------+ Table 12 Wei Expires 31 March 2027 [Page 64] Internet-Draft CLC-v1 September 2026 Two mapping notes the pinned profiles make explicit, because they are places a reader could mistake a carrier's rule for the relation itself: 1. *A carrier's own "contains"/"subset" may name a _constraint type_, not the capability relation.* AAT Section 4.5 defines argument-constraint types named contains and subset (a required- set superset and an allowed-set subset). Those are values _inside_ params; the capability-level relation is still Contains, and the constraint axes compose by union across a chain. The same applies to AAE's allowed_domains and AEGIS's context bounds. 2. *A profile resolves a carrier's inheritance and defaults before mapping, and must not invent semantics the carrier does not state.* AIP resolves an absent dimension to its nearest ancestor (Section 4.4), so the profile maps an absent dimension to _no bound_, not to a bound. AEGIS's dotted ids are hierarchical, but AEGIS grants capabilities individually and does not define domain-level containment, so the profile does *not* widen a bare domain into a namespace wildcard (ccx-042 fails closed). Contains is defined over the _declared_ sets the profile emits: the profile carries the carrier's resolution, and what the carrier leaves undefined the profile leaves undefined — it does not fill the gap with an allow. The full contract is Section 13.8.1. The rows marked _profile to be written_ are placeholders: this document does not guess another draft's field grammar. A carrier profile lands as a MapProfile case plus cross-walk vectors, exactly as the pinned profiles did. +==============+============================+=======================+ |Work | Role | Relationship to CLC | +==============+============================+=======================+ |OAuth Rich | Structured | RAR defines the | |Authorization | authorization_details | _carriage_ of | |Requests (RAR)| carried in the | structured | | | authorization request | authorization; CLC | | | | is a candidate | | | | _evaluation | | | | language_ for the | | | | capabilities RAR | | | | declares. | | | | Attenuating-agent- | | | | token work observes | | | | that RAR expresses a | | | | request but does not | | | | itself define how a | Wei Expires 31 March 2027 [Page 65] Internet-Draft CLC-v1 September 2026 | | | holder derives or | | | | verifies a | | | | _narrower_ token — | | | | the layer Contains | | | | addresses | +--------------+----------------------------+-----------------------+ |OpenID Connect| Agent capability claims in | A profile could | |agent-identity| an ID Token | define how OIDC- | |claims | | delivered | | | | capabilities are | | | | evaluated and how a | | | | delegation chain is | | | | containment-checked | +--------------+----------------------------+-----------------------+ |WIMSE AI | Informational best- | CLC is a candidate | |Identity | practice framework reusing | concrete evaluation | |Management | WIMSE and OAuth; | language for the | |System (draft-| explicitly identifies gaps | authorization step | |ietf-wimse- | rather than defining a | AIMS describes and a | |aims) | capability algebra | candidate answer to | | | | the "capability | | | | containment" gap it | | | | leaves open; the two | | | | are complementary, | | | | not competing | +--------------+----------------------------+-----------------------+ |WIMSE agent | Token format, chain | A carrier-level peer | |delegation | linkage (par_hash), a | that defines _how_ a | |chain ([ASOR],| scope/constraint | narrower token is | |draft-asor- | vocabulary with | carried and | |wimse-agent- | subsumption rules, and an | verified; CLC is the | |delegation- | 8-step offline | carrier-neutral | |chain) | verification algorithm | semantics for the | | | carried in an RFC 9068 JWT | per-hop subset | | | profile | judgement such a | | | | verifier performs. | | | | Contains is the | | | | relation its | | | | DT(child) ⊆ | | | | DT(parent) check | | | | needs, and its | | | | scopes/constraints | | | | map onto CLC's | | | | Grant/params/ | | | | constraints; the two | | | | are complementary, | | | | not competing (the | | | | AAT row makes the | Wei Expires 31 March 2027 [Page 66] Internet-Draft CLC-v1 September 2026 | | | same split one layer | | | | up) | +--------------+----------------------------+-----------------------+ |W3C ZCAPs | Linked-Data-Proof signed | ZCAPs defines the | | | capability documents with | document/carrier; | | | caveats and chaining | CLC can define the | | | | containment relation | | | | over its | | | | capabilities | +--------------+----------------------------+-----------------------+ |UCAN | DID/IPLD authorization | Same split: UCAN is | | | tokens with delegation and | the carrier, CLC the | | | attenuation | semantics | +--------------+----------------------------+-----------------------+ |AEGIS | Hierarchical dotted | Closest in _goal_ | |capability | capability registry, per- | (capability | |registry and | grant scope/constraints, a | declaration + | |AIAM-1 | deterministic decision | deterministic | |delegation | algorithm with verdicts | evaluation + | |([AEGIS], | (allow/constrain/escalate/ | narrowing); differs | |aegis- | deny), and monotonic | in _form_ — AEGIS is | |initiative/ | authority narrowing | a governance | |aegis- | (AIAM1-DEL-010); | architecture with a | |governance) | composition is explicitly | policy/registry | | | _not_ closed under | layer, CLC a | | | transitivity (AIAM1-CAP- | carrier-neutral | | | 011) | decision function | | | | over grants. | | | | Contains is the | | | | relation AEGIS's | | | | monotonic-narrowing | | | | check needs; AEGIS's | | | | non-transitive | | | | composition rule is | | | | compatible (CLC-D | | | | Contains is also | | | | non-transitive: it | | | | is a per-pair | | | | predicate, not a | | | | closure) | +--------------+----------------------------+-----------------------+ |Agent Identity| Delegation-chain token | Overlaps CLC's | |Protocol | with a Datalog policy | entailment/ | |([AIP], draft-| layer and a structural | intersection | |prakash-aip) | attenuation walk (V4) over | _functionally_, but | | | scope, budget, time, | pins a Datalog | | | domains, principal | policy language. | | | | AIP Section 4.4 | Wei Expires 31 March 2027 [Page 67] Internet-Draft CLC-v1 September 2026 | | | makes the same | | | | distinction CLC-D | | | | does — attenuation | | | | is a property of | | | | capability content, | | | | not of the append- | | | | only container — so | | | | CLC can be the | | | | shared deterministic | | | | semantics such a | | | | checker is validated | | | | against | +--------------+----------------------------+-----------------------+ |Agent Trust | Capability Manifest JSON | Overlaps the | |Negotiation | with schema binding, | capability-container | |([ATN], draft-| dimension semantics, and a | target and defines | |somoza-dmsc- | Capability Intersection | an intersection; | |atn-agent- | Algebra (Section 9) with | CLC-D supplies the | |trust- | per-dimension rules | _single-pair | |negotiation) | including preconditions | containment_ | | | union | predicate that runs | | | | before and alongside | | | | that intersection | | | | (Section 13.8). | | | | ATN's ordered | | | | dimension lattices | | | | (effects, | | | | external_calls, …) | | | | are the carrier- | | | | level analogue of | | | | CLC-D's mode lattice | | | | (Section 13.4.5), | | | | which stays out of | | | | the language | | | | relation | +--------------+----------------------------+-----------------------+ |Agent | Operation-proposal/ | Same "no escalation | |Operation | authorization JWTs with a | beyond the original | |Authorization | delegation_chain; the AS | scope" goal; AOA's | |([AOA], draft-| validates that a sub- | scope-string | |liu-agent- | operation is "strictly | containment is | |operation- | narrower in scope" | exactly a carrier | |authorization)| (Section 6.2) via policy | instance of | | | templates, OPA, or scope- | Contains, and AOA's | | | string containment | delegation_chain is | | | | the carrier for the | | | | chain CLC-D reasons | | | | over | Wei Expires 31 March 2027 [Page 68] Internet-Draft CLC-v1 September 2026 +--------------+----------------------------+-----------------------+ |Attenuating | Token chain with a | The closest formal | |Agent Tokens | capability lattice | neighbour at the | |([AAT], draft-| (C(child) ⊆ C(parent), | language level: | |niyikiza- | Section 4.1) and six | C(child) ⊆ C(parent) | |oauth- | attenuation invariants; I4 | is the property | |attenuating- | defines per-type | Contains decides, | |agent-tokens) | constraint subsumption | and AAT's naming of | | | with Decidable/Sound/ | a constraint type | | | Deterministic requirements | contains is a | | | (Section 3.5.1) | caution that the | | | | _relation_ and a | | | | _constraint value_ | | | | must not be | | | | conflated | +--------------+----------------------------+-----------------------+ |Agent | Verifiable Credential | AAE defines the | |Authorization | envelope with | carrier blocks and a | |Envelope | MANDATE/CONSTRAINTS/ | closed, | |([AAE], draft-| VALIDITY blocks and an | deterministic | |kroehl- | explicit "equal to or more | constraint language; | |agentic-trust-| restrictive" definition | CLC-D's | |aae) | per element (Section 3); | params_not_narrower | | | warns of delegation | / | | | amplification | child_exceeds_parent | | | (Section 7.4) | are the stable | | | | reason codes that | | | | make AAE's "strictly | | | | subordinate" check | | | | reportable | +--------------+----------------------------+-----------------------+ |External | Standardizes _how_ an | Orthogonal and | |Verifier | external verifier is | complementary: EVC | |Contract | invoked and returns a | is the verdict | |([EVC], draft-| verdict (allow/deny/denial | _interface_, CLC-D | |kondoju-evc) | codes, fail-closed exit | is the decision | | | semantics) | _semantics_ and its | | | | reason codes. An | | | | EVC implementation | | | | can compute CLC-D's | | | | verdict and surface | | | | the same reason | | | | codes | +--------------+----------------------------+-----------------------+ |Agent-auth | "Agent as workload", | A natural consumer: | |architecture | reusing existing | CLC can be the | |drafts (e.g. | mechanisms; notes that no | evaluation language | |draft-klrc- | single existing policy | such a framework | Wei Expires 31 March 2027 [Page 69] Internet-Draft CLC-v1 September 2026 |aiagent-auth) | engine covers the full | calls into | | | delegation-chain | | | | verification need | | +--------------+----------------------------+-----------------------+ |Dual-identity | Bind agent identity to | Answers _who | |/ attenuating-| owner identity; define how | delegated_ and _how | |token drafts | a holder derives and a | derivation is | |(e.g. draft- | verifier checks a narrower | carried_; CLC | |ni-wimse-ai- | token | answers _what was | |agent- | | delegated and | |identity, AAT | | whether it narrowed_ | |above) | | | +--------------+----------------------------+-----------------------+ |Agent | Interaction and delegation | Capability-based | |interaction/ | flow over capability | sibling; CLC is the | |delegation | systems | evaluation layer | |protocols | | rather than the | |(e.g. AIDP) | | interaction flow | +--------------+----------------------------+-----------------------+ Table 13 The external names above are recorded as context and MUST be re- verified against their current revisions before any submission or citation; this subsection makes no claim about their exact present contents. The mapping rows were checked against these revisions on 2026-09-21: draft-somoza-dmsc-atn-agent-trust-negotiation-00 (Section 5, Section 6, Section 9), draft-niyikiza-oauth-attenuating- agent-tokens-01 (Section 3.5, Section 4), draft-prakash-aip-01 (Section 3.3, Section 4.4), draft-kroehl-agentic-trust-aae-02 (Section 2.3, Section 2.5, Section 3), draft-liu-agent-operation- authorization-02 (Section 3, Section 6), draft-ietf-wimse-aims-00, and the aegis-initiative/aegis-governance repository (AIAM-1 v0.1, AIAM1-DEL-010), and draft-asor-wimse-agent-delegation-chain-01 (Section 3, Section 4, Section 5, Section 6, checked 2026-09-26). Each of these is an individual draft, an informational draft, or a non-IETF repository, with one exception: the WIMSE working group adopted draft-ietf-wimse-aims on 2026-09-09, so it is cited here as a working-group document rather than as an individual draft. The AEGIS material is an informational architecture, not a specification with a formal standing. Wei Expires 31 March 2027 [Page 70] Internet-Draft CLC-v1 September 2026 13.9.4. Where the demand actually is The need for a shared evaluation layer is increasingly explicit in the authorization community: the recurring complaint is not a lack of _carriage_ formats but a lack of agreement on _what a carried authorization means_ and on how a delegation chain is verified to only narrow. The following distinction determines what "demand" should be taken to mean here: * *If demand means "adopted as a WG standard":* uncertain. Several in-flight efforts (AIP, ATN, AOA, AEGIS, above) are attacking the same problem from different angles, and there is no consensus that a _separate_ authorization language is wanted. A standalone individual draft is unlikely to be adopted directly on that basis alone. * *If demand means "used by implementers":* the need is real and immediate. Agent frameworks and enterprise security teams each re-implement an authorization check and each ask the same question — "what may this agent actually do, and did the delegation only narrow?". A small, carrier-neutral, _tested_ decision function plus corpus is directly reusable there. The strategic consequence is that adoption is _earned by use_, not awaited from a standards vote: the corpus and the reference implementations are the contribution, and the standards reference follows if and when downstream implementers cite it. 13.9.5. Adoption risks * *Carrier dependence.* CLC only matters once a carrier (AIC, WIMSE, ZCAPs, UCAN, a RAR profile) binds it. The Section 13.8 AIC-JWT cross-walk is one such binding; without bindings CLC has no reach. * *Competing semantics, not a blank field.* AIP, ATN, AOA, and AEGIS each define (or assume) evaluation semantics of their own. CLC enters a field with several incumbents, so it must be _smaller_ (a decision function, not a policy language or registry), _carrier- neutral_, and _tested_ to be worth citing. * *Ecosystem competition.* A working group could prefer to define its own authorization meta-syntax rather than reference an external language. The response is scope discipline: CLC defines the _evaluation_ and nothing else, and stays small enough to be cited. Wei Expires 31 March 2027 [Page 71] Internet-Draft CLC-v1 September 2026 * *Implementation independence.* The three current implementations share an author, so they are a regression test, not independent validation (Section 12, restated for CLC-D in Section 13.7). Independent implementation remains the gating risk for any standards claim. 13.9.6. Positioning statement CLC is best positioned not as a standalone standard but as the *language specification other standards reference* when they need to define authorization evaluation and delegation narrowing. Concretely: when an AIP-style Datalog checker, an ATN-style condition evaluator, or an AEGIS-style policy evaluator needs a shared, deterministic semantic to validate against or interoperate with, CLC is a candidate. Publishing CLC as the capability language core of a wider agent-authorization architecture (the AIC direction) is exactly that positioning; containment is kept additive so such a reference can be made without disturbing the CLC-A core any adopter already implements. 13.10. Open Issues Section 13.10 records the consciously-deferred gaps surfaced in review; the items already landed as core revisions are marked _closed_, the rest are recorded for later discussion. Items marked _candidate v1.x_ are candidates for the _core language_ to adopt without breaking CLC-A inputs; items under "CLC-D" would extend containment itself. 13.10.1. Parameter model rigidity (closed in CLC-1.10) Landed as Section 6.5, the optional param_bounds field: * *Number*: inclusive min/max intervals and a step multiple rule. * *Enums*: array membership plus min_items/max_items cardinality. * *Optional keys*: an optional marker exempts a declared key from the omission half of layer 7. * *Defaults*: a param_defaults grammar with the precedence explicit > default > absent. The rejected shape is a {min,max} object inside params — it would collide with object recursion (Section 6.2), so the bounds live in a sibling field and no existing grant changes meaning. Wei Expires 31 March 2027 [Page 72] Internet-Draft CLC-v1 September 2026 13.10.2. Consumer obligations for allow_unresolved (closed in CLC-1.11) Section 8.4 delivers residual obligations on an allow_unresolved verdict; Section 8.5 *now defines the consumer's feedback loop* and this item is closed: * Resolve(decision, resolutions, now?) -> Decision, with each unresolved constraint reported as satisfied / violated / unknown; * a propagation rule for partially-evaluated sets (all satisfied → allow, any violated → deny with {type}:violated, remainder → allow_unresolved); * staleness/*TTL* semantics for time:window residuals: with now, the core clock evaluates the window and the discharge horizon is the current segment's end, so a cached allow expires with the window. This went beyond the original "Resolve is core, TTL is profile policy" split: both are now core (Section 8.5). The coarser identity-level consumer gate Discharge (the reference implementations' helper) remains as the satisfied-only case. 13.10.3. Constraints as a union axis (closed in CLC-1.12) This revision makes an explicit design decision: constraints are *not* part of the containment relation (Section 13.4.4). They compose by _union_ (conjunction) along a chain, which Intersect already implements, and no Contains layer reads them. Contains therefore stays the smaller relation — containment over (identifier, parameters) — and the "what does the chain collectively require?" question is answered by the separate derived function ConstraintUnion (Section 7.1, new in CLC-1.12). Folding the union into Contains was considered and rejected: it would make the relation no longer a pure subset on the declared tuple, and a null constraint check would then be able to hide a broken identifier/parameter boundary. A consumer wanting "the child's whole authority is inside the parent's" composes the two: Contains per hop plus ConstraintUnion over the chain. Wei Expires 31 March 2027 [Page 73] Internet-Draft CLC-v1 September 2026 13.10.4. Containment as evidence, not authorization (closed in CLC- 1.13) Section 13.4 keeps containment a declared-set comparison. A delegation _certificate_ binds a child grant; an operation-time authorization still needs the decision function (Section 9). CLC- 1.13 adds the fourth relation AuthorizeWithChain(chain, op) (Section 13.11), the one-call chain check named here: it evaluates Contains per hop and then Authorize against the *intersection* of the chain, so the parent's constraints (a union axis, outside containment) are not lost. It is a CLC-D function, not a core change; a CLC-A implementation is unaffected. 13.11. AuthorizeWithChain (fused chain authorization) Contains is a declared-set comparison and Authorize is an operation- time decision; a delegating consumer that has a chain often wants both in one call. AuthorizeWithChain is that convenience, defined at the CLC-D layer: AuthorizeWithChain(chain, op) → Decision // chain = ordered Grant[], root first 1. An *empty chain fails closed*: deny("absent_source") (Section 7 rule 5). 2. For each adjacent pair (chain[i], chain[i+1]), evaluate Contains (Section 13.4). The first hop that is not contained ends the call with deny(reason), where reason is that hop's Section 13.5 code — child_exceeds_parent or params_not_narrower, the two codes the relation can return; delegation_mode_not_narrower never appears here, because the chain gate calls Contains, which takes no mode argument (Section 13.4.5). This chain gate runs *before* op validation: a broken chain is reported even when the operation is also absent, because the chain is the subject of this function. 3. Otherwise compute the effective chain grant G = Intersect(chain...) (Section 7). Because constraints are outside containment (Section 13.4.4), this step is what brings every ancestor's params *and* constraints into force — authorizing against the leaf grant alone would let an operation pass that violates an ancestor's constraints (the union axis is not in Contains). An Intersect refusal (no_overlap, empty_bound_denies_class, invalid_params_binding) is returned as deny(reason). 4. Return Authorize(G, op) (Section 9) unchanged — allow / allow_unresolved / deny with its own Section 9 reason codes. Wei Expires 31 March 2027 [Page 74] Internet-Draft CLC-v1 September 2026 *Caller obligation.* AuthorizeWithChain evaluates the chain *as presented*: the caller MUST supply the complete, authenticated, root- first chain. The function fetches no missing link, verifies no signature or trust anchor, and detects no truncation or reordering — a verdict over a truncated, reordered or unauthenticated chain is a verdict about the presented sequence, not about the delegation it does not carry (authentication is the carrier's concern, Section 11). This obligation adds no decision rule: the steps above are unchanged by it. AuthorizeWithChain is a *CLC-D function*: it is not part of CLC-A, and an implementation claiming only CLC-A is unaffected. It introduces no new core semantics — it fixes the order of two existing relations and refuses fail-closed at each step. A chain carrying param_bounds is authorizable: step 3's Intersect(chain...) combines the hops' bounds with the Section 6.6 meet, so an ancestor's bound (e.g. max:100) stays in force over a narrower child (e.g. max:50). Because Section 13.4.3 requires the declaration site of every key to match at each hop, a valid chain never presents the cross-site case Section 6.6 refuses. The two-grant form AuthorizeWithChain(parent, child, op) named in Section 13.10.4 is the degenerate case chain = [parent, child]. 13.12. Revision and Governance Containment is folded into this document's revision stream: its changes are recorded in the Revision History and its conformance class CLC-D is declared in Section 12.1 in step with the language revision (this revision is CLC-1.15; CLC-D first appeared in CLC-1.9, folded from EXT-00 rev 0). * A CLC-A input is unaffected by the addition of CLC-D; compatible reading of CLC-A inputs is the floor. * CLC-D adoption is per-implementation: an implementation may claim CLC-A without claiming CLC-D. * The corpus (64 containment vectors, 784 property cases, 44 cross- walk vectors, 15 AuthorizeWithChain vectors) is a draft snapshot; the README in capability/data/_vectors/clc-d/ maintains the live count and the date the snapshot was generated. 14. Security Considerations * *Fail-closed*: undefined/malformed/unknown → deny. * *Deny-when-declared*: empty bounds deny the class. Wei Expires 31 March 2027 [Page 75] Internet-Draft CLC-v1 September 2026 * *No canonical broadening*: segment-boundary, not lexical prefix. * *Composition narrows only*: an intersection removes authority. Whether a _delegated_ grant stays inside its parent's boundary is the containment question Section 13 answers (Contains); intersection alone (Section 7) does not answer it, and a delegation profile MUST NOT substitute one for the other. * *Containment is fail-closed by construction*: every Contains layer defaults to false; a grant pair any layer cannot validate is refused, with no warning-then-allow path (Section 13.4). * *Containment is not a constraint oracle*: Contains does not read constraints (Section 13.4.4). A consumer that uses Contains as its _only_ gate MUST compose the delegation chain's Intersect so the parent's constraints stay in force; otherwise a child that omits a parent constraint could be admitted while the constraint is unenforced. allow_unresolved is orthogonal to containment and MUST NOT be read as a containment result. * *Containment reason-code leakage*: child_exceeds_parent reveals that a child requested an identifier the parent does not cover. A boundary that must not leak policy shape MAY collapse that single code into capability_not_authorized (never params_not_narrower, Section 13.5). * *Mode lattice must be carrier-pinned*: an implementer that maps authorized/representative the wrong way round inverts the boundary; Section 13.8 pins the AIC-JWT ordering, and other carriers MUST pin theirs in the profile that adopts CLC-D. * *Stable reason codes*: same input → same reason across implementations. * *Evidence binding is separate from native verification*: Match checks content correlation; native verification is the consumer's responsibility. * *Parsing divergence must not change the decision*: params are normalized at the input boundary per Section 6.2 (JCS serialization, duplicate keys, non-finite/over-precision numbers, size/depth caps). A consumer that decodes into a re-orderable map and re-encodes loses duplicate keys and cannot represent non- finite numbers; two such consumers would reach different verdicts on the same raw input. Decisions are made on the boundary- validated form, not on a lossy re-serialization. Wei Expires 31 March 2027 [Page 76] Internet-Draft CLC-v1 September 2026 * *Recognized-but-unevaluated is not silent acceptance*: a constraint the core recognizes but cannot evaluate MUST appear in the decision's unresolved field — never dropped (Section 8.4). The consumer must evaluate or confirm each such constraint before acting, otherwise it MUST deny (AAC Section 6.6). * *A core-clock discharge is time-bounded*: when Resolve (Section 8.5) evaluates a time:window obligation with a supplied now, the discharge is valid only for the segment containing now. A consumer MUST NOT cache the resulting allow past that segment's end — it re-invokes Resolve with a current now before acting, or derives the horizon from the segment end. Caching a clock-based allow turns a window into an unbounded permit. * *Reason-code detail suffix is diagnostic-only*: everything after the first : (e.g. the offending param name) MUST NOT change the verdict and MUST NOT be relied upon for decisions. Consumers match on the code prefix before the : (Section 9.2). * *Revision mismatch is fail-closed*: an incompatible language revision (Section 12.1) yields deny("unsupported_language_revision") resolved before any layer — never a silent downgrade or best-effort re-interpretation. * *Resource exhaustion is bounded at the input boundary*: the 512-byte serialized-size cap and the depth-32 nesting cap (Section 6.2 step 4) apply to raw_params as much as to every other input, keeping recursive evaluators safe from deep-nesting and oversized-params blowup. 15. IANA Considerations This document requests no IANA actions. Constraint types (max_rows, time, network) and reason codes are defined by this document as fixed sets. Should this work be adopted by a working group, that group may wish to consider whether either set warrants a registry; this revision does not propose one. The containment relation (Section 13) registers three additional reason codes (child_exceeds_parent, params_not_narrower, delegation_mode_not_narrower — the last produced by the binding profile's delegation-mode pre-check, Section 13.4.5, never by the relation itself); they are part of the same fixed set, and no constraint reason code is defined for containment because constraints are outside the relation (Section 13.4.4). Wei Expires 31 March 2027 [Page 77] Internet-Draft CLC-v1 September 2026 16. Privacy Considerations The language itself transports and stores nothing. Privacy exposure comes from what carriers put into it and from what evaluators report: * Capability identifiers and parameter values describe policy. They can reveal organizational structure, service topology, network ranges (network constraints), working hours (time windows), tenant names, or purposes. Deployments should treat grants as policy- confidential material. * Distinct reason codes reveal the shape of a grant: the difference between params_missing, undeclared_param and not_in_enum tells an observer what the grant constrains. Where the requester is untrusted, a consumer should consider collapsing reason codes at the boundary, as this specification already does for identifier- level failures (Section 9.1). * Parameter values may carry personal data if a scheme defines them that way. Scheme authors should avoid personal identifiers as parameter names or values. * Residual obligations (unresolved, Section 8.4) and any audit record built from decisions can persist policy and usage information; retention is the carrier's responsibility (Section 11). * The reference corpus published with this document is synthetic and contains no personal data. * Containment reasons (Section 13) are emitted to the child's requestor at the delegation step, not to end-users, and the child receives the failure code, not the parent's declared bounds. Where bounds themselves are sensitive (e.g. network/scope declarations), a profile SHOULD log codes, not values. 17. References 17.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Wei Expires 31 March 2027 [Page 78] Internet-Draft CLC-v1 September 2026 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . 17.2. Informative References [AIC-JWT] Wei, J., "AI Agent Identity Certificate (AIC) JSON Web Token Profile", September 2026, . [EMILIA-AEB] Schrock, I., "The Action Evidence Boundary for Consequential Agent Effects", Work in Progress, Internet- Draft, draft-schrock-action-evidence-boundary-07, September 2026, . [AEC] Schrock, I., "Authorization Evidence Chains: Composing Heterogeneous Agent-Action Evidence (EP-AEC)", Work in Progress, Internet-Draft, draft-schrock-ep-authorization- evidence-chain-06, September 2026, . [BCR] Schrock, I., "Bounded Capability Receipts and Durable Spend Control for Agent Actions", Work in Progress, Internet-Draft, draft-schrock-ep-bounded-capability- receipts-06, September 2026, . [PAP] Baur, T., "Principal Agent Protocol (PAP)", Work in Progress, Internet-Draft, draft-baur-pap-02, June 2026, . Wei Expires 31 March 2027 [Page 79] Internet-Draft CLC-v1 September 2026 [ASOR] Asor, R., "Verifiable Attenuated Delegation for AI Agent Chains", Work in Progress, Internet-Draft, draft-asor- wimse-agent-delegation-chain-01, September 2026, . [RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, . [CAID] Schrock, I., "The Canonical Action Identifier (CAID)", Work in Progress, Internet-Draft, draft-schrock-canonical- action-identifier-03, September 2026, . [ATN] "Agent Trust Negotiation", n.d., . [AAT] "OAuth 2.0 Attenuating Agent Tokens", n.d., . [AIP] "Agent Identity Protocol", n.d., . [AAE] "Agentic Trust Agent Authorization Envelope", n.d., . [AOA] "Agent Operation Authorization", n.d., . [EVC] "External Verifier Contract", n.d., . [CLC-CORPUS] Wei, J., "Capability Language Core -- conformance corpus, schemas and working documents", September 2026, . [AEGIS] "AEGIS Governance (AIAM-1 v0.1)", n.d., . Wei Expires 31 March 2027 [Page 80] Internet-Draft CLC-v1 September 2026 Appendix A. Consumption Mapping The rows below are examples of consumers of this shared vocabulary, not required profiles: conformance to CLC-A does not depend on any of them. RAR authorization details [RFC9396] are one such carrier; CLC is a candidate evaluation language for the capabilities they declare. Wei Expires 31 March 2027 [Page 81] Internet-Draft CLC-v1 September 2026 +=====================+=================+============+===========+================+ |Consumer |Grammar |Binding |Verdict |Notes | +=====================+=================+============+===========+================+ |AIC-JWT DA |capability[].id |Entailment |Decision |AIC-JWT | | | |(Section |(Section 9)|Section 5 | | | |6.1) | |binding | +---------------------+-----------------+------------+-----------+----------------+ |EMILIA AEB |AEG |Match |SATISFIED |AEB Section 3 | | |capability_class |(Section |(Section |decision levels | | | |6.4) + |10) + |(VERIFIED/MATCH/| | | |Entailment |Decision |SATISFIED) + | | | |(Section |(Section 9)|Section 5.1 | | | |6.1) | |ObservedAction +| | | | | |Section 7 AEC | | | | | |slots; a | | | | | |VERIFIED | | | | | |authorization | | | | | |artifact carries| | | | | |the Grant | +---------------------+-----------------+------------+-----------+----------------+ |RAR |type="capability"|Entailment |Decision |[RFC9396] format| |authorization_details| |(Section |(Section 9)| | | | |6.1) | | | +---------------------+-----------------+------------+-----------+----------------+ |Delegation chain |each hop's |Intersection|Decision |intersection | | |declared set |(Section 7) |(Section 9)|over declared | | | | | |sets only; a hop| | | | | |that must stay | | | | | |inside its | | | | | |parent is | | | | | |checked with | | | | | |Containment | | | | | |(Section 13) | +---------------------+-----------------+------------+-----------+----------------+ |Delegation |parent and child |Contains |Containment|per-hop child ⊆ | |containment |boundaries |(Section 13)|verdict |parent; carrier | | | | |(Section |vocabularies and| | | | |13) |reason-code | | | | | |mapping in | | | | | |Appendix C | +---------------------+-----------------+------------+-----------+----------------+ Table 14 Wei Expires 31 March 2027 [Page 82] Internet-Draft CLC-v1 September 2026 Appendix B. Reference Vectors *Grouping vs kind mapping*: The appendix groups vectors by semantic category (B.1–B.6). The machine-readable vectors.json uses a kind field that collates these groups differently: kind=entail (47) covers B.2 (8), the 35 params vectors that sit under kind=entail (B.3's 39 rows minus params-028/-029/-034/-036, which are kind=decide), and the four scheme stress-test entail vectors (clinical-001/-002, payments- 001, data-002); kind=decide (50) covers the B.5 rows below (34), the seven combined decision vectors, payments-002 and data-001, the four params boundary decisions that sit under kind=decide (params-028/- 029/-034/-036, all four also listed in B.3) and the three nested key- closure vectors (nested-001/-002/-003); kind=intersect (17) covers B.4 (10), the four combined vectors that call the intersect function (combined-004/-005/-008/-011) and the three CLC-1.15 cross-type audit vectors (intersect-011/-012/-013, outside the B.1–B.6 tables); kind=syntax (9) is exactly B.1. These counts are reproducible from the corpus itself: every vector in vectors.json carries its kind, so the mapping is machine-checkable rather than maintained by hand. B.1. Syntax (9 vectors) +==+=====================+=============================+===========+ |# |Input | Expected |Derivation | +==+=====================+=============================+===========+ |S1|std/database- | valid |literal | | |v1:query:SELECT | |identifier | +--+---------------------+-----------------------------+-----------+ |S2|std/database- | valid |trailing | | |v1:query:* | |wildcard | +--+---------------------+-----------------------------+-----------+ |S3|*:query:SELECT | deny |bare * | | | | |illegal | +--+---------------------+-----------------------------+-----------+ |S4|std/database- | deny |partial | | |v1:query:SEL* | |segment | | | | |wildcard | +--+---------------------+-----------------------------+-----------+ |S5|std/database- | deny |alternation| | |v1:query:{read,write}| |not v1 | +--+---------------------+-----------------------------+-----------+ |S6|std/database- | deny |character | | |v1:query:[a-z] | |class not | | | | |v1 | +--+---------------------+-----------------------------+-----------+ |S7|database:query | deny(invalid_capability_id) |Section 3 | | | | |scheme | | | | |grammar: no| Wei Expires 31 March 2027 [Page 83] Internet-Draft CLC-v1 September 2026 | | | |vendor "/" | | | | |product | | | | |"-v" major | | | | |(the spec's| | | | |own | | | | |counter- | | | | |example) | +--+---------------------+-----------------------------+-----------+ |S8|bad:op | deny(invalid_capability_id) |Section 3 | | | | |scheme | | | | |grammar: | | | | |scheme bad | | | | |does not | | | | |match | | | | |vendor/ | | | | |product-vN | | | | |(snips the | | | | |lax-intake | | | | |hole) | +--+---------------------+-----------------------------+-----------+ |S9|std/data- | valid |multi- | | |v1:fetch:item:42 | |segment | | | | |action + | | | | |conforming | | | | |scheme | | | | |(positive | | | | |boundary) | +--+---------------------+-----------------------------+-----------+ Table 15 B.2. Entailment (8 vectors) +==+=================+======================+========+==============+ |# | Grant | Operation |Expected|Derivation | +==+=================+======================+========+==============+ |E1| std/database- | std/database- |allow |literal match | | | v1:query:SELECT | v1:query:SELECT | | | +--+-----------------+----------------------+--------+--------------+ |E2| std/database- | std/database- |allow |trailing | | | v1:query:* | v1:query:SELECT | |wildcard | +--+-----------------+----------------------+--------+--------------+ |E3| std/database- | std/database- |allow |wildcard | | | v1:query:* | v1:query:SELECT:deep | |multi-segment | +--+-----------------+----------------------+--------+--------------+ |E4| std/database- | std/database- |deny |different | | | v1:query:* | v1:admin:DDL | |namespace | +--+-----------------+----------------------+--------+--------------+ Wei Expires 31 March 2027 [Page 84] Internet-Draft CLC-v1 September 2026 |E5| std/database- | std/database- |deny |no trailing | | | v1:query:* | v1:query | |segment | +--+-----------------+----------------------+--------+--------------+ |E6| std/database- | std/database- |deny |literal | | | v1:query:SELECT | v1:query:INSERT | |mismatch | +--+-----------------+----------------------+--------+--------------+ |E7| std/database- | std/database- |deny |class- | | | v1:* | v1:query:SELECT | |position | | | | | |(product- | | | | | |segment) | | | | | |wildcard is | | | | | |v1-forbidden: | | | | | |only a | | | | | |trailing | | | | | |action | | | | | |segment may | | | | | |be * | | | | | |(Section 3; | | | | | |Section 9.1 | | | | | |layer 3) | +--+-----------------+----------------------+--------+--------------+ |E8| std/database- | std/database- |deny |same class- | | | v1:* | v1:admin:DDL | |position | | | | | |wildcard; the | | | | | |v1-forbidden | | | | | |shape denies | | | | | |regardless of | | | | | |the action it | | | | | |faces | | | | | |(Section 3; | | | | | |Section 9.1 | | | | | |layer 3) | +--+-----------------+----------------------+--------+--------------+ Table 16 B.3. Params (39 vectors) +===+===============================+===============================+==================================+=====================+ |# |Grant |Operation |Expected |Derivation | +===+===============================+===============================+==================================+=====================+ |P1 |{"limit":100} |{"limit":50} |allow |50 ≤ 100 | +---+-------------------------------+-------------------------------+----------------------------------+---------------------+ |P2 |{"limit":100} |{"limit":150} |deny |150 > 100 | +---+-------------------------------+-------------------------------+----------------------------------+---------------------+ |P3 |{"tables":["a","b"]} |{"tables":["a"]} |allow |subset | +---+-------------------------------+-------------------------------+----------------------------------+---------------------+ |P4 |{"tables":["a"]} |{"tables":["a","b"]} |deny |"b" absent | Wei Expires 31 March 2027 [Page 85] Internet-Draft CLC-v1 September 2026 | | | | |(not_in_enum) | +---+-------------------------------+-------------------------------+----------------------------------+---------------------+ |P5 |{"columns":{"t":["id"]}} |{"columns":{"t":["id","name"]}}|deny |"name" absent | | | | | |(not_in_enum) | +---+-------------------------------+-------------------------------+----------------------------------+---------------------+ |P6 |{} |{"limit":50} |allow |unconstrained ({} ≡ | | | | | |absent; the literal | | | | | |{} is pinned by | | | | | |decide-028, | | | | | |params-006 pins the | | | | | |absent form) | +---+-------------------------------+-------------------------------+----------------------------------+---------------------+ |P7 |{"tables":[]} |{"tables":["a"]} |deny |explicit empty bound | | | | | |denies the class | +---+-------------------------------+-------------------------------+----------------------------------+---------------------+ |P8 |{"limit":100} |{"limit":null} |deny |null invalid in v1 | | | | | |(invalid_params_null)| +---+-------------------------------+-------------------------------+----------------------------------+---------------------+ |P9 |{"station":[1,2,3]} |{"station":2} |allow |scalar member of | | | | | |array set | +---+-------------------------------+-------------------------------+----------------------------------+---------------------+ |P10|{"station":[1,2,3]} |{"station":9} |deny |9 ∉ allowed set | | | | | |(not_in_enum) | +---+-------------------------------+-------------------------------+----------------------------------+---------------------+ |P11|{"station":[1,3]} |{"station":[1,3]} |allow |array, every element | | | | | |a member | +---+-------------------------------+-------------------------------+----------------------------------+---------------------+ |P12|{"station":[1,3]} |{"station":[1,2,3]} |deny |2 ∉ allowed set | | | | | |(not_in_enum) | +---+-------------------------------+-------------------------------+----------------------------------+---------------------+ |P13|{"station":[1],"speed":0.3} |{"station":1,"speed":0.25} |allow |member + number bound| | | | | |unaffected | +---+-------------------------------+-------------------------------+----------------------------------+---------------------+ |P14|{"station":[3]} |{"station":2} |deny |categorical: granting| | | | | |3 does not cover 1/2 | | | | | |(not_in_enum) | +---+-------------------------------+-------------------------------+----------------------------------+---------------------+ |P15|{"columns":{"t":["id","name"]}}|{"columns":{"t":["id"]}} |allow |object recursion: | | | | | |request element is a | | | | | |member of the granted| | | | | |set (Section 6.2 | | | | | |v1.1) | +---+-------------------------------+-------------------------------+----------------------------------+---------------------+ |P16|{"limit":100} |raw {"limit":100,"limit":150} |deny(invalid_params_duplicate_key)|duplicate JSON key | | | | | |rejected at input | | | | | |normalization | | | | | |(Section 6.2 step 2) | +---+-------------------------------+-------------------------------+----------------------------------+---------------------+ Wei Expires 31 March 2027 [Page 86] Internet-Draft CLC-v1 September 2026 |P17|{"limit":100} |raw {"limit":1e400} |deny(invalid_params_number) |non-finite number | | | | | |literal (Section 6.2 | | | | | |step 3) | +---+-------------------------------+-------------------------------+----------------------------------+---------------------+ |P18|{"s":"x"} |raw {"s":"<600 chars>"} |deny(invalid_params_size) |serialized form > 512| | | | | |B (Section 6.2 step | | | | | |4) | +---+-------------------------------+-------------------------------+----------------------------------+---------------------+ |P19|{"d":0} |raw depth-33 object |deny(invalid_params_size) |nesting beyond depth | | | | | |32 (Section 6.2 step | | | | | |4) | +---+-------------------------------+-------------------------------+----------------------------------+---------------------+ |P20|{"s":"x"} |raw {"s":"<512 B>"} |allow |serialized = exactly | | | | | |the 512 B limit (≤); | | | | | |positive boundary of | | | | | |P18 (Section 6.2 step| | | | | |4) | +---+-------------------------------+-------------------------------+----------------------------------+---------------------+ |P21|{"d":0} |raw depth-32 object |allow |depth exactly the 32 | | | | | |limit (≤); positive | | | | | |boundary of P19 | | | | | |(Section 6.2 step 4) | +---+-------------------------------+-------------------------------+----------------------------------+---------------------+ |P22|{"flag":true} |{"flag":1} |deny(params_exceed_grant) |boolean is exact and | | | | | |is NOT a number: 1 | | | | | |must not satisfy a | | | | | |granted true (params-| | | | | |022) | +---+-------------------------------+-------------------------------+----------------------------------+---------------------+ |P23|{"flag":true} |{"flag":true} |allow |positive side of P22 | | | | | |(params-023) | +---+-------------------------------+-------------------------------+----------------------------------+---------------------+ |P24|{"x":null} |(no params) |deny(invalid_params_null) |layer 6 (null) | | | | | |precedes layer 7 | | | | | |(presence) (params- | | | | | |024) | +---+-------------------------------+-------------------------------+----------------------------------+---------------------+ |P25|{"s":"x"} |raw {"s":"<512 B>","s":"dup"} |deny(invalid_params_size) |multi-fault: size (4)| | | | | |precedes duplicate | | | | | |keys (2) (params-025)| +---+-------------------------------+-------------------------------+----------------------------------+---------------------+ |P26|{"s":"x"} |raw {"n":1e400,"s":"<512 B>"} |deny(invalid_params_size) |multi-fault: size (4)| | | | | |precedes number shape| | | | | |(3) (params-026) | +---+-------------------------------+-------------------------------+----------------------------------+---------------------+ |P27|{"a":1} |raw {"a":1,"a":2,"n":1e400} |deny(invalid_params_duplicate_key)|multi-fault under the| | | | | |size limit: duplicate| | | | | |keys (2) precede | Wei Expires 31 March 2027 [Page 87] Internet-Draft CLC-v1 September 2026 | | | | |number shape (3) | | | | | |(params-027) | +---+-------------------------------+-------------------------------+----------------------------------+---------------------+ |P28|{} |raw {"n":1e-6,"s":"<494 a>"} |deny(invalid_params_size) |the received text is | | | | | |511 octets but the | | | | | |JCS form writes 1e-6 | | | | | |as 0.000001, so the | | | | | |Section 6.2 step 4 | | | | | |size is 515 (params- | | | | | |033) | +---+-------------------------------+-------------------------------+----------------------------------+---------------------+ |P29|{} |{"n":1e-6,"s":"<494 a>"} |deny(invalid_params_size) |decoded counterpart | | | |(decoded) | |of P28: both | | | | | |boundaries agree | | | | | |(params-034) | +---+-------------------------------+-------------------------------+----------------------------------+---------------------+ |P30|{} |raw {"n":1.0,"s":"<498 a>"} |allow |the received text is | | | | | |514 octets but the | | | | | |JCS form writes 1.0 | | | | | |as 1, so the size is | | | | | |512 and inside the | | | | | |cap (params-035) | +---+-------------------------------+-------------------------------+----------------------------------+---------------------+ |P31|{} |{"n":1.0,"s":"<498 a>"} |allow |decoded counterpart | | | |(decoded) | |of P30: a raw check | | | | | |counting the received| | | | | |token would refuse it| | | | | |(params-036) | +---+-------------------------------+-------------------------------+----------------------------------+---------------------+ |P32|{} |raw {"s":"<100×U+1F600>"} |allow |100 literal astral | | | | | |characters are 408 | | | | | |JCS octets; counting | | | | | |UTF-16 code units | | | | | |would double the | | | | | |count and refuse | | | | | |(params-037) | +---+-------------------------------+-------------------------------+----------------------------------+---------------------+ |P33|{} |raw {"s":"<100×\ud83d\ude00>"} |allow |escaped spelling of | | | | | |P32: literal and | | | | | |escaped forms of one | | | | | |string MUST reach the| | | | | |same verdict and the | | | | | |same size (params- | | | | | |038) | +---+-------------------------------+-------------------------------+----------------------------------+---------------------+ |P34|{} |raw {"s":"a\nb"} (literal |deny(invalid_params_number) |a literal control | | | |U+000A) | |character is not | | | | | |valid JSON text; Go | Wei Expires 31 March 2027 [Page 88] Internet-Draft CLC-v1 September 2026 | | | | |and Python refused it| | | | | |already (params-039) | +---+-------------------------------+-------------------------------+----------------------------------+---------------------+ |P35|{} |{"x":"<260×é>"} (decoded) |deny(invalid_params_size) |260 U+00E9 code | | | | | |points serialize to | | | | | |528 JCS octets > 512;| | | | | |non-ASCII sizes are | | | | | |measured on the | | | | | |canonical UTF-8 form,| | | | | |never in code points | | | | | |or UTF-16 units | | | | | |(params-028, rev CLC-| | | | | |1.4) | +---+-------------------------------+-------------------------------+----------------------------------+---------------------+ |P36|{} |{"x":"<251×é>"} (decoded) |allow |251 U+00E9 serialize | | | | | |to 510 octets ≤ 512; | | | | | |the positive side of | | | | | |P35 (params-029, rev | | | | | |CLC-1.4) | +---+-------------------------------+-------------------------------+----------------------------------+---------------------+ |P37|{"s":"x"} |raw {"s":"<251×\u00e9 |allow |the same 510-octet | | | |escapes>"} | |string spelled with | | | | | |\u00e9 escapes | | | | | |reaches the same | | | | | |verdict and the same | | | | | |size as the literal | | | | | |form of P36 (params- | | | | | |030, rev CLC-1.4) | +---+-------------------------------+-------------------------------+----------------------------------+---------------------+ |P38|{"limit":100} |raw {"s":"\ud800"} |deny(invalid_params_number) |a lone surrogate | | | | | |escape is not valid | | | | | |Unicode: refused at | | | | | |the raw boundary, | | | | | |never repaired to | | | | | |U+FFFD (RFC 8785 | | | | | |Section 3.2.2.2; | | | | | |Section 6.2 step 2; | | | | | |params-031, rev CLC- | | | | | |1.6) | +---+-------------------------------+-------------------------------+----------------------------------+---------------------+ |P39|{} |raw {"s":"\ud83d\ude02"} |allow |a valid surrogate | | | | | |pair is one character| | | | | |(U+1F602, four UTF-8 | | | | | |octets) and counts as| | | | | |such under the size | | | | | |rule (params-032, rev| | | | | |CLC-1.6) | +---+-------------------------------+-------------------------------+----------------------------------+---------------------+ Wei Expires 31 March 2027 [Page 89] Internet-Draft CLC-v1 September 2026 Table 17 B.4. Intersection (10 vectors) Shorthand: params shown compact; constraints use colon notation. +===+====================+=============================================+===================+==========+ |# |Source A |Source B |Expected |Derivation| +===+====================+=============================================+===================+==========+ |I1 |{"tables":["a","b"]}|{"tables":["a"]} |{"tables":["a"]} |overlap | +---+--------------------+---------------------------------------------+-------------------+----------+ |I2 |{"tables":["a"]} |{"tables":[]} |deny |deny-when-| | | | | |declared | +---+--------------------+---------------------------------------------+-------------------+----------+ |I3 |(unconstrained) |(no grant) |deny |absent | | | | | |source | +---+--------------------+---------------------------------------------+-------------------+----------+ |I4 |{"limit":100} |{"limit":50} |{"limit":50} |tighter | | | | | |bound | +---+--------------------+---------------------------------------------+-------------------+----------+ |I5 |(unconstrained) |constraint |recognized, not |constraint| | | |time:window:[{"start":"00:00","end":"01:00"}]|evaluated → |added | | | | |unresolved carried | | | | | |on allow_unresolved| | | | | |verdict | | +---+--------------------+---------------------------------------------+-------------------+----------+ |I6 |{"tables":["a"]} |{"tables":["b"]} |deny |no overlap| +---+--------------------+---------------------------------------------+-------------------+----------+ |I7 |(no source / null) |— |deny(absent_source)|zero | | | | | |sources: | | | | | |fail- | | | | | |closed | | | | | |(Section 7| | | | | |rule 5) | +---+--------------------+---------------------------------------------+-------------------+----------+ |I8 |{"limit":50} |{} |{"limit":50} |empty | | | | | |params | | | | | |declares | | | | | |no | | | | | |constraint| | | | | |→ bound | | | | | |preserved | | | | | |(bounded | | | | | |then | | | | | |empty, | | | | | |Section 7 | | | | | |rule 6) | +---+--------------------+---------------------------------------------+-------------------+----------+ Wei Expires 31 March 2027 [Page 90] Internet-Draft CLC-v1 September 2026 |I9 |{} |{"limit":50} |{"limit":50} |source | | | | | |order must| | | | | |not matter| | | | | |(empty | | | | | |then | | | | | |bounded, | | | | | |Section 7 | | | | | |rule 6) | +---+--------------------+---------------------------------------------+-------------------+----------+ |I10|{}, id query:SELECT |{}, id query:* |{} |narrower | | | | | |identifier| | | | | |wins; | | | | | |identifier| | | | | |comparison| | | | | |is params-| | | | | |free | | | | | |(Section 7| | | | | |rule 2) | +---+--------------------+---------------------------------------------+-------------------+----------+ Table 18 B.5. Decision (34 vectors) +===+==================+=====================================+=====================+ |# |Scenario |Expected |Derivation | +===+==================+=====================================+=====================+ |D1 |valid grant, valid|allow |all checks pass | | |op, constraints | | | | |pass | | | +---+------------------+-------------------------------------+---------------------+ |D2 |no matching grant |deny("capability_not_authorized") |fail-closed | +---+------------------+-------------------------------------+---------------------+ |D3 |unknown constraint|deny("unknown_constraint") |fail-closed | | |type | | | +---+------------------+-------------------------------------+---------------------+ |D4 |malformed |deny("invalid_capability_id") |input validation | | |capability_id | | | +---+------------------+-------------------------------------+---------------------+ |D5 |same input twice |same output |deterministic | +---+------------------+-------------------------------------+---------------------+ |D6 |constraint |deny("{type}:violated") |constraint fail | | |violation | | | +---+------------------+-------------------------------------+---------------------+ |D7 |grant bounds a |deny("params_missing") |Section 6.3 step 4 | | |param, operation | |fail-closed | | |omits it | | | +---+------------------+-------------------------------------+---------------------+ Wei Expires 31 March 2027 [Page 91] Internet-Draft CLC-v1 September 2026 |D8 |operation param |deny("invalid_params_null") |Section 6.2 null | | |value is null | |rule; may carry : | | | | | detail | | | | |(Section 9.2) | +---+------------------+-------------------------------------+---------------------+ |D9 |bounded grant, |deny("params_missing") |Section 6.3 step 4 | | |operation has *no | |fail-closed | | |params field at | | | | |all* | | | +---+------------------+-------------------------------------+---------------------+ |D10|Authorize called |deny("capability_not_authorized") |Section 9 fail- | | |with an *absent/ | |closed, no exception | | |empty grant* | | | +---+------------------+-------------------------------------+---------------------+ |D11|input declares |allow |same major, 1.0 ≤ 1.3| | |CLC-1.0 against a | |→ compatible | | |CLC-1.3 | |(Section 12.1) | | |implementation | | | +---+------------------+-------------------------------------+---------------------+ |D12|input declares |deny("unsupported_language_revision")|different major → | | |CLC-2.0 against a | |fail-closed | | |CLC-1.3 | |(Section 12.1) | | |implementation | | | +---+------------------+-------------------------------------+---------------------+ |D13|operation carries |deny("undeclared_param") |Section 6.2 key | | |a param key the | |closure, Section 9.1 | | |grant does not | |layer 7 request side | | |declare (key | | | | |closure) | | | +---+------------------+-------------------------------------+---------------------+ |D14|both a missing |deny("params_missing") |layer-7 order: | | |grant key and an | |missing before | | |undeclared request| |undeclared | | |key | | | +---+------------------+-------------------------------------+---------------------+ |D15|absent/empty grant|deny("capability_not_authorized") |Section 9.1 pre-check| | |*and* absent | |resolves before any | | |operation | |layer, incl. the | | | | |absent-operation case| +---+------------------+-------------------------------------+---------------------+ |D16|grant valid, |deny("missing_capability_id") |layer 1 | | |operation has *no | | | | |id* | | | +---+------------------+-------------------------------------+---------------------+ |D17|grant carries |deny("invalid_constraint") |a single segment | | |time:window with a| |crossing midnight is | | |*cross-midnight | |out of grammar | | |single segment* | |(decide-019) — a | Wei Expires 31 March 2027 [Page 92] Internet-Draft CLC-v1 September 2026 | |(22:00→06:00) | |crossing must be | | | | |split into two | | | | |segments | +---+------------------+-------------------------------------+---------------------+ |D18|grant carries |allow_unresolved, |recognized, no core | | |network:cidr |unresolved:[] |evaluator → residual | | |(array form, IPv4/| |obligation | | |IPv6) | |(Section 8.4; decide-| | | | |020) | +---+------------------+-------------------------------------+---------------------+ |D19|time:window scalar|deny("invalid_constraint") |out of Section 8.1 | | |second form | |value grammar | | |(window:3600) | |(decide-021) | +---+------------------+-------------------------------------+---------------------+ |D20|network:cidr |deny("invalid_constraint") |out of Section 8.1 | | |without prefix | |value grammar | | |length | |(decide-022) | +---+------------------+-------------------------------------+---------------------+ |D21|max_rows |deny("max_rows:violated") |fail-closed op-absent| | |constraint, op | |(decide-023) | | |carries *no* | | | | |max_rows value | | | +---+------------------+-------------------------------------+---------------------+ |D22|time:window split-|allow_unresolved, |cross-midnight split-| | |form multi-segment|unresolved:[] |segment grammar | | |window | |(decide-024) | | |(22:00→00:00 + | | | | |00:00→06:00) | | | +---+------------------+-------------------------------------+---------------------+ |D23|op scheme bad |deny("invalid_capability_id") |Section 3 scheme | | |passes no vendor/ | |grammar (decide-025) | | |product-vN | | | +---+------------------+-------------------------------------+---------------------+ |D24|grant id bad:op |deny("capability_not_authorized") |Section 3 fails in | | |against a valid | |Entails; ID-level | | |operation | |reason collapses | | | | |(decide-026) | +---+------------------+-------------------------------------+---------------------+ |D25|max_rows exactly |allow |violation is strict | | |at the bound | |>; core-evaluated so | | | | |no unresolved | | | | |(decide-027) | +---+------------------+-------------------------------------+---------------------+ |D26|grant params:{}, |allow |{} ≡ absent (decide- | | |op any params → | |028, Section 9.1) | | |unconstrained | | | +---+------------------+-------------------------------------+---------------------+ |D27|multi-grant: G1 |allow |any-one-covers | Wei Expires 31 March 2027 [Page 93] Internet-Draft CLC-v1 September 2026 | |{limit:10} denies,| |authorizes (decide- | | |G2 {limit:100} | |029, Section 9.1) | | |allows | | | +---+------------------+-------------------------------------+---------------------+ |D28|multi-grant: G1 |deny("params_exceed_grant") |all covering grants | | |{limit:10} + G2 | |reject → first reason| | |{limit:6}, op | |in canonical order | | |{limit:50} | |(decide-030, | | | | |Section 9.1) | +---+------------------+-------------------------------------+---------------------+ |D29|multi-grant |allow_unresolved, unresolved:[both] |residual obligations | | |allow_unresolved: | |union across covering| | |G1 network:cidr + | |grants (decide-035, | | |G2 time:window | |Section 9.1/ | | | | |Section 8.4) | +---+------------------+-------------------------------------+---------------------+ |D30|operation id uses |deny("unsupported_wildcard") |wildcard-shape | | |a forbidden | |detection precedes | | |wildcard shape | |the base grammar, and| | |(*:query:SELECT) | |layer 1 propagates | | | | |the specific code | | | | |rather than | | | | |invalid_capability_id| | | | |(decide-018, Section | | | | |3/Section 9.1) | +---+------------------+-------------------------------------+---------------------+ |D31|grant bounds |deny("max_rows:violated") |op-side value outside| | |max_rows:10, | |the Section 8.1 | | |operation carries | |domain (finite non- | | |max_rows:"garbage"| |negative integer) | | | | |fails closed, never | | | | |passes unchecked | | | | |(decide-031, rev CLC-| | | | |1.4) | +---+------------------+-------------------------------------+---------------------+ |D32|grant bounds |deny("max_rows:violated") |boolean is outside | | |max_rows:10, | |the Section 8.1 | | |operation carries | |domain (decide-032, | | |max_rows:true | |rev CLC-1.4) | +---+------------------+-------------------------------------+---------------------+ |D33|grant bounds |deny("max_rows:violated") |a negative is outside| | |max_rows:10, | |the Section 8.1 | | |operation carries | |domain (decide-033, | | |max_rows:-1 | |rev CLC-1.4) | +---+------------------+-------------------------------------+---------------------+ |D34|grant bounds |deny("max_rows:violated") |a fraction is outside| | |max_rows:10, | |the Section 8.1 | | |operation carries | |domain (decide-034, | Wei Expires 31 March 2027 [Page 94] Internet-Draft CLC-v1 September 2026 | |max_rows:1.5 | |rev CLC-1.4) | +---+------------------+-------------------------------------+---------------------+ Table 19 B.6. Combined (11 vectors) +===+==================+===============================+==========+ |# | Scenario | Expected |Derivation| +===+==================+===============================+==========+ |C1 | wildcard grant + | allow |E2 + P1 | | | params within | | | | | bounds | | | +---+------------------+-------------------------------+----------+ |C2 | wildcard grant + | deny |E2 + P2 | | | params exceed | | | | | bounds | | | +---+------------------+-------------------------------+----------+ |C3 | intersection + | deny |I4 + D6 | | | constraint | | | | | violation | | | +---+------------------+-------------------------------+----------+ |C4 | two-source | allow, narrowest |I1 + I4 | | | intersection, | | | | | both narrow | | | +---+------------------+-------------------------------+----------+ |C5 | grant with empty | deny |deny-when-| | | constraint bound | |declared | +---+------------------+-------------------------------+----------+ |C6 | unknown scheme | deny("unknown_constraint") |fail- | | | in grant | |closed | +---+------------------+-------------------------------+----------+ |C7 | grant: std/ | deny |E2 + P4 | | | database- | | | | | v1:query:*, op: | | | | | std/database- | | | | | v1:query:SELECT, | | | | | params mismatch | | | +---+------------------+-------------------------------+----------+ |C8 | three-source | deny |I3 | | | intersection, | | | | | one absent | | | +---+------------------+-------------------------------+----------+ |C9 | valid grant + | allow |D1 | | | valid constraint | | | | | + valid op | | | +---+------------------+-------------------------------+----------+ |C10| malformed id in | deny("invalid_capability_id") |D4 | Wei Expires 31 March 2027 [Page 95] Internet-Draft CLC-v1 September 2026 | | operation | | | +---+------------------+-------------------------------+----------+ |C11| delegation | deny |deny-when-| | | chain, | |declared | | | intermediate hop | |propagates| | | declares empty | | | | | bound | | | +---+------------------+-------------------------------+----------+ Table 20 *Total: 123 vectors* Decisions D17–D28 are the corpus pin for the residual-obligation channel unresolved / allow_unresolved, the Section 8.1 (scheme,type) identity, the invalid_constraint value grammar and the Section 9.1 multi-grant aggregation. decide-025/-026 and syntax-007/-008 pin the Section 3 scheme grammar; decide-021/-022, decide-019/-024 pin Section 8.1 time/network value shapes; decide-019 pins the no-cross-midnight rule; decide-028/-029/-030 pin Section 9.1 ({}≡absent, any-allow union, deterministic deny reason); decide-035 (D29) pins multi-grant residual-obligation union across covering grants; decide-031/-032/-033/-034 (D31–D34) pin the Section 8.1 max_rows request-side value domain (rev CLC- 1.4); decide-018 (D30) pins Section 3 wildcard-shape detection ahead of the base grammar. Wei Expires 31 March 2027 [Page 96] Internet-Draft CLC-v1 September 2026 The corpus additionally carries 6 scheme stress-test vectors (clinical-001/-002, payments-001/-002, data-001/-002) exercised against std/{clinical,payments,data}-v1: their enum/bound outcomes follow the grouping rules above (→ B.3 params semantics), and payments-002 additionally exercises Section 8 fail-closed unknown_constraint for a scheme-scoped constraint type. These vectors add no new normative rule; they exist to record the v2 requirements evidence, not to extend v1. undeclared-001/-002 (→ B.5 D13/D14) pin the Section 6.2 key-closure rule. params-006/ params-013 (→ B.3 P6/P13) close two previously-unmapped rows; params-020/021 (→ P20/P21) are the positive boundary cases of params-018/019; decide-016/017 (→ D15/D16) pin the Section 9.1 pre-check and layer-1 paths for absent/empty grant and id-less operation; intersect-007..010 (→ I7..I10) pin Section 7 rules 5–6 including empty-params sources, order independence, and a params- free identifier comparison; intersect-011/-012/-013 (rev CLC-1.15) are the cross-type audit pins of Section 7 rule 6 (string × number merge refusal, type-sensitive enum-member equality, 1.0 ≡ 1) and sit outside the B.1–B.6 tables, taking the corpus total to 123. B.5 row labels Dn are semantic row numbers, not corpus ids (D15/ D16 ↔ decide-016/-017, D29 ↔ decide-035); D10 (absent/empty grant, operation present) has no dedicated vector — the pre-check path is pinned by decide-016 (D15). B.7. Containment (external corpus) The delegation-containment relation (Section 13) is pinned by a separate corpus at capability/data/_vectors/clc-d/: containment- vectors.json (64 vectors, groups: identifier coverage, parameter narrowing, constraint non-participation, validity, symmetry), containment-property-cases.json (784 forward-closure cases over 39 shared operations) and containment-crosswalk-vectors.json (44 cross- vendor vectors). It is not re-tabulated here; the corpus README maintains the live count and the snapshot date. B.8. Extended parameter bounds (external corpus) The Section 6.5 param_bounds grammar is pinned by capability/data/_vectors/clc-v1/param-bounds-vectors.json (43 vectors, groups: numeric interval/step, enum cardinality, optional keys, nested recursion, the binding rule, malformed bounds, scheme defaults), with param-bounds-vectors.schema.json. It is not re- tabulated here. These vectors exercise a CLC-1.10 field; a CLC-1.9 or earlier implementation refuses them through the Section 12.1 minor gate rather than ignoring the bounds. The JSON type-sensitive enum equality of Section 6.5 layer 8 (rev CLC-1.15) is pinned by the companion file param-bounds-equality-vectors.json in the same directory. Wei Expires 31 March 2027 [Page 97] Internet-Draft CLC-v1 September 2026 B.9. Resolve (external corpus) The Section 8.5 Resolve function is pinned by capability/data/_vectors/clc-v1/resolve-vectors.json (26 vectors, groups: terminal pass-through, all-satisfied → allow, partial → allow_unresolved, violated → deny, the time:window core clock in and out of window, TTL re-evaluation, bare assertion without now, conflict precedence and malformed input), with resolve- vectors.schema.json. Vectors that exercise the core clock carry now; a CLC-1.10 implementation that does not implement Resolve is unaffected by this corpus. B.10. ConstraintUnion (external corpus) The Section 7.1 derived ConstraintUnion projection is pinned by capability/data/_vectors/clc-v1/constraint-union-vectors.json (12 vectors: union over one/many grants, duplicate folding across sources, deterministic ordering, empty constraints, and the empty- chain absent_source refusal), with constraint-union- vectors.schema.json. The UTF-8 byte-order collation pinned in rev CLC-1.15 (Section 7.1) — where UTF-16 code-unit order would diverge — is exercised by the companion file constraint-union-collation- vectors.json in the same directory. B.11. AuthorizeWithChain (external corpus) The Section 13.11 fused chain check is pinned by capability/data/_vectors/clc-d/authorize-chain-vectors.json (15 vectors: empty chain, broken identifier/parameter hop, a broken hop reported before op validation, the degenerate two-grant form, ancestor-constraint enforcement via the effective intersection, the param_bounds refusal, and pass-through of allow / allow_unresolved / operation-layer deny), with authorize-chain-vectors.schema.json. B.12. BoundMeet (external corpus) The Section 6.6 intersection of param_bounds is pinned by capability/data/_vectors/clc-v1/param-bounds-meet-vectors.json (groups: numeric min/max/step meet including the coarser-grid and fail-closed step cases, enum intersection and tightened cardinality, optional conjunction, nested recursion, the empty meets (min>max, disjoint enums — empty _within one value family_), the unrepresentable crosses (numeric∩enum in either order and scalar∩nested, refused since rev CLC-1.15; cardinality-only enum, incommensurable steps → invalid_params_binding), the identity empty Bound, and the cross-site refusal), with param-bounds-meet- vectors.schema.json. The rev CLC-1.15 meet invariant — every successful meet authorizes only what *every* source authorizes — is Wei Expires 31 March 2027 [Page 98] Internet-Draft CLC-v1 September 2026 exercised by param-bounds-meet-property-cases.json in the same directory. Appendix C. Containment Carrier Vocabulary and Reason-Code Mapping This appendix is *informative*. It puts a carrier's own vocabulary and its failure codes beside CLC-D's, so an adopter can explain a containment verdict in the carrier's terms — and can see exactly where the mapping is many-to-one and therefore not reversible without carrier context. The profiles named here are the pinned ones in Section 13.9.3; the profile obligations are Section 13.8.1. C.1. Vocabulary +=========+====================+==============+===================+ | Carrier | Carrier term | CLC term | Note | | | | used here | | +=========+====================+==============+===================+ | CLC-D | identifier | CapabilityId | the relation's | | | scheme:action:path | | left/right | | | | | identity | +---------+--------------------+--------------+-------------------+ | CLC-D | parameter bound | params | declared bound; | | | | | absent or {} = | | | | | unconstrained | +---------+--------------------+--------------+-------------------+ | CLC-D | constraint | constraints | *union* axis, | | | (varwof/ | | outside Contains | | | constraint-v1:*) | | (Section 13.4.4) | +---------+--------------------+--------------+-------------------+ | ATN | resource_bounds, | params | Section 9.2 takes | | | numeric conditions | (upper | the per-dimension | | | | bounds) | min | +---------+--------------------+--------------+-------------------+ | ATN | id + schema.digest | identifier | digest mismatch ⇒ | | | | segments | distinct | | | | | capability (ccx- | | | | | 043) | +---------+--------------------+--------------+-------------------+ | ATN | preconditions | — (union | never compared by | | | | axis) | Contains | +---------+--------------------+--------------+-------------------+ | AAT | tools(derived) ⊆ | identifier | | | | tools(parent) | coverage | | +---------+--------------------+--------------+-------------------+ | AAT | argument | params | AAT's own | | | constraints | | contains/subset | | | (exact/range/ | | are _constraint | Wei Expires 31 March 2027 [Page 99] Internet-Draft CLC-v1 September 2026 | | one_of/…) | | types_, not the | | | | | relation | +---------+--------------------+--------------+-------------------+ | AIP | scope, budget, | identifier + | absent ⇒ nearest | | | expiry, domains | params | ancestor, | | | | | resolved by the | | | | | profile | +---------+--------------------+--------------+-------------------+ | AAE | mandate.actions | identifier | | | | | coverage | | +---------+--------------------+--------------+-------------------+ | AAE | CONSTRAINTS value | params | numeric ≤, | | | (unwrapped) | | allowlist ⊆ | +---------+--------------------+--------------+-------------------+ | AAE | validity | — (carrier/ | not a declared | | | | time, CLC-A | Contains input | | | | R1) | | +---------+--------------------+--------------+-------------------+ | AOA | operation scope | identifier | * maps to a CLC | | | string | path | trailing wildcard | +---------+--------------------+--------------+-------------------+ | AEGIS | dotted capability | identifier | | | | | path | | +---------+--------------------+--------------+-------------------+ | AEGIS | numeric context | params | | +---------+--------------------+--------------+-------------------+ | AEGIS | allowed_roles, | — (*not | identity/policy | | | environment, | mapped*) | dimensions with | | | risk_level, scope | | no CLC field; the | | | | | profile leaves | | | | | them to the | | | | | carrier (C.3) | +---------+--------------------+--------------+-------------------+ Table 21 C.2. Failure-code mapping Carrier failure codes collapse onto CLC-D's three codes. The mapping is many-to-one and is therefore *not reversible* without the carrier recording which of its own codes applied before mapping. Wei Expires 31 March 2027 [Page 100] Internet-Draft CLC-v1 September 2026 +=================+========================+======================+ | Carrier | Carrier code / failure | CLC-D reason | +=================+========================+======================+ | ATN Section 9.1 | different id | different_namespace | | identity rule | | | +-----------------+------------------------+----------------------+ | ATN Section 9.1 | different | child_exceeds_parent | | identity rule | schema.digest | | +-----------------+------------------------+----------------------+ | ATN Section 9.2 | raised resource_bounds | params_not_narrower | +-----------------+------------------------+----------------------+ | AAT I4 | tool outside parent | different_namespace | | | set | | +-----------------+------------------------+----------------------+ | AAT I4 | constraint not | params_not_narrower | | | subsumed | | +-----------------+------------------------+----------------------+ | AIP Section 4.4 | aip_scope_insufficient | child_exceeds_parent | +-----------------+------------------------+----------------------+ | AIP Section 4.4 | aip_budget_exceeded | params_not_narrower | +-----------------+------------------------+----------------------+ | AIP Section 4.4 | aip_depth_exceeded | child_exceeds_parent | +-----------------+------------------------+----------------------+ | AAE Section 3 | action not a subset | different_namespace | +-----------------+------------------------+----------------------+ | AAE Section 3/ | constraint not more | params_not_narrower | | Section 7.4 | restrictive | | +-----------------+------------------------+----------------------+ | AOA Section 6.2 | scope not strictly | child_exceeds_parent | | | narrower | | +-----------------+------------------------+----------------------+ | AEGIS | authority exceeds the | params_not_narrower | | AIAM1-DEL-010 | delegator's | | +-----------------+------------------------+----------------------+ | AEGIS | capability the | different_namespace | | AIAM1-DEL-011 | delegator lacks | | +-----------------+------------------------+----------------------+ Table 22 The collapse is visible in the right column: child_exceeds_parent is reached by both AIP scope and AIP depth failures and by an ATN digest mismatch, and params_not_narrower by every carrier's bound-widening. A carrier that needs its own code back must keep it alongside the CLC-D reason; CLC-D guarantees the stable language-level reason, not the carrier's. Wei Expires 31 March 2027 [Page 101] Internet-Draft CLC-v1 September 2026 C.3. Profile obligations exercised by the corpus Two of the Section 13.8.1 obligations are visible in the pinned vectors: * *Identity dimensions the language cannot carry fail closed.* ATN's schema digest is carried as an identifier segment (ccx-043) rather than dropped, so a digest mismatch is child_exceeds_parent instead of a silent match. * *Semantics the relation cannot see are a profile limitation, not a CLC gap.* AEGIS's allowed_roles/environment/risk_level and AAE's validity have no CLC field; the profile leaves them to the carrier and asserts nothing about them. They are not modelled here, and a profile MUST NOT claim containment of a dimension the relation cannot see. Acknowledgements Iman Schrock (EMILIA Protocol) reviewed the intersection and constraint semantics against the revision 1.1 corpus and supplied the adversarial cases that revisions 1.2 and 1.3 fix: nested partial overlap in intersection, constraint value handling for max_rows, and the public entry-point contract. For revision 1.4 he re-ran the Go, Python and TypeScript implementations and the 1,184 property cases, and closed the two objections he had raised against the max_rows value domain and the UTF-8 size bound. For revision 1.5 he re-ran the three Go suites — 105 authorization, 30 evidence and 13 crosswalk cases — and supplied the four corrections that revision carries: the collapse from three-valued evaluation to the binary report (Section 10), the separation of allow_unresolved from evidence (Section 11), the scope of delegation (Section 12), and the boundary between this projection identity and CAID (Sections 4.2, 4.3 and 6.4). For revisions 1.6 to 1.8 he re-ran the three implementations and reported the raw-boundary cases those revisions fix: the HTML- escaping and key-order defects in the canonical serializer, the decoded paths that disagreed with the raw path on malformed Unicode, and the raw size checks that counted a number by its received spelling and a literal astral character by UTF-16 code unit. Revision 1.9 folds the delegation-containment relation and the CLC-D class into this document (Section 13, Appendix C), retiring the formerly separate containment extension, and pins it against six adjacent capability drafts (ATN, AAT, AIP, AAE, AOA, AEGIS) reviewed on 2026-09-21. Author's Address Wei Expires 31 March 2027 [Page 102] Internet-Draft CLC-v1 September 2026 Jijie Wei Individual Email: pki@varwof.com URI: https://varwof.com Wei Expires 31 March 2027 [Page 103]