Summary

  • A 27 September individual Internet-Draft proposes allow_unresolved alongside allow and deny for agent capability decisions; an unevaluated condition is not a permit.
  • The draft assigns residual checks to the consuming enforcement component. Its own implementation tests do not establish independent interoperability or IETF approval.

Imagine an agent granted a command only from a specified network and during an approved time window. A grammar can recognize both conditions without knowing the live network context or the clock rule the application has chosen. If the decision engine reports plain allow at that point, the permission has been broadened without anyone explicitly taking responsibility for the missing checks. Jijie Wei's new Capability Language Core proposal tries to make that gap a separate machine-readable outcome.

Published on 27 September 2026, draft-wei-capability-language-core-00 is an individual Internet-Draft with intended Experimental status. The IETF Datatracker lists it as I-D Exists and explicitly says that an individual submission has no formal standing in the standards process. There is no RFC, working-group adoption or evidence here of production use. Its reportable change is a proposed common language for capability identifiers, grant-to-operation coverage, intersecting multiple grants, and a deterministic decision function.

The sharpest boundary is its third verdict. Section 8.4 treats recognized time and network constraints that the v1 core cannot evaluate as residual obligations. They must remain in an unresolved list, and the answer is allow_unresolved, not allow. This is not a polite warning attached to a permit. The draft says the consumer — a policy enforcement point, carrier profile or declaring scheme — must evaluate or confirm every unresolved constraint before allowing an action, and deny if it cannot. Where several such conditions are present, satisfying one is not enough: the draft makes them conjunctive.

Section 8.5 adds a Resolve step: the consumer can return satisfied, violated or unknown for each obligation, and the core produces a fresh decision. That feedback loop does not magically create the observation. A network boundary still needs a competent evaluator; a time rule still needs a pinned interpretation and an appropriate clock. A binary adapter that maps every non-deny response to executable permission would defeat the proposed distinction. That is an integration risk implied by the semantics, not a reported exploit or a finding about an existing product.

The scope is deliberately narrower than a complete agent-security system. The draft says it defines what is evaluated, not who may be trusted to issue a grant, how a native token or signature is verified, whether an action actually ran, or how a receipt is carried. It mentions OAuth Rich Authorization Requests as one possible carrier mapping; RFC 9396 already defines the authorization_details parameter, but it does not standardize CLC. A carrier and a decision language may fit together only after the relying party supplies its own binding and enforcement rules.

The document reports 123 authorization vectors and 1,184 property cases, passed by Go, Python and TypeScript implementations sharing an author. Those numbers are useful evidence of an author's regression discipline, not an external interoperability result. The text itself says its two-independent-implementation maturity threshold has not been met. It claims a baseline authorization class, CLC-A, while declining to claim its evidence-side class CLC-E. The maturity distinction matters as much as the extra enum value: a precise proposal can still be an unvalidated proposal.

Sources