Others have answered correctly (it was an arbitrary choice), but fwiw I always found it helpful to think of current as the direction of the “holes” where electrons can be.
Like bubbles rising in water, the holes “travel” opposite the potential that’s pulling the surrounding electrons the other way.
> 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.
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.
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.
(author of the paper in your second link, which the Biscuit spec also references)
Macaroons are an abstract thing. They don't define an encoding format, nor any semantics or language for the caveats. So a lot of detail is left up to the implementer, which is why they're fairly hard to use. Their basic form is also built on symemtric keys and hmacs, so only the issuer can verify, which is a significant limitation in the real world.
AFAICT Biscuits define those (protobuf for encoding, a logic language for the caveats) and use public keys instead to allow other parties than the issuer (=holder of the root key) to verify them.
That abstraction is also a strength. I think one of the reasons Macaroons really resonate with security engineers is that the underlying cryptography is simple and user-proof, and the resulting formats and protocols are super flexible†, which is not a combination you typically get with cryptosystems. It's also one of the truly great security papers; having worked with a team for a year scaling them out, I get something new every time I read it. My only quibble is the internal naming ("CID", "VID").
We're doing a big-ass blog post as we speak about how our Macaroon tokens work, and it covers how we worked around the issuer/verifier constraint (spoiler: a litefs-backed replicated isolated internal API) and we did basic stuff like encoding (spoiler: we defined a rigid struct schema, and just MsgPack'd it).
One of the things I think I have to say about Macaroons is that there's a sliding scale of how much you use it; I think there are some simple ideas in them that would be pretty neat in any application's authentication cookie scheme.
† Also one of a couple reasons, I think, that "standard Macaroons" and their associated libraries never went anywhere.
Very much looking forward to the blog post! At G we’ve relied on some existing key replication APIs and the caveats have just been the simplest possible and rigid protobufs for each application.
(And thanks! I’m still citing your Velvet Underground comparison.)
I’m very intrigued and excited about this! I read your earlier post comparing schemes and saying after years beating the drum for macaroons, after trying to implement them, you wouldn’t beat that drum any more. Have you come back around?
There isn’t encryption nor a generated password involved with passkeys. Rather, your device generates a private key and stores it in your password manager - and only the public key is sent to the server.
When you log in later, the server uses an API to give your client a random unique challenge (just some bytes), you unlock and approve and the pwm signs some stuff including the challenge and sends the signature back. The server verifies with the public key, and is satisfied because only your private key could’ve generated that signature.
But you are exactly right - this is detail and the UX is essentially the same as having the pwm generate random passwords that you never get to see or copy.
There isn't encryption involved? I mean how can you use public and private keys without encryption?
Anyways yes, I agree otherwise. That said for all intents and purposes, the private key is a password. It’s the thing you store that gives you access to the service. That it’s not transmitted, but instead the whole public key / challenge response dance is done, is IMO sufficiently well summarized as “well, it’s a special kind of autogenerated password, which can’t be insecurely transmitted or badly stored by the service”.
If we really want people to adopt passkeys we gotta begin talking about them in terms people understand. I consider myself pretty tech savvy and it took me like 6 articles until I finally grokked that a passkey is just an autogenerated password (plus some free automatic bonus security that doesn’t affect my UX)
Important to emphasize that passkeys are phishing resistant. Unlike passwords that allow you to copy and paste them to a website (hmm, auto complete isn’t working on this broken website, I can just go find it and paste it in — boom phished).
You can still use your password today on a Google account with passkeys. And account recovery via other means (depending on a lot of things) is still available.
It's too early to completely replace all methods with passkeys, but the hope is that as they gain better support and understanding websites will be able to make other methods rare/exceptional. For exceptional cases such as account recovery, as opposed to day-to-day account sign-in, there is room to apply a lot of other abuse signals and other methods to make it harder for attackers.
Like bubbles rising in water, the holes “travel” opposite the potential that’s pulling the surrounding electrons the other way.