Attenuated Delegation

- 8 min read - Text Only

While reading a discussion on the Grant Negotiation and Authorization Protocol (GNAP) mailing list, I came across a phrase I did not recognize: “attenuated delegation”.

So what is this? Skip to the section Delegation for the answer

What's Attenuated Delegation?

Unfortunately on google there are not many good results for “attenuated” and “permissions” or “delegation”. While I have heard of macaroons and briefly looked at the paper, the word or phrase “attenuation” / “attenuated” did not stick with me. The other results about some sort of gender or health topics that threw me off.

Bad Search Result

Bad Search Result

What the heck are these results?

So I asked! And thankfully I received a response--although not on the mailing list.

Alan's Response


Some services permit users to create tokens that can perform all actions on their resources. These token are Not the user's credential, but is instead a disposable secret that can be revoked at the user's whims later. When a request is made with that token, the client could do all actions that user can on their resources. This is simple, but it requires complete trust to the client as long as that token is valid.

Complete trust is not safe, especially if the token can be ripped in a fly-by attack.

Discord Session Compromised

The above image is from ScreamyShepard on twitter, it comes from this tweet

Attenuated Delegation

Delegating a subset of your permissions is a way to enforce the Principle of Least Privilege. The client, application, or service that is given delegated access to resources you have access to can be attenuated or constrained.

For example, you may have a token granting you read/write permissions to some file. You’d like to delegate only read permissions to the service printing the file so that services can’t accidentally or on purpose modify the file.

Okay so attenuated delegation means that the resource owner or principal restricts (attenuates) delegated access / permissions / capabilities that a client is provided with.
Unsure what a principal is? See Principle of Least Privilege Section Principal. In short: the identity + permissions that the relying party trusts.

OAuth Delegation

Or the client presents a subset of the permissions requested, which the resource owner authorizes.

You may have seen something like this when logging in to a site with Twitter, Github, etc.

Github Gitter

In the above OAuth authorize request, the client (Gitter) has presented the scopes to Github's OAuth endpoint to access personal user data, team data from Github for the user that authorizes. Specifically the scopes user:email,read:org.

While you, the resource owner, have authority to request information like what your email is and the organizations tied to your user are, the client (Gitter) uses delegated authorization to access your user info after completing the OAuth flow. This delegated authorization has been attenuated to the scopes user:email,read:org.

Attenuating existing delegated permissions is another story however. Imagine if Gitter wanted to delegate access to Some Forum Service to get just my icon from Github? This transitive authorization case is not supported with OAuth at this time.

Nested Delegated Attenuation

How does one restrict permissions when the one restricting is not the resource owner?

Let’s review what that blog post Macaroons are Better Than cookies! discusses:

Attenuation: Macaroons enable users to add caveats to the macaroon that attenuate how, when, and where it may be used. ... macaroons enable you to add caveats that restrict what the application can do.

So, then checking the paper Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud

Macaroon Caveats

A caveat in practice appears to be a rule that specifies a condition that clients must satisfy during an access request, this condition may be specific to the resource, the client’s access, or something global like the time of day.

These restrictions can only intersect with existing restrictions. So in the above example the target server (TS) limits chunks to 100-500. If the example forum service (FS) had imposed a caveat that only chunk 600 could be read, no chunks could be accessed as 100-500 does not intersect (or contain) the chunk 600.

So, where else have I seen this? Or some form of delegation?
Presigned requests!

Presigned Requests

You can make an html form that can upload files to S3 using normal form POST requests, but the action URL must be presigned. It contains all the details needed and a signature to specify things like: file size, content length, s3 bucket, s3 path. The client that POSTs does not have the secret credentials to perform this action, instead it is given a delegated permission set with caveats (in the form of host, path, aws service, query parameters, and some headers) and this delegation is signed by the credential user.

Unfortunately, this solution has no flexibility. With S3 presigned URLs, one cannot say “The file size must be between 0b and 100kb”, instead it can only say, the file size must be exactly this many bytes. To work within these limitations, the client that uploads the file must have a preflight request with the authorized service wherein it specifies details like file size, name, and content type; and in return receive a presigned url.


Attenuated delegation, attenuated access, attenuated permissions as a topic does not have enough documentation or examples in place. The best out there I can find in public is the Macaroons paper. For those that find this page through a search, I hope this provides enough enlightenment.