Summary

  • draft-wei-capability-language-core-00 distinguishes allow_unresolved from both allow and deny: the language understood an obligation, but the available evaluator or evidence did not settle it.
  • The consumer must preserve the normalized unresolved set, resolve every conjunctive obligation and deny if any is violated or remains impossible to evaluate. Treating the enum as truth silently broadens authority.
  • Resolution is time-sensitive. An allow produced inside a permitted clock segment cannot be cached beyond that segment's end without re-evaluation.

The dangerous success code

Suppose a capability permits an automated settlement job only between 09:00 and 09:15 and only from an approved network. The core evaluator understands both constraint types. It can confirm the network, but the caller did not supply a trustworthy now. A binary engine would have to guess. Capability Language Core revision 00 instead returns allow_unresolved and carries the clock obligation forward.

That is not partial permission. It is a typed refusal to erase work that another layer must still perform. The consumer can obtain a trusted time, submit a resolution and call Resolve; or it can deny. It cannot turn the shared prefix in the enum name into an authorization decision.

This looks like a small API rule. It is an authority boundary. The engine defines what its output means, while each consumer decides how native credentials are verified, which evidence sources are trusted and whether the action is released. If a language binding, workflow tool or cache coerces the three-state result into a Boolean, the least examined component becomes the final policy maker.

Recognition is not evaluation

CLC is carrier-neutral. It does not decide whether a JWT, CBOR object or another native container is authentic; it expects the surrounding system to establish the relevant trust and supply the capability content. Nor does it execute the action. Its job is to evaluate a common language and return a result whose limits remain visible.

Revision 00 knows the grammar of core clock and network constraints. Knowing the grammar means an implementation can preserve, normalize and compare the obligation. It does not mean the implementation has a trustworthy clock, current network observation or deployment-specific evaluator.

Silently dropping a known but unevaluated constraint would be worse than rejecting an unknown field. The request would emerge with less authority restriction than it entered. The draft therefore requires the residual to survive in unresolved. Multiple obligations of the same scheme and type remain conjunctive: satisfying one does not turn the others into alternatives. First-wins, last-wins and “take any” processing all change the policy.

Normalization matters because a verifier and consumer need to agree on the exact unfinished set. Equivalent duplicates may be folded; distinct obligations may not disappear. Ordering is based on the specified UTF-8 byte representation, not a runtime's convenient default. ECMAScript's ordinary UTF-16 string ordering, for example, is not automatically the same rule. Determinism keeps two implementations from discussing different residual sets; it does not make either set satisfied.

Resolve is the second half of the decision

The draft does not leave completion as an informal callback. Resolve accepts the earlier decision and resolution material for the outstanding obligations. Its precedence is deliberately asymmetric. One violated obligation produces deny. If all are satisfied, the result becomes allow. If any remains unknown, the result remains allow_unresolved.

Malformed resolution input and invalid timestamps deny. Terminal allow and deny remain terminal rather than being reopened by later convenience data. The evidence-oriented path is stricter still: it has no unresolved authorization state; an unknown evidence condition is unsatisfied.

An implementation therefore needs more than a dashboard showing “resolver invoked”. It needs a joinable record: initial enum, exact normalized obligations, evaluator identity and version, evidence reference, observation time, state for each obligation and final decision. The action release must point to that final record. Otherwise an auditor can see that evidence once existed without knowing which permission it completed.

A valid answer can expire

Return to the 09:00–09:15 settlement window. At 09:12 a trusted clock can satisfy the residual. Resolve may correctly return allow. That answer does not acquire an unlimited lifetime merely because its derivation was valid.

The permission horizon is 09:15. A cache keyed only by subject, resource and action may replay the allow at 09:20. Nothing in the original evaluation was false; the deployment changed a point-in-time proof into a durable grant. Cache expiry must be no later than the earliest end among all time-bound resolutions, and a changed context requires a new decision.

This is where leadership choices become operational. Someone must name the trusted clock, acceptable skew, timezone interpretation, resolver owner and failure mode. RFC 3339 can standardize timestamp syntax. It cannot choose the authority of the clock or decide how late is too late.

Contained authority can still be unusable

CLC also describes containment: whether one capability stays within another's declared authority. That is an important structural test, but it answers a different question. A contained capability with an unresolved time window is still unresolved. A perfectly normalized capability from an untrusted carrier is still untrusted. An allowed decision does not prove the external action ran or produced its intended effect.

Lu Heng's reality layers are useful precisely here. The capability is a symbolic claim; normalized constraints are a representation; evaluator observations belong to the operating layer; an action and its consequences occur later. Collapsing those layers makes the cleanest artifact look like the final fact.

The minimum initial specification is therefore not a universal trust system. It is a narrow interoperable contract: preserve the residual, give it a stable meaning and let accountable local institutions decide which native verification and evidence can discharge it. Running code gives the proposal testable weight, but not more than it has earned.

What the implementation evidence does—and does not—show

Revision 00 reports 123 conformance vectors and 1,184 property cases across three implementations. That is useful evidence that authors have exercised normalization, decisions and edge cases. The listed implementations share an author, however, and the draft's independent-implementation threshold remains unmet.

The right conclusion is neither dismissal nor certification. Recompute the corpus in an implementation that does not share the authors' assumptions. Test enum handling across language bindings, UTF-8 ordering, repeated constraints, unknown resolutions, invalid timestamps and cache expiry at the exact segment boundary. Then publish the disagreements. Compatibility claims should follow independent execution, not precede it.

Sources and limits

These sources establish an active individual Internet-Draft, its public corpus and related specifications. They do not establish IETF consensus, an RFC, working-group adoption, independent security review, broad deployment, trusted carrier verification or successful action outcomes. This Article owns only revision 00's recognized-but-unevaluated constraint channel, Resolve loop and expiring time-window discharge.