Attenuated Delegation - 2021-06-02
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”.
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.
So I asked! And thankfully I received a response--although not on the mailing list.
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.
The above image is from
ScreamyShepardon twitter, it comes from this tweet
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.
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.
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
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
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
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.
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.