4 ms·

So, are Macaroons are like a "blockchain", where each block is an attenuation (ie reducing permission and scopes) of the permission of the original token? So a

So, are Macaroons are like a "blockchain", where each block is an attenuation (ie reducing permission and scopes) of the permission of the original token? So a bearer can get a token, reduce its scope (without talking to the server) and pass it down to other less privileged entities. That's cool! I kind of had to look into the paper linked to really understand what they are. I feel the article could have given a bit more context on it :)

dwaite 3y ago
Somewhat. It is symmetric key based, so only the initial issuer can do verification. It is not part of a distributed data store, so there can be multiple copies (and derivatives) of a macaroon floating around. Basically, a trusted service creates an initial atom and shares it with the initial party. That trusted atom can be copied and shared. Anyone with a copy can amend additional information to it, and share those copies. Based on the copy you get, you can't remove or alter any information received. So it works best for representing restrictions - maybe my user agent gets a token that gives full access for a project. It shares a version with another service endpoint which is restricted to read-only access. That service endpoint sees it needs to kick off a background process, so it creates a version which also adds on a 4 hour time limit. None of these changes are necessarily authenticated - I don't know that it specifically was the user agent that shared the token with the service or added the read-only restriction, at least with the core tech. You have to create a domain language to specify all of these things. If you want restrictions to be authenticated, you need to describe how to sign them individually with PKI. While HMAC is fast, you still have the whole system rooted in a single trusted service that can mint any messages it wants or lie about the validity of a given message. So while it is indeed a chain of cryptographic elements, it is missing the multi-party validation and operation transparency which are the common selling points of distributed ledgers.
- tptacek 3y ago
  Biscuits have single roots of trust too. The (superficial) distinction is that Biscuits can be verified (completely) on systems that don't hold the root keys. You can't do that with a Macaroon, but, as we explain in this post, you don't have to. I don't think we'd meaningfully gain security from Biscuits --- though we would potentially get flexibility from Datalog, and our deployment story might have been a little bit simpler. (We already need hardware-isolated secret stores, so the deloyment win is probably marginal for us, but it's a bigger deal for other shops). Purely symmetric cryptography is one of the features of Macaroons. It's a reason cryptography hipsters like it, not a reason to dunk on it.
  - dwaite 3y ago
    Yep, comparing SHA2-based macaroons and ED25519-based biscuits, you'll have size and computational performance advantages for macaroons as well as post-quantum resistance. But that doesn't help you if you want to solve the network performance and failure issues with verifying macaroons. There may be strategies to solve some of the biscuit disadvantages using different signature mechanisms like BLS, but that might not help with performance and will not currently get you post-quantum resistance.
    - tptacek 3y ago
      The back half of this piece is largely about the network performance and deployment issues of Macaroons and how we addressed them. This is a real system, running in production; it isn't a proposal.
- arnarbi 3y ago
  > None of these changes are necessarily authenticated - I don't know that it specifically was the user agent that shared the token with the service or added the read-only restriction, at least with the core tech. Macaroons are very much grounded in capability thinking, where it is a “feature” that principals such as the user agent in your case don’t need to have representable identities. So there’s nobody to authenticate, except the fact that it was a holder of the previous macaroons tag, which means they had the authority it represented. In other words, not needing something like a PKI is somewhat the point of it all. If you have the need to authenticate the intermediate principals, eg because they have pre-existing identities already, then the capability model in general may just be a distraction. They could just sign their desired attentuations with their own identity key.
  - dwaite 3y ago
    One use of macaroons is to have caveats restricting the request itself used to achieve higher security than bearer tokens. This might be "only good for this service" audience restrictions or "only good for this hashed request message" as proof-of-possession. This creates a role division, where the user agent caveats before the proof-of-possession are potentially authorized differently than the ones after. It also creates the possibility that you will need to override caveats per policy, say when that message wasn't a terminal call but rather hitting an ingress to a complex internal services framework which would still like to leverage the macaroon. Basically - if a role has a requirement that they always terminate with a particular caveat, you know a section of caveats was created by software in that role. This is more of a second level of authorization than it is authentication though, I would agree.
    - arnarbi 3y ago
      In one of our iterations, we did indeed have a mandatory rule that each set of caveats added by a holder was terminated by a “sign off” caveat. But in the end we concluded that if that mattered in the actual enforcement, then one wasn’t really doing things “the capability way” and then that principal probably needed some stronger authentication than merely having held the unattenuated macaroon. But that’s theoretical thinking and the real world is indeed more shades of gray. See you in Madrid!
