incomplete

Given that source queries have a single source site and trigger queries have a single trigger site, you could start by indicating the type of query (which can be implicit or part of the query creation step), then you can have two tables: one for the "same" side (source configurations for source queries, trigger configurations for trigger queries) and one for the "other" side (the converse). Then you could concatenate the two tables, index rows starting from zero and refer to the configurations.

Each row in the table would then effectively be a configuration that lists:

1. Site: length prefixed ASCII; 1 byte length. Optimization hack: length = 0 copies the previous value.
2. Epoch: 2 bytes.
3. Key identifier: 1 byte.

There are three implied values that fill out the common stuff:

1. (implied) Event type is inferred from the table type, so this is effectively run-length encoded.
2. (implied) The match key provider should be the same for all events, so that can be part of query configuration.
3. (implied) The helper party should know its own name, so that can be omitted completely.

Indexing into this table shouldn't take too many bytes. But I don't think that a 1 byte is going to work out in all cases. But the table size is known before you start processing individual items, so we can make the index size based on the table size ($\lceil log_2(t)/8 \rceil$).

RFC 6648.

We need a format for creating a query, which needs to include these values somehow. I would not use header fields for this, but instead define a payload format. This doesn't need to be tightly packed, so JSON is probably where I would go.

Also, some of this is information that could be part of the resource identity. That is, you would have one URI that does IPA and another that does something different. That means that you don't need to include explicit versioning.

Parameters are only necessary if you think that something needs tuning, or there are things that need to be known in order to accept the query. I think that we should directly signal the query size in this request as that has a direct bearing on what is being requested.

IPA already has a bunch of parameters that we have built into our implementation:

• The number of breakdown keys.
• The maximum value of individual trigger values.
• The per-user cap.
• The attribution window.

These are what I would expect to see in the request that creates a query.

I think that you need to spell out assumptions here. Something like:

• enc = 32
• ciphertext = 2*40/8 = 10
• tag = 16
• site = 1 + 50 (say)
• key id = 1
• epoch = 2
• breakdown key = 1 (assuming XOR shares here and a small space, not sure about state of the art)
• trigger value = 4
• ts = 4 (not sure here again)

That's a little more than you have.

But with a table, and if we make breakdown key and trigger value mutually exclusive (and the same size), then we have 68 bytes, plus the table size, which is trivial for a large data set.

The other thing with tables is that you can reuse them...

Why are we choosing http instead of tls here?

"over" here means that the one protocol layer (HTTP) runs on top of the other (TLS). It doesn't mean "instead of", even though that is another meaning that "over" can take, it isn't the usual assumption in this context.

oh ok.. maybe we should reword it to say "on top of" TLS to avoid confusion?

heh, I never read it that way - too used to this expression. I agree that it does sound confusing, so I'll just use HTTPS instead.

"HTTP over TLS" is the name of the protocol. Or "HTTPS". To call it something else would be far worse.

Didnt know about that. How about we add a link to RFC for it : https://www.rfc-editor.org/rfc/rfc2818