|
|
|
|
|
by arnarbi
869 days 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. |
|
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.