The allowance behind
a delegated key.

A customer can give a subcontractor narrower access while retaining her own authority. The difficult commercial question is what happens to the allowance they now use together.

Imagine a design firm buying 1,000 image transformations from a computing service. It hires a specialist to process one project and gives that specialist permission to submit up to 200 transformations. The firm keeps working on its other projects. A sensible delegation should let the specialist do the agreed work without revealing the firm's general account credential or opening every project.

This hypothetical arrangement combines three different promises: which requests the specialist may make, how the service identifies the person acting, and how much work the whole purchase will fund. Public research on restricted credentials helps with the first. A token-exchange standard clarifies the second. The third requires an accounting decision that a valid credential alone cannot settle.

Narrow the work that can be requested

The 2014 Macaroons paper, by Birgisson and colleagues, describes credentials that holders can restrict before passing them on. Added conditions, called caveats, can limit objects, actions and the circumstances of a request. Deriving a restricted credential need not require the target service to mint another one.

The construction protects accumulated restrictions through chained message-authentication codes. The verifier must also check the caveats. First-party caveats concern request context; third-party caveats require suitable discharge credentials. These are bearer credentials, so restricting use to a particular recipient requires meaningful evidence and enforcement, rather than merely writing a name into a field. The paper supplies a formal treatment and prototype evaluation, not a guarantee about every subsequent implementation.

For the design firm, the intended permission could be expressed as an intersection: the firm's allowed requests, restricted to Project A, restricted to reading inputs and submitting transformations, restricted to a stated period and an authenticated acting party. A request to delete Project B would lie outside that intersection. This describes the desired policy; it is not an implementation or a security proof.

A holder who restricts a copy may still retain the original credential. That observation matters to the economic description. Appointing a narrower user of a service need not surrender the purchaser's own access. A product sold as an exclusive transfer would require an additional arrangement that makes the former holder's competing authority ineffective.

Keep the acting party visible

RFC 8693 distinguishes delegation from impersonation. With delegation, an actor represents a subject while retaining a separate identity. Impersonation instead makes the actor indistinguishable from the subject within the authorised context. Those choices affect what a downstream service can understand about a request.

The standard also warns against reading too much into the word exchange. Under Section 2.1, exchanging tokens does not normally invalidate the input credentials; special token semantics can change that. Revocation propagation between input and output is deployment-specific. Exchange does not inherently implement a transfer that extinguishes the sender's position. Nor does the standard automatically impose narrower permissions: issuance depends on the service's policy.

In our example, the firm would want its transaction record to distinguish its own requests from those made by the specialist. That could support investigation and allocation of charges. The record should describe the authenticated acting principal and authority used, rather than assume that every use of the firm's account was a personal action by its owner.

Keep one purchase from becoming two allowances

Suppose the firm has already used 850 transformations and the specialist has used none. The specialist's nominal sublimit is still 200, but only 150 transformations remain in the shared purchase. If the service gives the firm's credential a separate 1,000-use counter and the specialist's credential an independent 200-use counter, it has changed the total commercial promise.

For this example, the intended constraints are simple: usage charged to the firm and all its delegates together must stay within 1,000, and this specialist's usage must stay within 200. The sublimit restricts who may consume part of the purchase. It does not create an additional purchase. These numbers are illustrative arithmetic, not measurements from either technical source.

The service could maintain a shared account with protected admission decisions. It could instead reserve part of the remaining allowance for the specialist, reducing what the firm can spend elsewhere. Those designs have different consequences. Shared accounting can require communication at admission; a reservation can leave capacity unavailable to the firm while the specialist is idle. Allowing a reservation to return needs an effective release rule, especially when old credentials remain reachable.

The earlier article, The second redemption, examines competing uses of one entitlement. Delegation adds a different source of confusion: the competing requests can come from different, deliberately authorised credentials. Every credential can satisfy its own restrictions while the family of credentials exceeds the purchased budget. The accounting boundary must follow the entitlement through that family.

Decide what earns a charge

Our example defines a transformation as one successful completed job, with failed work handled under a separate stated policy. The admission process would therefore need to reserve the necessary allowance before starting and reconcile that reservation with completion. A repeated request should not silently become a second charge, and an uncertain response should not cause the client to create another independent job by accident.

Other products may legitimately charge for submission or compute time consumed, including unsuccessful work. Customers and delegates need to know which event counts. Otherwise the same counter can describe incompatible products, and a comparison of prices or operating efficiency will mislead.

Further delegation also needs an explicit decision. Can the specialist appoint another worker? Does that worker draw on the specialist's 200-use sublimit as well as the firm's remaining balance? Who can cancel the appointment, and what happens to jobs already admitted? These questions concern the service's promised behaviour. They do not establish legal assignment, ownership of the output, or the removal of information already downloaded.

Test the delegation family

A useful evaluation would compare a restricted-credential design with ordinary service-managed subaccounts under the same purchased allowance and work policy. It should test valid delegated work, forbidden projects and actions, simultaneous parent-and-child requests near exhaustion, repeated submissions after lost responses, further delegation and cancellation during a running job.

I would record completed work, incorrect charges, legitimate requests wrongly refused, excess aggregate consumption, administration time and the cost of enforcing each decision. A design that lowers credential-management effort but increases reconciliation work may simply have moved the burden. These are proposed tests; no implementation, experiment or measured saving is reported here.

My published research on governance and rule change separates admission from authority over the rules. Applying that institutional question here means asking who can change delegation limits, recognise an exception or redefine a charge after customers have organised work around the service. This is an application of the question, not evidence that the blockchain study tested delegated computing markets.

The commercial benefit of delegation is the ability to organise specialised work without handing over unrestricted authority. Making that benefit dependable requires the service to connect a narrower permission to a clearly identified actor and the original allowance. A delegated key becomes useful when all three fit the purchase.