k__ 3y ago
Are macaroons similar to UCAN? https://ucan.xyz/ https://ucan.xyz/
kevincox 3y ago
I wouldn't use the word "blockchain" as that is primarily a tool for generating consensus. Macaroons are each independent and can be "forked" freely. So while I agree that the data structure itself is very similar the actual algorithms that are applied on top are wildly different.

dwaite 3y ago

Somewhat. It is symmetric key based, so only the initial issuer can do verification. It is not part of a distributed data store, so there can be multiple copies (and derivatives) of a macaroon floating around. Basically, a trusted service creates an initial atom and shares it with the initial party. That trusted atom can be copied and shared. Anyone with a copy can amend additional information to it, and share those copies. Based on the copy you get, you can't remove or alter any information received. So it works best for representing restrictions - maybe my user agent gets a token that gives full access for a project. It shares a version with another service endpoint which is restricted to read-only access. That service endpoint sees it needs to kick off a background process, so it creates a version which also adds on a 4 hour time limit. None of these changes are necessarily authenticated - I don't know that it specifically was the user agent that shared the token with the service or added the read-only restriction, at least with the core tech. You have to create a domain language to specify all of these things. If you want restrictions to be authenticated, you need to describe how to sign them individually with PKI. While HMAC is fast, you still have the whole system rooted in a single trusted service that can mint any messages it wants or lie about the validity of a given message. So while it is indeed a chain of cryptographic elements, it is missing the multi-party validation and operation transparency which are the common selling points of distributed ledgers.

tptacek 3y ago
Biscuits have single roots of trust too. The (superficial) distinction is that Biscuits can be verified (completely) on systems that don't hold the root keys. You can't do that with a Macaroon, but, as we explain in this post, you don't have to. I don't think we'd meaningfully gain security from Biscuits --- though we would potentially get flexibility from Datalog, and our deployment story might have been a little bit simpler. (We already need hardware-isolated secret stores, so the deloyment win is probably marginal for us, but it's a bigger deal for other shops). Purely symmetric cryptography is one of the features of Macaroons. It's a reason cryptography hipsters like it, not a reason to dunk on it.
- dwaite 3y ago
  Yep, comparing SHA2-based macaroons and ED25519-based biscuits, you'll have size and computational performance advantages for macaroons as well as post-quantum resistance. But that doesn't help you if you want to solve the network performance and failure issues with verifying macaroons. There may be strategies to solve some of the biscuit disadvantages using different signature mechanisms like BLS, but that might not help with performance and will not currently get you post-quantum resistance.
  - tptacek 3y ago
    The back half of this piece is largely about the network performance and deployment issues of Macaroons and how we addressed them. This is a real system, running in production; it isn't a proposal.
arnarbi 3y ago
> None of these changes are necessarily authenticated - I don't know that it specifically was the user agent that shared the token with the service or added the read-only restriction, at least with the core tech. Macaroons are very much grounded in capability thinking, where it is a “feature” that principals such as the user agent in your case don’t need to have representable identities. So there’s nobody to authenticate, except the fact that it was a holder of the previous macaroons tag, which means they had the authority it represented. In other words, not needing something like a PKI is somewhat the point of it all. If you have the need to authenticate the intermediate principals, eg because they have pre-existing identities already, then the capability model in general may just be a distraction. They could just sign their desired attentuations with their own identity key.
- dwaite 3y ago
  One use of macaroons is to have caveats restricting the request itself used to achieve higher security than bearer tokens. This might be "only good for this service" audience restrictions or "only good for this hashed request message" as proof-of-possession. This creates a role division, where the user agent caveats before the proof-of-possession are potentially authorized differently than the ones after. It also creates the possibility that you will need to override caveats per policy, say when that message wasn't a terminal call but rather hitting an ingress to a complex internal services framework which would still like to leverage the macaroon. Basically - if a role has a requirement that they always terminate with a particular caveat, you know a section of caveats was created by software in that role. This is more of a second level of authorization than it is authentication though, I would agree.
  - arnarbi 3y ago
    In one of our iterations, we did indeed have a mandatory rule that each set of caveats added by a holder was terminated by a “sign off” caveat. But in the end we concluded that if that mattered in the actual enforcement, then one wasn’t really doing things “the capability way” and then that principal probably needed some stronger authentication than merely having held the unattenuated macaroon. But that’s theoretical thinking and the real world is indeed more shades of gray. See you in Madrid!

k__ 3y ago

Are macaroons similar to UCAN? https://ucan.xyz/ https://ucan.xyz/

kevincox 3y ago

I wouldn't use the word "blockchain" as that is primarily a tool for generating consensus. Macaroons are each independent and can be "forked" freely. So while I agree that the data structure itself is very similar the actual algorithms that are applied on top are wildly different.