Subject: [Privacy-pass] Private Access Tokens and Privacy Pass Architecture

From: Steven Valdez <[email-masked]>
Date: Thu, 16 Dec 2021 11:41:19 -0500

Following up on IETF 112, and discussions about Private Access Tokens (
https://www.ietf.org/archive/id/draft-private-access-tokens-00.html) in
SECDISPATCH to move it to PRIVACYPASS, the authors have been working on a
proposed re-architecture of the PRIVACYPASS documents to support both the
existing privately verifiable construction (based on VOPRFs), as well as
the publicly verifiable construction (based on RSA Blind Signatures) and
the Private Access Tokens design.

Links and a discussion to the proposed drafts are below. Please review them
and provide feedback!

Due to the scope of the changes, it might be useful to go over these drafts
in a meeting. Chairs, would it be possible to get an interim scheduled in
January to discuss these changes?

---

Current proposed drafts of the documents are:

Architecture:
https://ietf-wg-privacypass.github.io/base-drafts/caw/arch-refactor/draft-ietf-privacypass-architecture.html
HTTP Auth Scheme:
https://tfpauly.github.io/privacy-proxy/draft-pauly-privacypass-auth-scheme.html
PrivacyPass Issuance Protocol:
https://ietf-wg-privacypass.github.io/base-drafts/caw/pp-issuance/draft-ietf-privacypass-protocol.html
Rate-limited Token Issuance Protocol (Private Access Tokens):
https://tfpauly.github.io/privacy-proxy/draft-privacypass-rate-limit-tokens.html

The Architecture document provides the shared architecture that different
tokens build on top of, generalizing the existing architecture of Issuer,
Client, Origin to include an Attester (which is currently implicit in the
existing architecture). It defines the purpose and requirements for Privacy
pass issuance and redemption.

The HTTP Auth Scheme document is a new document to provide an HTTP
authentication scheme for Privacy Pass redemption. This can be used with
any issuance protocol.

The Issuance Protocol documents provide the protocol details for each
issuance protocol (the PrivacyPass token protocol includes the VOPRF and
RSA Blind Signature forms).

---

From: Alex Davidson <[email-masked]>
Date: Mon, 20 Dec 2021 16:52:25 +0000

Hi,

Broadly speaking, I think the reorganisation of the protocol, architecture,
HTTP auth docs make sense. Having not followed the work on Private Access
Tokens very closely, I think it would be beneficial to have a presentation
on this topic to the WG. Specifically, it would be useful to hear more
related to the motivation and intended goals of this draft, and the
applicability of this work to the WG.

I also found a few minor issues after doing an initial read-through of the
docs:

- Section 3 of the HTTP auth doc seems to already be covered in Section 3.2
of the architecture doc, maybe this could be replaced with a simple
citation?
- This may be a hangover from a previous iteration, but in Section 4.2 of
the architecture doc the advised key rotation period (1-12 weeks) is not
consistent with the table in Section 6 (2-24 weeks).

I will read the linked drafts over the next few days more thoroughly and
post any additional things that I notice here.

Cheers,
Alex

On Thu, Dec 16, 2021 at 4:41 PM Steven Valdez <svaldez=
[email-masked]> wrote:

> Links and a discussion to the proposed drafts are below. Please review
> them and provide feedback!
>
> Due to the scope of the changes, it might be useful to go over these
> drafts in a meeting. Chairs, would it be possible to get an interim
> scheduled in January to discuss these changes?
>
> ---
>
> --
> Privacy-pass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/privacy-pass
>

---

From: "Christopher Wood" <[email-masked]>
Date: Mon, 20 Dec 2021 10:40:26 -0800

On Mon, Dec 20, 2021, at 8:52 AM, Alex Davidson wrote:
> Hi,
>
> Broadly speaking, I think the reorganisation of the protocol, 
> architecture, HTTP auth docs make sense. Having not followed the work 
> on Private Access Tokens very closely, I think it would be beneficial 
> to have a presentation on this topic to the WG. Specifically, it would 
> be useful to hear more related to the motivation and intended goals of 
> this draft, and the applicability of this work to the WG.

Definitely! That said, a primary objective of this refactor is to ensure that Privacy Pass can easily support different types of issuance protocols, including, for example, those that may produce publicly verifiable tokens. The base OPRF-based Privacy Pass variant is one specific type of issuance protocol. Public verifiable variants and PAT are simply other types.

This seems like a clean way to address the extensibility point this WG has been discussing for quite some time now, and I'm hopeful that we can reach consensus on this as the path forward.

> I also found a few minor issues after doing an initial read-through of the docs:
>
> - Section 3 of the HTTP auth doc seems to already be covered in Section 
> 3.2 of the architecture doc, maybe this could be replaced with a simple 
> citation?

Yep, good catch: https://github.com/tfpauly/privacy-proxy/issues/121

> - This may be a hangover from a previous iteration, but in Section 4.2 
> of the architecture doc the advised key rotation period (1-12 weeks) is 
> not consistent with the table in Section 6 (2-24 weeks).

This is indeed hangover from the previous iteration, but we can clean it up here. 

> I will read the linked drafts over the next few days more thoroughly 
> and post any additional things that I notice here.

Lovely -- thanks!

Best,
Chris

>
> Cheers,
> Alex
>
> On Thu, Dec 16, 2021 at 4:41 PM Steven Valdez 
> <svaldez=[email-masked]> wrote:
>> Following up on IETF 112, and discussions about Private Access Tokens (https://www.ietf.org/archive/id/draft-private-access-tokens-00.html) in SECDISPATCH to move it to PRIVACYPASS, the authors have been working on a proposed re-architecture of the PRIVACYPASS documents to support both the existing privately verifiable construction (based on VOPRFs), as well as the publicly verifiable construction (based on RSA Blind Signatures) and the Private Access Tokens design.
>> 
>> Links and a discussion to the proposed drafts are below. Please review them and provide feedback!
>> 
>> Due to the scope of the changes, it might be useful to go over these drafts in a meeting. Chairs, would it be possible to get an interim scheduled in January to discuss these changes?
>> 
>> ---
>> 
>> Architecture: https://ietf-wg-privacypass.github.io/base-drafts/caw/arch-refactor/draft-ietf-privacypass-architecture.html
>> HTTP Auth Scheme: https://tfpauly.github.io/privacy-proxy/draft-pauly-privacypass-auth-scheme.html
>> PrivacyPass Issuance Protocol: https://ietf-wg-privacypass.github.io/base-drafts/caw/pp-issuance/draft-ietf-privacypass-protocol.html
>> Rate-limited Token Issuance Protocol (Private Access Tokens): https://tfpauly.github.io/privacy-proxy/draft-privacypass-rate-limit-tokens.html
>> 
>> The Architecture document provides the shared architecture that different tokens build on top of, generalizing the existing architecture of Issuer, Client, Origin to include an Attester (which is currently implicit in the existing architecture). It defines the purpose and requirements for Privacy pass issuance and redemption.
>> 
>> The HTTP Auth Scheme document is a new document to provide an HTTP authentication scheme for Privacy Pass redemption. This can be used with any issuance protocol.
>> 
>> The Issuance Protocol documents provide the protocol details for each issuance protocol (the PrivacyPass token protocol includes the VOPRF and RSA Blind Signature forms).
>> --