The Privacy Pass Architecture
draft-ietf-privacypass-architecture-16

[Ballot comment]
Thanks for working on this document. I have no TSV related comments. There are number of typos and nits - specially the double definition of "Token", but those are mostly covered by my fellow ADs comments.

[Ballot comment]
Thank you for the work on this document.

I only scanned for ART issues and didn't find any. Many thanks to Russ Housley for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/HpQXSIthHUeu9uWUDprSbMVcY0g/ and follow up, and to the authors for addressing Russ's comments.

[Ballot comment]
Thanks to Russ Housley for his ARTART review(s).

(Paul, remember to set the Consensus Boilerplate before Cindy makes you do it!)

Some of the SHOULDs in here feel dodgy to me, in the sense that they appear to be describing preferred or best practices rather than security or interoperability concerns.  If I'm wrong, then maybe the text around them could use a bit of expansion to describe the choice being presented and why the recommendation improves interoperability.

[Ballot comment]
# John Scudder, RTG AD, comments for draft-ietf-privacypass-architecture-15
CC @jgscudder

Thanks for this interesting and readable document. I have a few questions and comments, and some nits.

## COMMENTS

### Section 2, what's a token?

```
Token:
A cryptographic authentication message used for authorization decisions.

Token:
A privacy-preserving authenticator that is used for authorization.
```

This seems like an editing error, presumably it isn't both? (Or if it is both, it should be expressed some other way that makes that clear, presumably with a single definition.)

### Section 3.3, non-colluding

"In particular, this means that Attesters which may be privy to private information about Clients are trusted to not disclose this information to non-colluding parties"

The qualification "to non-colluding parties" carries within it the implication that collusion is OK, hence the qualifier. As far as I can tell, that's not right -- for example, §4 says "The discussion below assumes non-collusion" and §7 has "This document ... describes deployment models built around non-collusion assumptions". I.e., I think that the architecture intends for all parties that are not malicious actors to be non-colluding.

Would it be right to rewrite the quoted phrase as just, "In particular, this means that Attesters which may be privy to private information about Clients are trusted to not disclose this information"? The second clause in the sentence already provides a hint to the reader that non-collusion assumptions are important.

### Section 3.3, signature over what?

"In settings where Clients do not communicate with Issuers through an Attester, the Attesters might convey this trust via a digital signature over that Issuers can verify."

There's something missing after "over".

## NITS

### Section 3

Presumably in "considerations for implements these entities" you meant either "implementors of" or "implementations of".

### Section 3.1

s/deployment specific/deployment-specific/

### Section 3.2

s/rate limit malicious/rate-limit malicious/

### Section 3.3

s/Client visible information/Client-visible information/

(occurs 3x in §3.3, 1x in §3.5)

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

[Ballot comment]
Thank you to Ned Smith for the SECDIR review.

** Section 2.
  Token:  A cryptographic authentication message used for authorization
      decisions.

  Token:  A privacy-preserving authenticator that is used for
      authorization.

-- Is “Token” being defined two different ways intentional?

-- In addition, should the token be defined as the output of running the Challenge mechanism?

** Section 2.
  Redemption:  The mechanism by which Clients present tokens to Origins
      for consumption.

Is it “for consumption” (as defined) or “in response to a Challenge”?

** Section 2.
  Attestation procedure:  The procedure by which an Attester determines
      whether or not a Client has the specific set of properties that
      are necessary for token issuance.

Is “attestation procedure” the same as RATS “appraisal policy for evidence” + “reference values” + “endorsement”?  I’m asking because a few of the other terms were framed in terms of the RATS architecture.

** Section 3.1.  Editorial
  1.  A Client interacts with an Origin by sending a request or
      otherwise interacting with the Origin in a way that triggers a
      response containing a token challenge.  The token challenge
      indicates a specific Issuer to use.

What is significant of “token challenge” being used here instead of the more generic “challenge” defined in the previous section?

** Section 3.1.  Editorial.  Step #4+ references “Token Request” and “Token Response” but these are defined until much later in the document.  A forward reference would be very helpful if this terminology remains as is.

** Section 3.4 and 3.6.* make reference to cross-Origin redemption. 

-- This pattern isn’t documented in the deployment approach in Section 4.*.  Should it?

-- What coordination (collusion) between Origins needs to occur to realize this protocol flow?  What are the privacy implications for a Client?  Risks to the Origin?

** Section 3.5.1 and 3.5.2.  Definition of the Attester and Issue role

-- Section 3.5.1 said that “Clients trust the Attester to not share any Client-specific information with the Issuer.  In deployments where the Attester does not learn Client-specific information, the Client does not need to explicitly trust the Attester in this regard.”

