Karl, Not by appointment alone. A successor taking the role on 10 Nov has to hold the delegation; occupying the role doesn’t do it (companion §3.0, (c)(i)). Where the departure has put the grant into re-ownership, recovery also needs the successor’s recorded acceptance ((c)(v), (d)(ii)). Revocation is the other closure route — it closes the grant rather than restoring usable authority. https://doi.org/10.5281/zenodo.23105657 For 4471, the dependency follows the declared scope of reliance. If the order relies on the Mission’s persistent grant, acceptance of that grant covers it; the companion doesn’t require a separate acceptance of each order. If the order depends on a separate grant, or on a decision-specific accountable-owner requirement, restoring the Mission’s authority doesn’t satisfy that on its own. Acceptance recovers responsibility for the grant going forward; it doesn’t rewrite who made the original approval. That’s the distinction my “person or role-holder” wording needed. It also doesn’t remove any separate requirement to approve the order under applicable policy. On 12 Nov, the point-of-use determination has to establish standing for the grant actually relied on, including the acceptance and its scope. That settles standing, not every condition for executing. If standing can’t be confirmed, (b)(iv) says the use isn’t recorded as authorized, and leaves deny versus permit-and-flag to the deployer. Runtime §2.7.7 makes that selection for a declared dependency: refuse. The two compose; the companion sets the floor and the profile fixes the choice. Your §11.2 successor acceptance and §2.7.7 declared dependency scope are consistent with all of that. Neither a job title nor the original approval record alone establishes what the successor has accepted. Cliff
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
