From: Tommy Pauly <tpauly@apple.com>
Message-id: <830ECEA5-41B5-49BD-9187-4561F12A9BFB@apple.com>
Content-type: multipart/alternative;
 boundary="Apple-Mail=_45655932-7024-4E3E-8E81-EC7F10218C96"
MIME-version: 1.0 (Mac OS X Mail 16.0 \(3864.200.42\))
Date: Sun, 02 Nov 2025 08:56:45 -0500
In-reply-to: <6A00AFD1-9205-4D4A-9D62-9B40460947B3@iii.ca>
To: Cullen Fluffy Jennings <fluffy@iii.ca>, MOQ Mailing List <moq@ietf.org>,
 privacy-pass@ietf.org
References: <6A00AFD1-9205-4D4A-9D62-9B40460947B3@iii.ca>
Message-ID-Hash: JYV6HDNINAZKXRSEYTSHFORJHT42OIS6
CC: Suhas Nandakumar <suhasietf@gmail.com>
Precedence: list
Subject: =?utf-8?q?=5BPrivacy-pass=5D_Re=3A_Request_for_agenda_time_for_draft-ietf-mo?=
 =?utf-8?q?q-privacy-pass-auth-00?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/privacy-pass/Efw71tyDlQAj9Hta7S8phNyxuQY>


--Apple-Mail=_45655932-7024-4E3E-8E81-EC7F10218C96
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

(CC=E2=80=99ing 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 =E2=80=94 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 =E2=80=9Ccacheable=E2=80=9D 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 =E2=80=94 just a hash of the challenge is at that =
point in the typical construction. It=E2=80=99s 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=E2=80=9D, which =
isn=E2=80=99t normally possible. Can you help describe the flow you=E2=80=99=
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=E2=80=99t =
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=E2=80=99s 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=E2=80=AFPM, Cullen Fluffy Jennings =
<fluffy@iii.ca> wrote:
>=20
> I would like to request 10 minutes to get feedback about:
>=20
> draft-ietf-moq-privacy-pass-auth-00
>=20
> 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.=20
>=20
> Thanks, Cullen
>=20
> 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
>=20
>=20
> --=20
> Privacy-pass mailing list -- privacy-pass@ietf.org
> To unsubscribe send an email to privacy-pass-leave@ietf.org


--Apple-Mail=_45655932-7024-4E3E-8E81-EC7F10218C96
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html aria-label=3D"message body"><head><meta http-equiv=3D"content-type" =
content=3D"text/html; charset=3Dutf-8"></head><body =
style=3D"overflow-wrap: break-word; -webkit-nbsp-mode: space; =
line-break: after-white-space;"><div>(CC=E2=80=99ing MOQ list =
too)</div><div><br></div>Hi Cullen,<div><br></div><div>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.</div><div><br></div><div>For those following along on the =
Privacy Pass side, the current document is =
draft-ietf-moq-privacy-pass-auth-01 (<a =
href=3D"https://www.ietf.org/archive/id/draft-ietf-moq-privacy-pass-auth-0=
1.html">https://www.ietf.org/archive/id/draft-ietf-moq-privacy-pass-auth-0=
1.html</a>).</div><div><br></div><div>Overall, I think the document is =
going in a good direction and using the tokens well. I appreciate the =
updated diagrams =E2=80=94 there had been a few issues in the individual =
draft that are sorted out now.</div><div><br></div><div>Some technical =
questions:</div><div><br></div><div>1. Are the tokens being used here =
=E2=80=9Ccacheable=E2=80=9D 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&nbsp;<a =
href=3D"https://www.rfc-editor.org/rfc/rfc9577.html#section-2.1.4">https:/=
/www.rfc-editor.org/rfc/rfc9577.html#section-2.1.4</a>&nbsp;and&nbsp;<a =
href=3D"https://www.rfc-editor.org/rfc/rfc9576.html#section-7.1">https://w=
ww.rfc-editor.org/rfc/rfc9576.html#section-7.1</a>. 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.</div><div><br></div><div>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 =E2=80=94 just a =
hash of the challenge is at that point in the typical construction. =
It=E2=80=99s 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=E2=80=9D, which isn=E2=80=99t normally possible. Can =
you help describe the flow you=E2=80=99re thinking of for who needs to =
check this information, and what they need to check it =
against?</div><div><br></div><div>3. The draft discusses the challenge =
format, but doesn=E2=80=99t explicitly mention the format the token is =
sent in for token redemption (the equivalent to&nbsp;<a =
href=3D"https://www.rfc-editor.org/rfc/rfc9577.html#name-token-structure">=
https://www.rfc-editor.org/rfc/rfc9577.html#name-token-structure</a>). =
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.</div><div><br></div><div>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=E2=80=99s 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 <i>think</i>&nbsp;that type 2 can also work =
for the later type. The text could allow that in the =
example.</div><div><br></div><div>Thanks,</div><div>Tommy</div><div><div><=
br id=3D"lineBreakAtBeginningOfMessage"><div><br><blockquote =
type=3D"cite"><div>On Oct 15, 2025, at 4:55=E2=80=AFPM, Cullen Fluffy =
Jennings &lt;fluffy@iii.ca&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div><div> I would like to request =
10 minutes to get feedback =
about:<br><br>draft-ietf-moq-privacy-pass-auth-00<br><br>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. <br><br>Thanks, =
Cullen<br><br>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<br><br><br>-- =
<br>Privacy-pass mailing list -- privacy-pass@ietf.org<br>To unsubscribe =
send an email to =
privacy-pass-leave@ietf.org<br></div></div></blockquote></div><br></div></=
div></body></html>=

--Apple-Mail=_45655932-7024-4E3E-8E81-EC7F10218C96--