-- Section 3.5.2 says that “Clients do not explicitly trust Issuers.”

In deployment models where the Issuer+Attester are combined, don’t clients have to trust Attesters and Issuers equally?  Is it reasonable to assume that an attester won’t share client-specific information with the issuer?

** Section 3.5.1
  As an example, the number of Clients that have solved a CAPTCHA in
  the past day, that have a valid account, and that are running on a
  trusted device is less than the number of Clients that have solved a
  CAPTCHA in the past day.

I couldn’t understand the intent of this example.  Specifically, why is it surprising that population-a, “the number of Clients that have solved a CAPTCHA in the past day, that have a valid account, and that are running on a trusted device”, is less than population-b, “the number of Clients that have solved a CAPTCHA in the past day”.  Population-a always has to be <= population-b since population-a is a subset of population-b.

** Section 3.5.1
  Attesters SHOULD NOT be based on
  attestation procedures that result in small anonymity sets.

The reason for doing that is clear.  However, who is this guidance directed at and how would it be implemented?  Is this guidance suggesting collecting metrics?  Are there thresholds for “small”?

** Section 3.5.1
  if attestation is compromised because of a zero-day exploit on
  compliant devices

From the context, I think that this text is talking about the Attestor.

-- Please clarify if this “compliant device” is the client or the infrastructure hosting the Attestor?

-- What’s “compliant” mean in this context?

** Section 3.5.3
  Generally speaking, Clients cannot determine if this
  value is generated honestly or otherwise a tracking vector.

What does “honest” mean here?  Section 3.5.2 already said “Clients do not explicitly trust Issuers” and this section explains that the value is opaque.  Isn’t the clearer statement that in the case of opaque metadata, the client cannot be sure of either the correctness or the intent of the data that is passed to it?  Furthermore, that the Client has little protection against the insertion of said tracking vector beyond the guidance in Section 6.1?

** Section 4.2
  For certain types of issuance protocols, this model achieves Origin-
  Client, Issuer-Client, and Attester-Origin unlinkability. owever,
  issuance protocols that require the Issuer to learn information about
  the Origin, such as that which is described in [RATE-LIMITED], are
  not appropriate since they could lead to Attester-Origin
  unlinkability violations through the Origin name.

Without knowing the protocols, how can this be true?  Should this be re-framed to say “In order to ensure this deployment model realizes ... unlinkability, the issuance protocols that required the Issuer to learn information about the Origin ... are inappropriate

** Section 5.1
  In principle, Issuers should strive to mitigate discriminatory
  behavior by providing equitable access to all Clients.
...
  In practice, this may require tradeoffs in what type of
  attestation Issuers are willing to trust so as to enable more
  widespread support.


-- Realizing that this isn’t for the protocol to solve, is there a sense of what would drive this equitable access?  It is a realistic assumption for what seems like a dual-use technology.

-- Can the second sentence be clarified.  Re-reading it a few times, is it saying that practically Issuers will have to make “tradeoffs” on the practical bounds of widespread support, which suggests that full equitable access might not be possible?

** Section 6.1
  Clients SHOULD bound the number of possible metadata values in
  practice.

What does this mean in practice?  Is it that the Client would not certain tokens from the Issuer?

-- Should Client be inherently concerned about the security implications of these opaque blobs?

** Typos:
Section 1.  Typo. s/suceeding/succeeding/

Section 3.2.  Typo. s/propietary/proprietary

[Ballot comment]
Hi,

Thanks for this document, I have some minor (non blocking) comments/questions:

Minor level comments:

(1) p 3, sec 2.  Terminology

  Token:  A privacy-preserving authenticator that is used for
      authorization.

I presume that this is a typo and not meant to be Token?


(2) p 5, sec 3.2.  Use Cases

  *  Privacy-preserving authentication for proprietary services.
      Tokens can attest that the client is a valid subscriber for a
      propietary service, such as a deployment of Oblivious HTTP
      [OHTTP].

Is it possible or appropriate for this technology (or an extension of it) to be used to help confirm that a client is over a certain age in a way that reduces their loss of privacy compared to them having to prove their age via verifiable ID or a credit card to a website?


(3) p 14, sec 3.5.2.  Issuer Role

    In general, Clients SHOULD
  minimize or remove identifying information where possible when
  invoking the issuance protocol.

Would "remove superfluous identifying information" be better here?



Nit level comments:

(4) p 7, sec 3.3.  Privacy Goals and Threat Model

    In settings where Clients do not communicate with Issuers
  through an Attester, the Attesters might convey this trust via a
  digital signature over that Issuers can verify.

I found that last part of this sentence to be slightly clunky.  "over which" might be slighty better than "over that" or could restructure.

