5 ms·

Surprised to see JSON here. I recall discussing JWT with tptacek a few years ago, and one of the concerns was the {a: x, a: y} ambiguity in JSON parsers. Was th

by fovc 3y ago

Surprised to see JSON here. I recall discussing JWT with tptacek a few years ago, and one of the concerns was the {a: x, a: y} ambiguity in JSON parsers. Was that a concern with this design? My other reaction was that this sounds scary: > a token with no caveats restricts nothing. It’s a god-mode token. Don’t honor it. I guess it's technically "fail closed" but seems kind of brittle

tptacek 3y ago
I think it becomes more obvious later in the post that the Python code here is for illustrative purposes only. We don't use JSON. Our actual tokens are strictly typed. But also: it doesn't matter that much, because all of the predicates in a Macaroon are evaluated independently. There's no opportunity to confuse a previous caveat with a subsequent one. That's one of the strengths of having a rigidly coherent design like Macaroons, rather than just a bag of keys and values like JWTs do.
- fovc 3y ago
  Ah thanks for clarifying! I knew the code was illustrative but didn't realize the JSON part was too
hinkley 3y ago
The XML digital signature spec had that problem in spades. It took us about five times as long to button it down as it did to implement. By the time I was done with that project, the document for partners and vendors (if anyone wanted to implement their own instead of using ours) was several times longer than the spec, what with all the extra MUST and MUST NOT situations. Which is not that hard when you're dealing with swiss cheese. Document.findById and Element.findById being able to return different (non-null) results being the most egregious one I can remember.
- dwaite 3y ago
  XML is a disaster here all of its own, but is at least unambiguous at the parser level. JSON says "if your document does this, parser behavior is undefined". So you need to declare that the parser used should behave in particular ways. Both are best solved a robust specification and supplemental test vectors. If you define meta rules (e.g. JSON parsers must either fail or return the last object property), you still retain the value you hoped for by using something like JSON or XML in the first place.
  - hinkley 3y ago
    Isn't it Turing Complete with namespaces? (that's another thing on the SHALL NOT list). Can't be unambiguous if you don't halt.
    - dwaite 3y ago
      Turing complete? Not really, parsing still forms static data structures in linear time. The fundamental screw-up with XML is that it was a textual markup format (e.g. HTML or word processor documents) that got usurped for cross platform data transfer. Among many other problems, that put pressure on its design to be unambiguous to generalized tools - which wasn't an initial design consideration. So you had an awful lot of making people use document markup processing tools to serialize and parse data structures, schema and transform systems that tried to target both mindsets and did a bit of a poor job at each, and lots and lots of abstractions to try to make it so you only had to deal with the problem once. Even JSON is a bit of a pain the farther away from late-bound or untyped scripting languages you get.

by fovc 3y ago

tptacek 3y ago

I think it becomes more obvious later in the post that the Python code here is for illustrative purposes only. We don't use JSON. Our actual tokens are strictly typed. But also: it doesn't matter that much, because all of the predicates in a Macaroon are evaluated independently. There's no opportunity to confuse a previous caveat with a subsequent one. That's one of the strengths of having a rigidly coherent design like Macaroons, rather than just a bag of keys and values like JWTs do.

fovc 3y ago
Ah thanks for clarifying! I knew the code was illustrative but didn't realize the JSON part was too

hinkley 3y ago

The XML digital signature spec had that problem in spades. It took us about five times as long to button it down as it did to implement. By the time I was done with that project, the document for partners and vendors (if anyone wanted to implement their own instead of using ours) was several times longer than the spec, what with all the extra MUST and MUST NOT situations. Which is not that hard when you're dealing with swiss cheese. Document.findById and Element.findById being able to return different (non-null) results being the most egregious one I can remember.

dwaite 3y ago
XML is a disaster here all of its own, but is at least unambiguous at the parser level. JSON says "if your document does this, parser behavior is undefined". So you need to declare that the parser used should behave in particular ways. Both are best solved a robust specification and supplemental test vectors. If you define meta rules (e.g. JSON parsers must either fail or return the last object property), you still retain the value you hoped for by using something like JSON or XML in the first place.
- hinkley 3y ago
  Isn't it Turing Complete with namespaces? (that's another thing on the SHALL NOT list). Can't be unambiguous if you don't halt.
  - dwaite 3y ago
    Turing complete? Not really, parsing still forms static data structures in linear time. The fundamental screw-up with XML is that it was a textual markup format (e.g. HTML or word processor documents) that got usurped for cross platform data transfer. Among many other problems, that put pressure on its design to be unambiguous to generalized tools - which wasn't an initial design consideration. So you had an awful lot of making people use document markup processing tools to serialize and parse data structures, schema and transform systems that tried to target both mindsets and did a bit of a poor job at each, and lots and lots of abstractions to try to make it so you only had to deal with the problem once. Even JSON is a bit of a pain the farther away from late-bound or untyped scripting languages you get.