Conceptual model · 1 min read

Delegated authority stays within the approved grant

Original editorial defensive synthesis, not a vendor architecture, protocol sequence or independently verified patch. The Google researcher describes lost client and permission binding through a device grant; proposed binding controls are not evidence of the deployed repair. The n8n maintainer describes constrained first issuance but missing resource binding during refresh, with a stated repair that retains the binding and rejects mismatches. It also calls for renewed authorization of older unbound grants. RFC 9700 sections 2.3 and 4.14.2 support restricted token authority and refresh grants bound to the consented scope and resource servers. The graph abstracts one invariant shared by distinct first-issuance and refresh paths; it does not equate their protocol steps. Both input arrows are required together, not alternative authorization paths. Trusted context means authenticated, integrity-protected grant information and applicable client verification; no storage design is prescribed. The subject's wider access and a client's registration are not extra authority delegated by this grant. Within approval permits narrower issuance and authority added through a separately approved incremental decision; it does not require exact equality with every original permission. Resources, audiences and actions have deployment-specific meanings. Mismatched or incomplete binding cannot establish approval. A separate authorization decision is needed to change approved authority, with no automatic consent or retry loop implied. Revocation, concurrency, replay protection and consent usability are outside this model.