Macaroons 很快就升级了
Macaroons——一种带有 caveat 的加密授权令牌——正在被研究为传统 cookie 和 JWT 的灵活替代方案，尤其适合分布式系统中的委派和细粒度访问控制。评论者讨论了基于对称 HMAC 的 macaroons 与 Biscuits 或 JWT 等非对称方案之间的权衡，涉及性能、密钥管理、撤销以及中心化验证的运维成本。与此同时，读者注意到 “macarons” 与 “macaroons” 在命名和图像上的持续混淆，凸显了即便是术语本身也会让新安全机制的采用变得复杂。
Macaron vs. Macaroon（以及其他语言岔题）
- 大量子讨论聚焦于 macarons（法式蛋白霜“夹心”饼干）和 macaroons（椰丝球）之间的区别。
- 有人指出博客图片里显示的是 macarons，而令牌方案却叫做 “macaroons”；有些人把 “French macaroon” 视为可接受的同义词，另一些人则坚持这只是错误。
- 讨论进一步扩展到语言漂移：entrée 在美国英语中意为“主菜”、英国菜单里的 “mains”、以及 “macarrons/macaroni/maccheroni” 作为意大利面，还有关于 “Macron/micron/mâcon/maçon” 的玩笑。
- 有人把这种命名混乱看作一种俏皮的营销；也有人认为明知已有混淆还选择 “macaroon” 是个糟糕的决定。
将 Macaroons 作为认证令牌：设计、权衡与比较
- 多条评论重申，macaroons 是一种持有者令牌，可以在不联系发行方的情况下被削弱和委派，常被宽泛地类比为某种“链”，但明确不是区块链。
- 重点强调的是能力模型：权力来自持有令牌，而不是身份；这被视为一种特性，但会使经过认证的委派和审计变得复杂。
- 提出的担忧包括：单一对称根密钥、密钥轮换、需要在线验证、撤销、速率限制，以及对派生令牌进行中心化审计的困难。
- 文章中的部署使用了一个充当软件 HSM 的验证服务；这被描述为缓解了对称密钥风险，并让 Biscuits（基于公钥的方案）在这里不那么有吸引力。
- 与 Biscuits、UCAN、JWT、Zanzibar 以及 “runes” 的比较：macaroons 在简单性、速度和后量子友好性方面占优；biscuits 和类似系统在离线验证和更丰富的策略逻辑方面占优。
- 有人认为削弱/委派应被更广泛地使用；也有人认为对于简单的 CRUD 应用来说，macaroons 过于复杂。
实现细节、UX 与文档
- 澄清博客中的 Python 是伪代码；真实系统使用有类型的格式、AEAD、类似 Noise/mTLS 的通道，以及严格的 caveat 处理。
- 读者希望对“玩具”与“生产”代码有更清晰的标识，并对 HMAC、attenuation 以及前文有更多背景说明。
- 有人称赞文字和插图；也有人觉得语气偶尔有点“圈内术语太多”。
- 关于 Fly.io DX 的旁支讨论：数据库机器、凭据以及环境变量访问引发了困惑，这与一种刻意的安全模型有关，该模型把密钥视为 “hazmat”。
专利与法律顾虑
- 有人提到 Google 对 macaroons 的专利；一些人因此出于担心侵权而回避了这项技术。
- 另一些人则指出 Google 的不侵略承诺以及“防御性专利”的常见做法，但这些承诺在法庭上究竟有多大约束力并不明确。