@Cliff I agree that verifying an approval record does not establish that the authority it depends on still holds at execution. I’ve made that boundary explicit in §6.9 of the editor’s copy <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission.html#multi-party-approval> .
The effect of the officer’s transfer depends on policy. An organizational approval may survive her transfer. Under a personal delegation with a declared dependency, further orders are refused within the declared bound after the authoritative source records her loss of authority. Work requiring an accountable owner may pause until an authorized successor takes responsibility. The new example <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-approval-governance.html#approver-transfer-example> covers all three without changing who originally approved the Mission. Your definition makes current authority a condition of reliance. Would an authorized successor inherit responsibility for order 4471, or would that require a separate acceptance or approval? Does the dependency apply to the order’s approval, the Mission, or both? I agree this distinction does not require a new OAuth format. The Runtime draft’s proposed authority-dependency rules <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-runtime.html#input-authority-dependency> require the deployment to identify the authoritative source, freshness bound, and enforcement path. If current standing is required, permitting execution with a flag does not satisfy that condition. The check can use a sufficiently fresh observation without requiring a remote lookup for every action. @Henri Your distinction between human action on this decision and reuse of an earlier approval is useful. Under Mission’s governed_policy, a human approves a bounded policy version, and the policy decides later activations. The human remains accountable without being recorded as personally approving each activation or purchase. Your example distinguishes approval of M17, the ERP’s decision BD-9001 about PO-9001, and authorization to execute the purchase. The ERP can make the latter two decisions in one component, provided its decision and enforcement path meets the runtime contract <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-runtime.html#runtime-contract> . You’ve identified the optional members that carry disposition, policy and decision linkage. For this integration, we should specify which are required. Could we also work through how the receipt identifies the Mission and how a verifier checks the authority and the link to execution? I can sketch the Mission side. For now, I would keep governance_record tied to the Mission’s approval event and link evidence for later purchase decisions separately. -Karl On Sun, Oct 25, 2026 at 11:23 PM Henri Sirkkavaara <[email protected]> wrote: > Karl, all, > > In your procurement example, BD-9001 could be a receipt under > draft-sirkkavaara-vaara-receipt-14, with PO-9001 as the call it > decided. The issuer signs the verdict and can record who disposed of > it, "human" or "policy", plus a flag that is true only when a person > acted on this decision. A replayed earlier approval does not set it. > > The record names the call and commits to its arguments with a fresh > salt per decision. The holder opens the commitment with the order's > arguments, and that opens this decision and no other. The execution > record can carry the digest of the decision it answers, so an outcome > cannot be attached to a different decision about the same call. > > decidedAt is the issuer's clock. A relying party that needs time it > does not take from the ERP checks an RFC 3161 token over the signed > receipt, which shows the receipt existed no later than that time. The > state the decision was made under travels as a digest of the issuer's > decision state, which includes the policy it loaded. > > The relying party checks the signature, the evidence digest, the opened > commitment and the decision digest in the execution record. The record > says nothing about whether M17's approval was valid or the policy > sound. The disposition, the policy digest and the decision digest are > optional members in -14, so the example needs an issuer that writes > them. Member names are in Sections 3.7, 5 and 6.8. > > Cliff's standing check is outside -14 too. The receipt records who > disposed of the decision at the time it was made. Section 10 says a > signature that verifies tells a consumer nothing about the signing key > now, and the same holds for the approver: whether they still hold the > role on 12 Nov is checked by the deployment at use, against its own > records. The receipt does not carry that. > > Henri Sirkkavaara > Founder, Vaara > vaara.io | [email protected] > > Helsinki, Finland > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
