[Privacy-pass] Re: Request for agenda time for draft-ietf-moq-privacy-pass-auth-00

[Tommy Pauly <[e-mail]>]

(CC’ing MOQ list too)

Hi Cullen,

Thanks for sharing this document! It looks like the document may not have made it onto the Privacy Pass agenda, but I wanted to share some initial review feedback.

For those following along on the Privacy Pass side, the current document is draft-ietf-moq-privacy-pass-auth-01 (https://www.ietf.org/archive/id/draft-ietf-moq-privacy-pass-auth-01.html)

Overall, I think the document is going in a good direction and using the tokens well. I appreciate the updated diagrams — there had been a few issues in the individual draft that are sorted out now.

Some technical questions:

1. Are the tokens being used here “cacheable” so the client could potentially get multiple equivalent tokens and spend them over time, or are they strictly unique based on challenges? See token caching discussion in https://www.rfc-editor.org/rfc/rfc9577.html#section-2.1.4 and https://www.rfc-editor.org/rfc/rfc9576.html#section-7.1. Specifically, if the tokens should not be cachable, then the needs to include an unpredictable redemption_context. Currently, the text allows it to be empty.

2. Sections 3.2 and 3.3 discuss using the origin_info to associate matching for tracks and metadata. I want to point out that the challenge details are not visible to the token issuer, and are also not visible on redemption normally — just a hash of the challenge is at that point in the typical construction. It’s possible to also include the information on redemption, but that should be spelled out explicitly if so. The text in 3.3.3 mentions "Extract the MoQ-specific authorization scope from the token's origin_info field”, which isn’t normally possible. Can you help describe the flow you’re thinking of for who needs to check this information, and what they need to check it against?

3. The draft discusses the challenge format, but doesn’t explicitly mention the format the token is sent in for token redemption (the equivalent to https://www.rfc-editor.org/rfc/rfc9577.html#name-token-structure) In general, I see this document as the MOQ binding for tokens, whereas RFC 9577 is the HTTP authentication binding. As such, it might be nice to also explain how and where these challenges and tokens go within the MOQ protocol bits.

4. Minor: In Section 2.2, there is discussion of bootstrapping tokens, and then having more tokens generated based on those. This is a pattern that’s being somewhat common, so good to see more use here. The text says that type 2 is used for bootstrap, and then privately verifiable types are used later. While this is fine, I think that type 2 can also work for the later type. The text could allow that in the example.

Thanks,
Tommy


> On Oct 15, 2025, at 4:55 PM, Cullen Fluffy Jennings <[e-mail]> wrote:
> 
> I would like to request 10 minutes to get feedback about:
> 
> draft-ietf-moq-privacy-pass-auth-00
> 
> This draft uses privacy pass tokens for Media Over Quic ( MoQ ). It does not need any changes to privacy pass tokens, but we would greatly appreciate the input and review of the privacy pass WG. 
> 
> Thanks, Cullen
> 
> Note: draft-ietf-moq-privacy-pass-auth-00 is not out yet but it will get published by the deadline. It will be an updated version of draft-jennings-moq-privacy-pass-auth-00
> 
> 
> -- 
> Privacy-pass mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]