[Use Case] Enterprise procurement with multi-level delegation, cumulative limits and revocation on role change
fg-tida-use-cases-use-case-enterprise-procurement-with-multi-level-delegation-cumulative-limits-and-revocation-on-role-change-65
| Type | FG-TIDA document |
|---|---|
| Group | Trust and Identity for Humans and Agentic AI |
| State | Submitted |
| Authors | Not entered |
| Last updated | 2026-10-23 15:11 UTC |
Formats and resources
Abstract
1. Identification
Title: Enterprise procurement with multi-level delegation, cumulative limits and revocation on role change
Submitting organization: PAX S&T Co., Ltd. (Republic of Korea)
Contact name: Jaedoo Kim
Contact email: jdookim0307@gmail.com
Sector (tick all that apply; a cross-industry case may tick more than one):
- [ ] Education
- [ ] Displaced persons / humanitarian
- [ ] Health
- [ ] Financial services
- [ ] Telecom
- [ ] Media and publishing
- [x] Logistics
- [ ] Energy
- [ ] Critical infrastructure
- [ ] Smart home / IoT
- [x] Other (specify): Enterprise procurement (industrial supplies)
2. The situation
Plain language description (required, 3 sentences max): A procurement manager of Company K, authorized by the company to commit it for a category and budget, delegates to a procurement agent the authority to buy industrial sensors within a per-order amount and a monthly cumulative limit, and the agent re-delegates to a sub-agent the authority to collect quotations only. A supplier's sales agent must decide whether an incoming order, or an acceptance sent by the sub-agent, is backed by Company K. When the manager's purchasing authority ends, the authority of both agents must end from that moment, and suppliers learn of it within the freshness they require.
Actor (every party involved): Company K (principal, organization); procurement manager (role holder); Company K's enterprise IAM (trust source for the role); business registry (trust source for Company K); procurement agent; quotation sub-agent; supplier (relying party) and its sales agent.
Action: The procurement agent places an order; the sub-agent collects quotations and, in the failure case, attempts to accept an offer; Company K later revokes the delegation.
Decision required: "Is this order backed by Company K's authorization of the manager, within the per-order and the monthly cumulative limit as of now, and does the agent in front of me hold commitment authority rather than quotation-only authority?"
Problem encountered (why that decision cannot be made today): Delegation scopes are usually expressed per platform or per authorization server; a role attested by enterprise IAM does not by itself show authority to commit the company; the supplier cannot readily see whether a sub-agent's authority stays within its parent's; cumulative limits spanning several orders, possibly placed concurrently by several agents, are not checkable from the delegation alone; and the supplier may not learn in time that the underlying authority has ended.
Current mitigation: Purchase orders confirmed by humans; supplier portals with per-buyer accounts; periodic reconciliation of spending against budgets.
Residual gap: Working hypothesis, to be tested in the gap analysis: no common profile yet covers multi-level delegation in which a re-delegation can never exceed its source, the organization's authorization is distinguished from a role, cumulative limits are reserved against an authoritative state, and the end of the underlying authority propagates to every agent depending on it.
3. Actors and context
Taxonomy roles involved
- [x] Principal — possesses the authority being exercised; source of the mandate
- [x] Relying party — must decide whether to accept the agent's authority
- [ ] Builder
- [x] Deployer / Owner
- [x] Agent instance
- [x] User — interacts with the agent; may or may not be the principal
- [ ] Infra provider
- [x] Attestor
- [ ] Other (specify):
Mandates in this case (required)
| Grantor | Grantee | What is conferred | Governing regime |
|---|---|---|---|
| Company K (legal entity) | Procurement manager (employee) | Authority to commit the company for a product category and budget, recorded in Company K's internal authorization, distinct from the job role itself | Company K internal authorization rules; corporate, employment and commercial law |
| Procurement manager, as representative authorized by Company K (Company K remains the principal) | Procurement agent | Buy industrial sensors from qualified suppliers; per-order and monthly cumulative limits; contracts above threshold require the manager's approval; re-delegation permitted for quotation only | Company K procurement policy; commercial law |
| Procurement agent | Quotation sub-agent | Collect quotations only; no commitment authority; no further re-delegation | Derived from the mandate above; can never exceed it |
Cross-border?
- [ ] Yes — jurisdictions involved:
- [x] No
Embodied (physical actuation or sensing)?
- [ ] Yes — physical context:
- [x] No
Agent action type (required)
- [x] Read-only
- [x] Consequential (reversible)
- [x] Irreversible (acceptance of an order may form a contract)
Crosses organisational boundary? (required)
- [x] Yes (specify): between Company K and the supplier
- [ ] No
Risk level (required)
- [ ] Low
- [x] Medium
- [ ] High
4. Theme relevance
| Theme | Yes | Primary | Justification (required if checked) |
|---|---|---|---|
| Dynamic Identity | [ ] | [ ] | |
| Continuous Trust and Attestation | [x] | [ ] | Authority depends on a role that may change; the supplier needs the current state, not the state at issuance. |
| Delegation | [x] | [x] | Two-level delegation with narrowing, cumulative limits and an approval threshold must be verified by an external relying party. |
| Discovery and Cross-Border Trust | [ ] | [ ] | |
| Runtime Enforcement (Control Plane) | [x] | [ ] | The supplier must refuse the sub-agent's acceptance at the moment of action because it exceeds the sub-agent's mandate. |
| Embodied AI Identity and Trust | [ ] | [ ] |
Related theme proposals: [Theme] Subject-Anchored Identity, Delegation and Discovery for Agentic AI (FG-TIDA/themes#45); FG-TIDA/themes#23 authorization and privilege lifecycle; delegation depth in multi-agent chains, raised at the 3rd preparation meeting (https://github.com/FG-TIDA/meetings/blob/main/2026-09-30-preparation-meeting-3/minutes.md).
5. Requirements
| # | Type (choose one) | Requirement description | Criticality (choose one) |
|---|---|---|---|
| 1 | Technical | A re-delegation can never confer more authority than its source; a relying party can verify this along the chain, including the direct issuer and the parent delegation. | Must |
| 2 | Technical | Cumulative limits spanning several actions are held by an authoritative cumulative state (for example on the organization's side) with reservation before execution, bound to the acceptance of each order, so that concurrent orders by several agents cannot exceed them. | Must |
| 3 | Technical | Ending a delegation, or the authority it rests on, ends the authority of every dependent agent from that moment, without affecting the organization's identity or other relationships; relying parties check status before a consequential action, with freshness set by risk. | Must |
| 4 | Business | A role attested by enterprise IAM is distinguished from the organization's authorization to commit; both may be needed. | Must |
| 5 | Technical | Organizational principals can be attested by existing trust sources (business registry, enterprise IAM) rather than re-established per agent. | Should |
| 6 | Business | Conditions requiring human approval are part of the delegation and visible to the relying party. | Should |
| 7 | Technical | Each order carries a unique reference that the supplier's system checks and records atomically, so that a retried submission is executed at most once and returns the original result. | Must |
6. Assessment criteria
Success criteria: Using the verifiable delegation chain together with the authoritative cumulative state and current status, the supplier accepts the procurement agent's order, refuses the sub-agent's acceptance, refuses orders for which no reservation against the cumulative state can be obtained, executes each order at most once, and refuses orders from either agent once it has observed the revocation.
Measurable metric: (a) Rate of actions accepted outside the delegated scope, including acceptances exceeding the cumulative limit, whether or not any revocation occurred (target: zero); (b) after a revocation, rate of actions accepted once the revocation was observable under the freshness required for the action (target: zero), and the time between revocation and the supplier's observation of it; (c) duplicate executions of a retried order (target: zero).
7. Duplication check
Existing standards or SDOs: OAuth 2.0, Token Exchange (RFC 8693, actor claim) and Rich Authorization Requests (RFC 9396); GNAP; attenuable capability tokens (UCAN, ZCAP-LD, macaroons, Biscuit); Agent Payments Protocol (AP2) v0.2 mandates; OAuth Transaction Tokens; enterprise IAM and RBAC; X.1250-series identity management.
Overlap notes: These provide delegated access, including token exchange across domains (RFC 8693) and fine-grained authorization details (RFC 9396). The working hypothesis, to be tested in the gap analysis, is that scope vocabularies and cumulative-limit semantics are not common across organizations, and that constraints on multi-level re-delegation and revocation propagation are not yet profiled for an external relying party in a provider-independent way.
8. Maturity
Pilot status
- [x] Hypothetical
- [ ] Pilot in progress
- [ ] Deployed in production
Reference implementation: n/a (architecture described in the HWW white paper and HCTP Core Specification Draft 1.0, https://www.hww.kr; a minimal proof of concept is in preparation)
9. IP and confidentiality
Confidentiality level
- [x] Public
- [ ] FG-internal only
- [ ] Redact before publication
IP notes (optional): PAX S&T Co., Ltd. holds Korean Patent No. 10-2990000 and International Patent Application PCT/KR2026/012600, which may relate to the architecture referenced here. It intends to license on RAND terms and will submit an ITU-T General Patent Statement and Licensing Declaration; this note does not replace that declaration and does not imply that any patent is essential to a future Recommendation.
10. Assets
Link to assets:
- [ ] Dataset
- [ ] Code
- [ ] Protocol
- [x] Other: White paper and core specification draft (background only, not proposed for standardization), https://www.hww.kr
IP notes (optional): As above.
Revisions
- No file revisions have been uploaded.