Summary

  • Revision -07 of an individual Internet-Draft splits native VERIFIED from relying-party ACCEPTED; revision -06 had folded local trust into the first result. This is a proposal, not an IETF-approved standard.
  • A resolvable key makes an artifact checkable, not necessarily acceptable. An unresolved reference is NOT_EVALUATED, not proof that a signature failed.
  • Only evidence that passes both steps can be matched to the intended action. Even SATISFIED evidence leaves the executor's AUTHORIZED decision and actual outcome open.

Consider a receipt an agent offers before an expensive infrastructure change. The bits and signature are identical at two operators. Both can verify the signature against the same key; one has that signer pinned for this kind of approval and the other does not. Calling the receipt simply “valid” would conceal the operational disagreement. The first operator has made a local trust decision. The second has not. Neither has yet decided whether to perform the change.

That is the useful news in Ian Schrock's 28 September revision of Authorization Evidence Chains: Composing Heterogeneous Agent-Action Evidence. The official archive carries draft-schrock-ep-authorization-evidence-chain-07, an individual Internet-Draft marked Informational by its author. It is not a Working Group adoption, an RFC, a deployed control or an IETF instruction to operators. Revision -06 already proposed an evidence-composition object. The -07 change log says that the old VERIFIED result joined a native check and the relying party's trust judgment; the new text reports VERIFIED and ACCEPTED separately.

The distinction is not merely a nicer audit label. Native verification answers whether a component's cryptographic and structural checks succeeded under the verifier's inputs. Acceptance asks whether the relying party's pinned issuer, role, key class, directory status, policy and format revision allow that verified component to count. If a format points to a key rather than carrying it, the verifier must resolve the reference from relying-party material. If it cannot, verification is NOT_EVALUATED, not FAILED. If it can, the key still has to be accepted for the component's role and at the relevant time. Because key-resolution material can differ, the same bytes need not even have a context-free verification answer across operators. The new vocabulary makes that dependency visible rather than pretending there is a universal green tick.

Nor may the presenter supply a Boolean saying that its own evidence is verified or accepted. The draft requires the native check and local acceptance at a protected boundary. It permits previously computed verifier results inside the same trust boundary only when they are integrity-bound to the exact evidence digest, verifier profile, trust snapshot and verification time. A serialized result handed over by the presenter is another artifact to verify, not an exemption. This matters when an agent passes a bundle through several services: a downstream executor cannot inherit somebody else's trust pins just because a wrapper says “approved.”

The sequence after those two results also matters. Only VERIFIED and ACCEPTED components become eligible for material-action matching. An authentic, locally accepted permit for a different frozen action fails MATCH; it has not suddenly become an unacceptable signer. Freshness, authenticated status, role constraints and inter-artifact bindings then determine whether the relying party's named evidence requirement is SATISFIED. That word means the evidence suffices for the requirement at the stated verification time. It is not the protected application's AUTHORIZED decision, an invocation record, or proof the requested effect occurred. The draft explicitly keeps these answers apart.

Revision -07 makes the separation inspectable in a replay output: algorithm revision, action and requirement digests, verification time, per-component native_verification and acceptance, a trust-snapshot digest, matching result and bounded reasons. Its reason codes should distinguish a bad cryptographic check, a check that could not be evaluated, a local trust refusal and a wrong-action match. A later investigator could therefore ask whether the artifact changed, the verifier configuration changed, the pinned trust policy changed or the agent asked to do something else. The replay object is an evaluation output, not a universal registry or a presenter-provided pass. The draft asks IANA to do nothing.

Sources