First, I don't think that's a good characterization of the talk.
Second, I'm not sure (based on the talk) that I see how they had any of the problems that Macaroons solve.
Third, I think a lot of the trouble they ran into feels like generic "we built our own token system" stuff; for instance, they backed themselves into designing a refresh token system (all their Macaroons had a third-party caveat discharged by their central Rails app, which, without any extra context, seems like a weird choice); similarly, they ran into revocation problems, which they addressed by routing all their requests through their Rails application --- these are just standard "stateless token" problems that you'd run into with a custom JWT solution as well!
(They also issued a whole bunch of long-expiry stateless tokens, and then had to wait forever to transform them to their new tokens, which is a problem every token and stateless cookie implementer has had to deal with).
I feel like they kind of went "full Macaroon", exercising all the features described in the paper, some of which weren't good fits for their problems.
We wrote a survey of auth tokens (it's linked upthread) a year or so ago, and I mentioned this talk, and I remember at the time that it made a dent with me. But we've spent a year rolling out Macaroons and gotten real-world experience with them, and in the course of writing that up I re-watched the talk and was much less persuaded by it --- in particular, I found that much of it was less a critique of Macaroons and more just a good war story about rolling out any custom stateless token scheme.
Second, I'm not sure (based on the talk) that I see how they had any of the problems that Macaroons solve.
Third, I think a lot of the trouble they ran into feels like generic "we built our own token system" stuff; for instance, they backed themselves into designing a refresh token system (all their Macaroons had a third-party caveat discharged by their central Rails app, which, without any extra context, seems like a weird choice); similarly, they ran into revocation problems, which they addressed by routing all their requests through their Rails application --- these are just standard "stateless token" problems that you'd run into with a custom JWT solution as well!
(They also issued a whole bunch of long-expiry stateless tokens, and then had to wait forever to transform them to their new tokens, which is a problem every token and stateless cookie implementer has had to deal with).
I feel like they kind of went "full Macaroon", exercising all the features described in the paper, some of which weren't good fits for their problems.
We wrote a survey of auth tokens (it's linked upthread) a year or so ago, and I mentioned this talk, and I remember at the time that it made a dent with me. But we've spent a year rolling out Macaroons and gotten real-world experience with them, and in the course of writing that up I re-watched the talk and was much less persuaded by it --- in particular, I found that much of it was less a critique of Macaroons and more just a good war story about rolling out any custom stateless token scheme.