Compressing serialized Macaroons?

[Akram Shehadi]

Hello!

I'm working on an idea about using macaroons instead of access tokens, and if I follow the general idea of using one macaroon to restrict access to only one "item" (e.g. an endpoint), it's very easy to see that after adding a few first party caveats (FPCs) as well as some third-party ones (TPCs), we can end up sending a few KBs of data.

After very limited research and testing, it turns out that browsers support cookies with a max size of ~4KB, which is a limit that could be somewhat easily reached if e.g. I use UUIDs for identifiers.

For example, after serializing a macaroon with 4 FPCs and 2 TPCs, I get around 700 bytes. If I create a macaroon with 6 FPCs and 4 TPCs using UUIDs copiously, I get ~1.4KB easily.

My question is then, is it worth to look into compressing macaroons?

Or is it better to instead store them in localStorage for example? (although that has it's own issues regarding browser support etc)

Has anyone given some thought about this problem or is this perhaps a non-problem?

Thanks!

Akram

[roger peppe]

On Thu, 8 Nov 2018 at 03:17, Akram Shehadi <akram....@gmail.com> wrote:

Hello!

I'm working on an idea about using macaroons instead of access tokens, and if I follow the general idea of using one macaroon to restrict access to only one "item" (e.g. an endpoint), it's very easy to see that after adding a few first party caveats (FPCs) as well as some third-party ones (TPCs), we can end up sending a few KBs of data.

After very limited research and testing, it turns out that browsers support cookies with a max size of ~4KB, which is a limit that could be somewhat easily reached if e.g. I use UUIDs for identifiers.

For example, after serializing a macaroon with 4 FPCs and 2 TPCs, I get around 700 bytes. If I create a macaroon with 6 FPCs and 4 TPCs using UUIDs copiously, I get ~1.4KB easily.

My question is then, is it worth to look into compressing macaroons?

I you're using large random UUIDs, then I suspect you won't see any compression gains.

What format are you using for your macaroon encoding? The binary encoding has become quite a bit more space-efficient since the original.

 

Or is it better to instead store them in localStorage for example? (although that has it's own issues regarding browser support etc)

Has anyone given some thought about this problem or is this perhaps a non-problem?

We have definitely had issues with macaroon size in the past, which is why I put some effort into designing the new binary format and pushing that forward into the various implementations.

 

  cheers,

    rog.

[Akram Shehadi]

On Thursday, November 8, 2018 at 6:45:05 AM UTC-6, roger peppe wrote:

On Thu, 8 Nov 2018 at 03:17, Akram Shehadi <akram....@gmail.com> wrote:

Hello!

I'm working on an idea about using macaroons instead of access tokens, and if I follow the general idea of using one macaroon to restrict access to only one "item" (e.g. an endpoint), it's very easy to see that after adding a few first party caveats (FPCs) as well as some third-party ones (TPCs), we can end up sending a few KBs of data.

After very limited research and testing, it turns out that browsers support cookies with a max size of ~4KB, which is a limit that could be somewhat easily reached if e.g. I use UUIDs for identifiers.

For example, after serializing a macaroon with 4 FPCs and 2 TPCs, I get around 700 bytes. If I create a macaroon with 6 FPCs and 4 TPCs using UUIDs copiously, I get ~1.4KB easily.

My question is then, is it worth to look into compressing macaroons?

I you're using large random UUIDs, then I suspect you won't see any compression gains.

What format are you using for your macaroon encoding? The binary encoding has become quite a bit more space-efficient since the original.

I am using Evan Cordell's PyMacaroons, and after checking the source code it would appear it's the binary encoding that is being used.

 

Or is it better to instead store them in localStorage for example? (although that has it's own issues regarding browser support etc)

Has anyone given some thought about this problem or is this perhaps a non-problem?

We have definitely had issues with macaroon size in the past, which is why I put some effort into designing the new binary format and pushing that forward into the various implementations.

I used the python implementation of zstd and I got the serialized macaroon compressed to about 70%, which is not terribly much but I guess it's something.

So I guess macaroons are by nature a bit bigger and we'll have to work with that regardless, e.g. by using localStorage preferably (at least in browser-based clients)

 

 

  cheers,

    rog.

[Akram Shehadi]

On Thursday, November 8, 2018 at 10:15:00 PM UTC-6, Akram Shehadi wrote:

On Thursday, November 8, 2018 at 6:45:05 AM UTC-6, roger peppe wrote:

On Thu, 8 Nov 2018 at 03:17, Akram Shehadi <akram....@gmail.com> wrote:

Hello!

I'm working on an idea about using macaroons instead of access tokens, and if I follow the general idea of using one macaroon to restrict access to only one "item" (e.g. an endpoint), it's very easy to see that after adding a few first party caveats (FPCs) as well as some third-party ones (TPCs), we can end up sending a few KBs of data.

After very limited research and testing, it turns out that browsers support cookies with a max size of ~4KB, which is a limit that could be somewhat easily reached if e.g. I use UUIDs for identifiers.

For example, after serializing a macaroon with 4 FPCs and 2 TPCs, I get around 700 bytes. If I create a macaroon with 6 FPCs and 4 TPCs using UUIDs copiously, I get ~1.4KB easily.

My question is then, is it worth to look into compressing macaroons?

I you're using large random UUIDs, then I suspect you won't see any compression gains.

What format are you using for your macaroon encoding? The binary encoding has become quite a bit more space-efficient since the original.

I am using Evan Cordell's PyMacaroons, and after checking the source code it would appear it's the binary encoding that is being used.

I meant to say I'm using version 2 serialization of PyMacaroons, which I think it's the one you were talking about.

Cheers,

Akram