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

[Raphael Robert <[e-mail]>]

> On 8. Apr 2024, at 20:52, Tommy Pauly <tpauly=[e-mail]> wrote:
> 
> 
> 
>> On Apr 8, 2024, at 11:37 AM, Raphael Robert <ietf=[e-mail] <mailto:ietf=[e-mail]>> wrote:
>> 
>> Thanks for the issue, I’ll take a look.
>> 
>> Regarding the question of the redemption being the same – I think that’s only true for the P-384 batched tokens, but not the ristretto255 variant. 
> 
> For ristretto255 is that just because there isn’t a non-batched variant? Could there ever be a non-batched variant?

Yes to the former. As for the latter – in theory there could be, but from what I understand it wasn’t included in the base spec because it wasn’t sufficiently different from the P-384 variant and had an additional security consideration. 

For the batched tokens it made sense to include it because the batched tokens are all about improving efficiency. 

Raphael 

> 
> Thanks,
> Tommy
> 
>> 
>> I will cut a new draft shortly once I looked at the issue, sorry for being slow here.
>> 
>> Thanks
>> 
>> Raphael
>> 
>>> On 8. Apr 2024, at 17:36, 'Tommy Pauly' via ietf <[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?
>>> 
>>> 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
>>> 
>> 
>> -- 
>> Privacy-pass mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/privacy-pass