Regards,
Rob

[Ballot comment]
Firstly, thank you for this document -- I found it is pleasant and useful read.

I do have some nits to offer:
Sec 3:
"Deployment variations for the Origin, Issuer, and Attester in this architecture, including considerations for implements these entities, are further discussed"
- I suspect you meant "implmenting"

Sec 5:
"Although Origin-Client unlinkabiity guarantees" - unlinkability

Sec 6.2:
"... any Client that invokes the issuance protocol with this configuration becomes be part of a set of " - s/becomes be/becomes/

Sec 7.1:
"As an example of this attack, many distributed Clients could obtain cacheable tokens and them share them with a single Client" - and then share them

[Ballot comment]
# Internet AD comments for draft-ietf-privacypass-architecture-15
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S2

* Is the two different definitions for the same term ("Token") intentional?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-privacypass-architecture-13, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Specialist

Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Meral Shirazipour. Sent review to list. Submission of review completed at an earlier date.

The following Last Call announcement was sent out (ends 2023-07-03):

From: The IESG
To: IETF-Announce
CC: draft-ietf-privacypass-architecture@ietf.org, jsalowey@gmail.com, paul.wouters@aiven.io, privacy-pass@ietf.org, privacypass-chairs@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (The Privacy Pass Architecture) to Informational RFC


The IESG has received a request from the Privacy Pass WG (privacypass) to
consider the following document: - 'The Privacy Pass Architecture'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2023-07-03. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document specifies the Privacy Pass architecture and
  requirements for its constituent protocols used for constructing
  privacy-preserving authentication mechanisms.  It provides
  recommendations on how the architecture should be deployed to ensure
  the privacy of clients and the security of all participating
  entities.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-privacypass-architecture/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The working group had strong consensus to move this document forward. 

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No particular controversial points

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No Extreme Discontent and no threats of appeal

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There are deployed examples of the privacy pass architecture.  References to these implementations are included in the document.
This includes two open source implementations that implement pieces of the architecture and vendor products including private
access tokens implemented by Apple, Cloudflare and Fastly.
 

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

Members of the working group also participate in the W3C which has activities that may link up to privacy pass.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

NA

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

NA

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.
NA

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The Document is ready for handoff to the IESG

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

This document is an architecture document and most of the common issues do not apply.
Authors and reviewers have considered security throughout the process, but this document
should go through secdir review.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The document describes an architecture and an Informational RFC is requested. 

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

The chairs have contacted the authors and informed them of IPR disclosure. 
No IPR disclosures have been made for this document.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The chairs have asked the authors and one indicated they wanted to be removed from
the draft because they did not feel the contributed enough.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

ID Nits have been reviewed.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

the references are classified appropriately.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
Normative references are freely available.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
No DownREFs

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
No

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document does not change the status of other documents

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

No actions for IANA

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

NA

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The working group had strong consensus to move this document forward. 

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No particular controversial points

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No Extreme Discontent and no threats of appeal

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There are deployed examples of the privacy pass architecture.  References to these implementations are included in the document.
This includes two open source implementations that implement pieces of the architecture and vendor products including private
access tokens implemented by Apple, Cloudflare and Fastly.
 

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

Members of the working group also participate in the W3C which has activities that may link up to privacy pass.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

NA

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

NA

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.
NA

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The Document is ready for handoff to the IESG

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

This document is an architecture document and most of the common issues do not apply.
Authors and reviewers have considered security throughout the process, but this document
should go through secdir review.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The document describes an architecture and an Informational RFC is requested. 

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

The chairs have contacted the authors and informed them of IPR disclosure. 
No IPR disclosures have been made for this document.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

The chairs have asked the authors and one indicated they wanted to be removed from
the draft because they did not feel the contributed enough.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

ID Nits have been reviewed.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

the references are classified appropriately.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
Normative references are freely available.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
No DownREFs

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
No

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document does not change the status of other documents

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

No actions for IANA

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

NA

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

The working group had strong consensus to move this document forward. 

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

No particular controversial points

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No Extreme Discontent

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

There are deployed examples of the privacy pass architecture.  References to these implementations are included in the document.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

Members of the working group also participate in the W3C which has activities that may link up to privacy pass.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

NA

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

NA

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.
NA

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

The Document is ready for handoff to the IESG

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

The document describes an architecture and an Informational RFC is requested. 

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

the references are classified appropriately.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
Normative references are freely available.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
No DownREFs

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
No

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

This document does not change the status of other documents

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

No IANA considerations

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

NA

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://trac.ietf.org/trac/ops/wiki/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://trac.ietf.org/trac/iesg/wiki/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/