Re: [Privacy-pass] Working group last Call for batched Tokens

[Tommy Pauly <[e-mail]>]

> On Apr 8, 2024, at 9:50 AM, Christopher Wood <[e-mail]> wrote:
> 
> 
> 
>> On Apr 8, 2024, at 11:36 AM, Tommy Pauly <[e-mail]> wrote:
>> 
>> Also chiming in for a review — I just read through the draft and it looks good to me. I didn’t see any particular flaws that I would say need addressing before publication. I filed one very minor editorial issue https://github.com/ietf-wg-privacypass/ietf-draft-privacypass-batched-tokens/issues/8
>> 
>> I did have one overall question about our approach to token types and batching: this new batched VOPRF allocates a new token type, although my understanding is that the redemption step doesn’t necessarily need to know anything about it being batched in order to validate the token. To what degree do we want changes to the issuance that don’t impact the nature of the token upon redemption to be reflected in the token type vs some other difference in the request (such as media type, etc, etc)? Is there a security reason that the redeemer needs to know?
> 
> The redeemer does not need to know that issuance was fetched using a batched version of the protocol. However, since we chose to reuse the TokenRequest structure for issuance, we needed a distinguisher for the issuer to know that a batch was being requested. That ended up being the token type. We could have introduced a new BatchTokenRequest structure, with a new media type, for issuance, but that didn’t happen. I recall having this discussion at some point in the past, but I didn’t look to where it took place (on the list, GitHub, or during a meeting). In any case, we can change this, but I don’t feel strongly about it, except maybe that knowing a client supports batched and non-batched issuance could be a way to partition the client anonymity set for a redemption context. (Okay, maybe that’s a reason to change!)

Right — if this is a way to segment clients, it’s not great. I’m thinking a bit of the precedent we’re setting here, too. If we end up always exposing a change in the issuance path as a new type to the redemption side, we’re exposing new bits unless all clients are doing the same approach. If this works equally well with using existing token types and using a different media type to the issuer, then that may be a better solution.

Tommy

> Best,
> Chris 
> 
>> 
>> Tommy
>> 
>>> On Apr 7, 2024, at 9:02 PM, Joseph Salowey <[e-mail]> wrote:
>>> 
>>> RIght now we only have one response to the last call which is not enough to call consensus on.   It would be good to have a draft that is not expired, but I also think before we can continue a consensus call we need a draft with all the outstanding changes as well.  
>>> 
>>> Thanks,
>>> 
>>> Joe
>>> 
>>> On Wed, Mar 20, 2024 at 3:37 AM Raphael Robert <[e-mail] <mailto:[e-mail]>> wrote:
>>>> As soon as that issue is resolved I’ll make one more editorial pass before I cut a new draft. I’ll announce it here.
>>>> 
>>>> Raphael
>>>> 
>>>>> On 20. Mar 2024, at 06:23, Steven Valdez <svaldez=[e-mail] <mailto:[e-mail]>> wrote:
>>>>> 
>>>>> I think this draft looks mostly good and I support it going to the IESG. There is one outstanding issue #6 <https://github.com/ietf-wg-privacypass/ietf-draft-privacypass-batched-tokens/issues/6> (I submitted and forgot to follow up on) regarding adding the VOPRF variant as a defined type since we're relying on that variant for PST. I can try to get a PR for that submitted, though not sure what the ordering between the draft being expired, the WGLC and cutting a new draft should look like?
>>>>> 
>>>>> -Steven
>>>>> 
>>>>> On Mon, Mar 11, 2024 at 2:47 PM Joseph Salowey <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>> This is the working group last call for Batched Token Issuance Protocol (https://datatracker.ietf.org/doc/draft-ietf-privacypass-batched-tokens/).  Please review the document and indicate if it is ready to forward to the IESG by posting comments to this thread.  The internet draft is about to expire but should still be accessible.  Please send your comments by March 26, 2024.  
>>>>>> 
>>>>>> Thanks,
>>>>>> 
>>>>>> Joe and Ben
>>>>>> -- 
>>>>>> Privacy-pass mailing list
>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>> https://www.ietf.org/mailman/listinfo/privacy-pass
>>>>> 
>>>>> 
>>>>> --
>>>>> 
>>>>>  Steven Valdez |	 Chrome Privacy Sandbox |	 [e-mail] <mailto:[e-mail]> |	 Cambridge, MA
>>>>> -- 
>>>>> Privacy-pass mailing list
>>>>> [e-mail] <mailto:[e-mail]>
>>>>> https://www.ietf.org/mailman/listinfo/privacy-pass
>>>> 
>>> -- 
>>> Privacy-pass mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/privacy-pass
>>