Macaroons are a bearer credential format: http://theory.stanford.edu/~ataly/Papers/macaroons.pdf
I think the Macaroons format is in general rather LANGSEC friendly: it uses git pkt-lines, which have a 4-byte hexadecimal length prefix followed by a "binary-safe" line of data. I believe this qualifies as context-free? There are interoperable libraries for many programming languages which implement the format, but I've felt the APIs provided by these libraries are fairly low-level, and have been trying to expose a higher-level API which handles type coercion and serialization. The main thing I've being trying to add in Boulangerie, my high-level "opinionated" Macaroons library, is a schema language and a set of types used to represent serialized data: https://github.com/cryptosphere/boulangerie/wiki/Types tl;dr: somewhat like an S-expression per git pkt-line, but where nested lists are not allowed. In defining these I've generally tried to restrict expressive power. The resulting language has no way to represent nested lists, for example. It might seem rather tempting to add "(" ")" and allow nested lists (and the existing syntax is amenable to that), perhaps even throwing out the git pkt-line part of it and representing the entire Macaroon with S-expressions, but at least for now I'm specifically trying to avoid that. Likewise there is (not yet) any string type and therefore no potential for string escaping vulnerabilities. I think overly expressive language formats have been a big problem with bearer credential formats in the past. The worst offender is probably SAML, with repeated XXE remote code execution vulnerabilities due to the use of XML. But I can see how the absence of certain features could simply lead people to create bad ad hoc solutions which would limit interoperability and also add potential for people to reintroduce the classes of vulnerabilities I'm trying to avoid. I'm working within the constraints of pkt-lines and trying to find the minimum amount of expressive power needed to cover the majority of use cases (i.e. finding the sweet spot between security and expressiveness) I think elsewhere there's a push to revive a (previously defunct) alternative version of the format which used JSON instead of pkt-lines to handle similar use cases. Anyway, thoughts? -- Example schema file (I'm using YAML for describing schemas for now, and supporting extensible versioned schemas): schema-id: ee6da70e5ba01fec predicates: v0: not-before: DateTime expires: DateTime blobby: Binary booleany: Boolean boolean-list: List(Boolean) datetime-list: List(DateTime) v1: another-booleany: Boolean v2: decimal-list: List(Decimal) atom-list: List(Atom) v3: uri-list: List(URI) -- Example serialized Macaroon: 0029location https://mysupercoolsite.com 0076identifier v:0 uuid:4213ce9f-1149-44e8-a8cb-ff47d8aff25c kid:key1 sch:7dc57277e5b399ac@0 iat:2016-01-09T23:52:16Z 0026cid expires: 2016-01-09T23:52:21Z 0029cid not-before: 2016-01-09T23:52:16Z 002fsignature [...] -- Tony Arcieri
_______________________________________________ langsec-discuss mailing list langsec-discuss@mail.langsec.org https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss
