Karl, all, Taking up the ask to pin down the business decision, its scope and timing, and the evidence a relying party needs, with the procurement example. Standing policy: the procurement officer may place orders up to a cap (Jiahui’s policy-ref). Decision: on 3 Nov she adopts order 4471, $38k, supplier X (a decision-ref, bound to scope and time as the Luna draft’s decision-replay consideration requires). The agent executes on 12 Nov. On 7 Nov she transfers out and the role sits vacant. On 12 Nov everything this thread has built passes. The typed digest verifies. The decision-ref resolves to a signed record naming the approver. The action is inside the decision’s scope and window. And the approval has nobody behind it. That is a third property, separate from the two the digest work covers:
* Resolving: the reference leads to a signed decision record that names an accountable approver. * In-window: the action is inside the scope and time the decision bound. * Standing: at the point of use, a currently accountable person or role-holder still holds the authority the decision depended on. Standing is the only one of the three that can change with nothing changing in the artifact. Departure, role reassignment, rotation of a credential the Mandate depends on, a Mission Record restored from a snapshot taken before the approver left: the digest still verifies in every case. I wrote this up as a companion to the NIST IA-9 overlay work: “Authority Provenance: Standing of Delegated Authority Behind Non-Person Actor Actions”, v0.3, doi:10.5281/zenodo.23105657 (CC BY 4.0). Three parts bear on Karl’s question: 1. Evidence for a later action is not re-verification of the approval event. It is a determination, made at the point of use from the current delegation record, that the approver still holds the authority. An earlier determination is not reused (Element (b)(i)). 2. When that cannot be confirmed, the record says “not standing”, not “unknown”. The use is not recorded as authorized; deny versus permit-and-flag is the deployer’s selection ((b)(iv)). This sits next to Mission-01’s own gating: revoking a Mission stops issuance but does not recall issued tokens, and a standing check at use is what covers the token already in hand. 3. High-frequency use: a maximum age for the determination, declared before use, each determination recorded against every use it supports ((b)(v)). No declared age falls back to (b)(iv). None of this needs a format inside OAuth. If the Mission or Mandate carries a typed decision-ref, standing is evaluated by whoever holds the record, out of band, which is where the thread has already put the governance layer. What I would ask is that the out-of-scope statement in §6.9 name the property it leaves out: a resolving, in-window decision reference does not establish that the approving authority is still standing at the time of use. Disclosure: I am the founder of Cerydora, a commercial product in this space. The deposit requires, references and is tested against nothing of mine; any equivalent mechanism satisfies it. Cliff Singletary
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
