Summary

  • The 29 September -04 revision of Sankarshan Mukhopadhyay’s individual Agent Registry Protocol draft adds a structured authority-evaluation result, including decision, reason codes, evaluation time, policy identity and conditional evidence or freshness references. It is a proposal, not an IETF-approved standard.
  • Its new interoperability section would prevent an affirmative answer from outliving the material freshness bound in an HTTP cache; a consumer that misses material events must resynchronize or return a non-affirmative result. The prior draft already distinguished identity from authority, so the novelty is the more explicit wire and consumer contract.

Consider an agent whose identifier still resolves cleanly at noon, although its delegated permission was suspended at eleven. The identifier is not wrong. The decision made from an older copy of its status is. That is the operational gap addressed by revision -04 of the proposed Agent Registry Protocol, or ARPA. The document sits in the IETF Internet-Draft repository as an active individual submission. Its cover expresses an intention to pursue Standards Track status; that wording is not working-group adoption, IETF approval, an RFC, or evidence that anyone runs the protocol.

The earlier -03 text was not naive about this problem. It already separated identification and authentication from authorization, warned against treating a capability advertisement as permission, and required material freshness to be assessed. The news in -04 is a lengthy new section that tries to pin those principles to interoperable objects and failure behaviour. Section 29.1.7 specifies what an Authority Evaluation Result would carry on the wire: a decision, one or more stable reason codes, evaluation time and the chosen policy’s identifier, version and applicability. A conditional allow needs its conditions. Materially derived or historical evidence needs a source checkpoint; freshness information is required when it can alter the decision. The answer is meant to expose why it was reached, not just whether a name was found.

The draft gives those fields consequence. Under section 29.3, only allow and allow_with_conditions are affirmative. deny, indeterminate and not_applicable remain different non-affirmative outcomes. Section 29.4 forbids silently reading stale, conflicting or unsupported material status as active. Those are proposed rules within the draft, not requirements already imposed on registries by the IETF. They nevertheless clarify the question a consuming service would have to ask: which policy and which observation made this result usable for this action at this time?

Caching is where the distinction becomes especially tangible. Section 29.7 does not outlaw an HTTP cache. It says the cache lifetime must not exceed the validity or freshness bound material to the authority evaluation. A cache that retains an identity record longer may still be useful for identity resolution, but it cannot quietly extend a positive permission verdict beyond the evidence supporting that verdict. When material freshness cannot be established, the proposed outcome is non-affirmative. The article’s noon example is hypothetical; the draft supplies no measured incident or deployment survey.

The same reasoning reaches event streams. If a registry advertises an ARPA event endpoint, section 29.10 would require stable event identifiers and an ordering position or checkpoint sufficient to detect gaps. A consumer that detects a material gap cannot keep asserting an affirmative state solely from the incomplete feed; it must resynchronize against an authoritative snapshot or checkpoint, or return a non-affirmative result. This is a repair path, not permanent denial. Section 29.11 separately makes writes default-deny and says an operator or controller label is not, by itself, a licence to mutate unrelated authority records.

Finally, section 29.16 asks conformance claims to identify the implementation role and map promoted requirements to positive and hostile fixtures. That is a proposal about how an implementer would demonstrate behaviour, not proof that independent implementations or a corpus of passing tests already exist. The valuable change is narrower than the ambitious protocol name: revision -04 makes a current authorization answer harder to confuse with a durable registry entry. Its reception and implementation remain open questions.

Sources