> Bob will still have to hit our login service to "activate" the token. I think thats what I was saying - on first verify your centralized system will know the

> Bob will still have to hit our login service to "activate" the token. I think thats what I was saying - on first verify your centralized system will know the contents of the token and can do appropriate auditing. In practice I find that keeping processing simple is a challenge. It doesn't naturally say as simple as one would like, with orthagonal caveats that can be processed independently and independent of centralized knowledge. For example, you might expect the user to indicate the system they are calling in a caveat, an audience value. However, if you either make this true a restriction on further use it will prevent any sort of delegation, which may include delegation to internal systems that the user didn't know about. You don't want to outright ignore it either. So you have some sort of policy interpretation of that restriction, such as 'this audience means this set of services can use this macaroon' or 'we will audit internal use based on this audience but take no action', or even crazier you color caveats before and after this point as being ones set by the user vs ones set by the service. This sounds a bit contrived, but it does loop back into one of the core usages I've seen for macaroons - gaining proof of possession or other sender verification rather than using bearer-style tokens.