W3C home > Mailing lists > Public > public-interledger@w3.org > November 2016

Re: TJSON

From: Stefan Thomas <stefan@ripple.com>
Date: Thu, 03 Nov 2016 20:41:28 +0000
Message-ID: <CAFpK0Q36vf9VyfVusuVj1NSMe0rvDN5vSdFEUPbfRDcAykoP9Q@mail.gmail.com>
To: Tony Arcieri <bascule@gmail.com>
Cc: Shane McCarron <shane@spec-ops.io>, Anders Rundgren <anders.rundgren.net@gmail.com>, Adrian Hope-Bailie <adrian@hopebailie.com>, Interledger Community Group <public-interledger@w3.org>
> There's a domain separation concern if you don't always add a tag: it no
longer becomes possible to encode strings which legitimately end with a
given postfix.

My solution to that would be to always put the tag in the key, never in the
value.

Then the problem is only to find a separator that is unlikely to appear in
keys naturally. I think there are many good choices, colons seem fine to me.

On Thu, Nov 3, 2016 at 12:11 PM Tony Arcieri <bascule@gmail.com> wrote:

> On Thu, Nov 3, 2016 at 11:15 AM, Stefan Thomas <stefan@ripple.com> wrote:
>
> Why do I have to add a ton of tags? Why not just:
>
> {
>   "count": 5,
>   "key:b64":  "AANFJzysAFsbashj==",
>   "message": "Hello!"
> }
>
>
> There's an alternative syntax proposal here which is quite similar:
>
> https://github.com/tjson/tjson-spec/issues/30
>
>
> I.e. tag the fields where your default guess of the type would be wrong
> and leave the rest of the fields as-is.
>
>
> There's a domain separation concern if you don't always add a tag: it no
> longer becomes possible to encode strings which legitimately end with a
> given postfix. This could, among other things, be exploited by an attacker
> to change how strings are interpreted, provided the attacker can control
> the key.
>
> I would prefer not to have that sharp edge.
>
> --
> Tony Arcieri
>
Received on Thursday, 3 November 2016 20:42:11 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 3 November 2016 20:42:12 UTC