Privacy Pass Issuance Protocol
draft-ietf-privacypass-protocol-16

[Ballot comment]
Thanks for fixing the IANA stuff I mentioned.

Copied from my previous DISCUSS position about -14:

Maybe I'm missing something, but you have this in Section 6.5:

"Since Clients truncate token_key_id in each TokenRequest, Issuers SHOULD ensure that the truncated form of new key IDs do not collide with other truncated key IDs in rotation."

Version -15 goes on to say that there are no security implications of a collision (whew) but basically says the operation is invalid after that.  That leads me to think this is a strange use of SHOULD, i.e., "You SHOULD do this or things don't work."  I still don't understand why that's not a MUST.  Why might one legitimately decide not to do what this says?

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

Many thanks to Yoshiro Yoneya for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/jNWWVjSN2UrAHlhxp6LBwfgX9SU/ and to Mark Nottingham for his HTTP Dir review: https://lists.w3.org/Archives/Public/ietf-http-wg/2023JulSep/0157.html. Thanks to the authors for addressing the comments.

Thank you for addressing my comment and posting the media type registration to the media-types list (for next time, please make it easier for readers and copy paste the whole registration request directly in your email).

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

Many thanks to Yoshiro Yoneya for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/jNWWVjSN2UrAHlhxp6LBwfgX9SU/ and to Mark Nottingham for his HTTP Dir review: https://lists.w3.org/Archives/Public/ietf-http-wg/2023JulSep/0157.html. Thanks to the authors for addressing the comments.

Thank you for addressing my comment and posting the media type registration to the media-types list (for next time, please make it easier for readers and copy past the whole registration request directly in your email).

[Ballot comment]
Thank you to Alexey Melnikov for the SECDIR review.

Thank your for publishing -15 to address my DISCUSS and COMMENT feedback; and for the document clarifications in the ballot thread.

One final, minor editorial suggestion to improve the pointers to the to the ASN.1 objects.

OLD – Section 6.5

  The key identifier for an Issuer Private and Public Key (skI, pkI),
  denoted token_key_id, is computed as SHA256(encoded_key), where
  encoded_key is a DER-encoded SubjectPublicKeyInfo [RFC5280] (SPKI)
  object carrying pkI as a DER-encoded RSAPublicKey value in the the
  subjectPublicKey field.  Additionally, the SPKI object MUST use the
  id-RSASSA-PSS object identifier in the algorithm field within the
  SPKI object,

NEW (i.e., add a reference to RFC5756 or RFC4055; and remove the “the the”)

The key identifier for an Issuer Private and Public Key (skI, pkI),    denoted token_key_id, is computed as SHA256(encoded_key), where    encoded_key is a DER-encoded SubjectPublicKeyInfo [RFC5280] (SPKI) object carrying pkI as a DER-encoded RSAPublicKey value [RFC5756]in the subjectPublicKey field.

[Ballot discuss]
Maybe I'm missing something, but you have this in Section 6.5:

"Since Clients truncate token_key_id in each TokenRequest, Issuers SHOULD ensure that the truncated form of new key IDs do not collide with other truncated key IDs in rotation."

Why would this not be a MUST?  That strikes me as something pretty important, so it's curious to give implementers a choice to skip this requirement.  What would a legitimate reason be to not do this?

[Ballot comment]
The "Optional parameters" in each of the subsections of Section 8.3 should read "N/A" (as you have it for "Required parameters"), not "None", unless you meant to declare that there's an option called "None".

The first and last SHOULDs in Section 4 are bare.  What's the interoperability or security impact if I don't do what it says?  Same question with the SHOULD in Section 5.5.

[Ballot comment]
I am traveling this week, and so relied heavily on Susan Hares' OpsDir review:  https://datatracker.ietf.org/doc/review-ietf-privacypass-protocol-12-opsdir-lc-hares-2023-09-04/

I am balloting NoObj in the "This is outside my area of expertise or have no cycles" with the "I read the protocol action, and I trust the sponsoring AD so have no problem." sense of the term

[Ballot discuss]
Two things related to references ...

** Section 7.  Given the deferment of security and privacy considerations to [ARCHITECTURE] and [CONSISTENCY], both seem to be a normative references.

** The reference for the format of SPKI (for RSA key material) doesn’t seem right based on my read of the ASN.1 references.

-- Section 6.5
  The key identifier for a keypair (skI, pkI), denoted token_key_id, is
  computed as SHA256(encoded_key), where encoded_key is a DER-encoded
  SubjectPublicKeyInfo (SPKI) object carrying pkI.  The SPKI object
  MUST use the RSASSA-PSS OID [RFC5756], which specifies the hash
  algorithm and salt size.

-- Section 8.2.2 says:
  *  Token Key Encoding: Serialized as a DER-encoded
      SubjectPublicKeyInfo (SPKI) object using the RSASSA-PSS OID
      [RFC5756]

SubjectPublicKeyInfo (SPKI) seems to be defined in RFC5280.  Additionally, RFC 4055 provides the “algorithm” OBJECT IDENTIFIER as id-RSASSA-PSS, “parameters” are RSASSA-PSS-params, and the “subjectPublicKey” is RSAPublicKey.


==[ snip from RFC5280 ]==
  AlgorithmIdentifier  ::=  SEQUENCE  {
        algorithm              OBJECT IDENTIFIER,
        parameters              ANY DEFINED BY algorithm OPTIONAL  }

SubjectPublicKeyInfo  ::=  SEQUENCE  {
    algorithm            AlgorithmIdentifier,
    subjectPublicKey    BIT STRING  }
==[ snip from RFC5280 ]==

==[ snip from RFC4055 ]==
      -- Used in SubjectPublicKeyInfo of X.509 Certificate.
      RSAPublicKey  ::=  SEQUENCE  {
        modulus          INTEGER,    -- n
        publicExponent    INTEGER  }  -- e

      -- AlgorithmIdentifier parameters for id-RSASSA-PSS.
      -- Note that the tags in this Sequence are explicit.

      RSASSA-PSS-params  ::=  SEQUENCE  {
        hashAlgorithm    [0] HashAlgorithm DEFAULT
                                  sha1Identifier,
        maskGenAlgorithm  [1] MaskGenAlgorithm DEFAULT
                                  mgf1SHA1Identifier,
        saltLength        [2] INTEGER DEFAULT 20,
        trailerField      [3] INTEGER DEFAULT 1  }

      HashAlgorithm  ::=  AlgorithmIdentifier

      MaskGenAlgorithm  ::=  AlgorithmIdentifier
==[ snip from RFC4055 ]==

[Ballot comment]
Thank you to Alexey Melnikov for the SECDIR review.

** Section 2.  The definition of Client and Issue as defined here seems slightly different than those in Section 2 of [ARCHITECTURE].  Is that intentional?  Why redefine them?

** Section 4.  token-key

-- Please explicitly say that the contents and formatting of this field are defined by the value of token-type.

-- Please provide a normative reference for base64URL encoding.

-- The openssl decode in in Section 6.5 was very helpful.  Consider providing a full example of a base64 encoded blob, which is then decoded with openssl.

** Section 4.  Editorial. Why is the “not-before” field not included in Table 2 which described all of the fields in the token-keys object?

** Section 5.1.  Editorial.

  nonce = random(32)

Please explain in the prose what this is doing.  Is that returning 32-bytes of random data?

** Section 5.1.  Editorial.

  POST /request HTTP/1.1
  Host = issuer.example.net
  Accept = application/private-token-response
  Content-Type = application/private-token-request
  Content-Length =

Shouldn’t this read “Host: issuer.example.net” and not “Host = issuer.example.net”, or is this not trying to show an HTTP header?

** Section 6.5.  Per the openssl decode of the SPKI file, where is the public key in that example?

** Appendix B.2.  Test Vector #2.  I had trouble verifying the token of the second test vector in the example.  I didn’t try any other example.  I tried the following:

$ cat privacy-pass-token.hexbin  (no line breaks in the file)
0002a1aa8b371c37c9a8ddbd7342ab4f9dd5227d5b1600dca6517b60f63143cd43a3bb8a8cf1c59e7a251358ed76fe0ccff61044bc79dd261f16020324d22f2d434cca572f8982a9ca248a3056186322d93ca147266121ddeb5632c07f1f71cd27082899f4bc385b4147a650a3e7efc7d23a743cb944bb53e2ed8b88ee03a9c0b1cf1f73fd7f15c1bd1f850a5a96a34d4ee9f295543f30ac920825e9a0ce26e924f2c145583019dd14408c565b660e8b702fbea559908b1a8c8f9d21ef22f7cc6a4641c57c146e6c5497d2890ca230a6749f5f83a8fdd79eba0722f10dff9e81a2fb2d05fa4d989acc2e93f595ae69c98c3daa3b169efcdd6e59596b2f049f16ba49528761f661032da65a3ee0fe8a22409766e90daf8c60323c16522818c49273c795f26bbab306dc63cfc16fe1702af2464028cf819cc647d6f9b8a8f54d7d6585a268fdb8c75f76618c64aba266836a3b2db7cdd739815a021d7ff2b36ef91f23

$ xxd -r privacy-pass-token.hexbin | openssl asn1parse -dump -inform DER
Error: offset out of range

$ xxd -r -p privacy-pass-token.hexbin | openssl asn1parse -dump -inform DER
    0:d=0  hl=2 l=  2 prim: EOC             
      0000 - a1 aa

[Ballot comment]
# GEN AD review of draft-ietf-privacypass-protocol-14

CC @larseggert

## Comments

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Terms `blinded`, `blind`, `blind_inv`, `blinded_msg`, `blindrsa`,
  `blindevaluate`, `blind_sig`, `blindsign`, and `blinded_element`;
  alternatives might be `visually impaired`, `unmindful of`, `unconcerned
  about`, `negligent of`, `unaware`, `uncomprehending`, `unaware`,
  `uncritical`, `unthinking`, `hasty`, `blocked`, `opaque`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 5.2, paragraph 6
```
-    If these conditions are met, the Issuer then tries to deseralize
+    If these conditions are met, the Issuer then tries to deserialize
+                                                              +
```

### Grammar/style

#### Section 4, paragraph 20
```
l, the Issuer Request URL might be correspond to the Client's configured Atte
                                ^^^^^^^^^^^^^
```
There may an error in the verb form "be correspond".

#### Section 5.5, paragraph 3
```
l, the Issuer Request URL might be correspond to the Client's configured Atte
                                ^^^^^^^^^^^^^
```
There may an error in the verb form "be correspond".

## 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. Review generated by the [`ietf-reviewtool`][IRT].

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

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

Many thanks to Yoshiro Yoneya for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/jNWWVjSN2UrAHlhxp6LBwfgX9SU/ and to Mark Nottingham for his HTTP Dir review: https://lists.w3.org/Archives/Public/ietf-http-wg/2023JulSep/0157.html. Thanks to the authors for addressing the comments.

I only have one additional point to bring up, easy to resolve.

As specified by RFC6838, it is strongly encouraged to post the media type registration to the media-types mailing list for review (see https://mailarchive.ietf.org/arch/msg/media-types/3_DukpPWrpkTXO-zynjJlShtC1w/ for an example of a registration review). If I missed it, my apologies. Or is there any reason this was not done here? If not, please post to the media-types mailing list, and I will remove the discuss with no objections raised in a week or so.

Request for Last Call review by HTTPDIR Completed: Ready with Issues. Reviewer: Mark Nottingham. Sent review to list. Submission of review completed at an earlier date.

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

The IANA Functions Operator has completed its review of draft-ietf-privacypass-protocol-12. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that some of the actions requested in the IANA Considerations section of this document are dependent upon the approval of and completion of IANA Actions in another document: [draft-ietf-privacypass-auth-scheme].

The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the Well-Known URIs registry located at:

https://www.iana.org/assignments/well-known-uris/

a single new registration will be made as follows:

URI Suffix: private-token-issuer-directory
Change Controller: IETF
Reference: [ RFC-to-be ]
Status: permanent
Related Information:

As this document requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, the Privacy Pass Token Type registry will be created upon approval of a related draft: [draft-ietf-privacypass-auth-scheme]. Once that document is approved and the registry is created, two new registrations will be made in the registry as follows:

Value: 0x0001
Name: VOPRF (P-384, SHA-384)
Token Structure: As defined in Section 2.2 of [draft-ietf-privacypass-auth-scheme]
Token Key Encoding: Serialized using SerializeElement from Section 2.1 of [draft-irtf-cfrg-voprf]
TokenChallenge Structure: As defined in Section 2.1 of [draft-ietf-privacypass-auth-scheme]
Publicly Verifiable: N
Public Metadata: N
Private Metadata: N
Nk: 48
Nid: 32
Reference: [ RFC-to-be; Section 5 ]
Notes: None

Value: 0x0002
Name: Blind RSA (2048-bit)
Token Structure: As defined in Section 2.2 of [draft-ietf-privacypass-auth-scheme]
Token Key Encoding: Serialized as a DER-encoded SubjectPublicKeyInfo (SPKI) object using the RSASSA-PSS OID [RFC5756]
TokenChallenge Structure: As defined in Section 2.1 of [draft-ietf-privacypass-auth-scheme]
Publicly Verifiable: Y
Public Metadata: N
Private Metadata: N
Nk: 256
Nid: 32
Reference: [ RFC-to-be; Section 6 ]
Notes: The RSABSSA-SHA384-PSS-Deterministic and RSABSSA-SHA384-PSSZERO-Deterministic variants are supported

As this also requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Third, in the application namespace of the Media Types registry located at:

https://www.iana.org/assignments/media-types/

three new media types are to be registered as follows:

Name: private-token-issuer-directory
Template: [ TBD-at-registration ]
Reference: [ RFC-to-be ]

Name: private-token-request
Template: [ TBD-at-registration ]
Reference: [ RFC-to-be ]

Name: private-token-response
Template: [ TBD-at-registration ]
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that these three actions are the only ones required to be completed upon approval of this document.

Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

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

Thank you,

David Dong
IANA Services Sr. Specialist

Request for Last Call review by ARTART Completed: Ready with Nits. Reviewer: Yoshiro Yoneya. Sent review to list. Submission of review completed at an earlier date.

The following Last Call announcement was sent out (ends 2023-08-31):

From: The IESG
To: IETF-Announce
CC: draft-ietf-privacypass-protocol@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:  (Privacy Pass Issuance Protocol) to Proposed Standard


The IESG has received a request from the Privacy Pass WG (privacypass) to
consider the following document: - 'Privacy Pass Issuance Protocol'
  as Proposed Standard

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-08-31. 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 two variants of the two-message issuance
  protocol for Privacy Pass tokens: one that produces tokens that are
  privately verifiable using the issuance private key, and another that
  produces tokens that are publicly verifiable using the issuance
  public key.




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



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


The document contains these normative downward references.
See RFC 3967 for additional information:
    draft-irtf-cfrg-voprf: Oblivious Pseudorandom Functions (OPRFs) using Prime-Order Groups (None - Internet Research Task Force (IRTF))
    draft-irtf-cfrg-rsa-blind-signatures: RSA Blind Signatures (None - Internet Research Task Force (IRTF))
    rfc8877: Guidelines for Defining Packet Timestamps (Informational - Internet Engineering Task Force (IETF))
    rfc5861: HTTP Cache-Control Extensions for Stale Content (Informational - Independent Submission)

# 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?

This document represents a broad agreement of the working group.

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

This document has strong consensus without any significant points of contention.

> 3. Has anyone threatened an appeal or otherwise indicated extreme discontent?

No.

> 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 protocol.  References to
these implementations are included in the architecture 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. These implementations communicate using the auth scheme defined in
this document (see e.g. https://developer.apple.com/news/?id=huqjyh7k,
https://www.fastly.com/blog/private-access-tokens-stepping-into-the-privacy-respecting-captcha-less).

This document does not contain any reference to these implementations.

> 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 incubator 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.

N/A

> 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]?

N/A

> 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.

N/A

## 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?

Yes.

> 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 is a security-oriented draft, developed in the SEC area.  Common security-
related issues have been thoroughly addressed.

> 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?

"Proposed Standard".  This draft defines a concrete protocol element and syntax
that can be implemented interoperably to issue privacy pass tokens. 
The Datatracker state is correct.

> 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.

Yes.  There are four authors.

> 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?

All normative references are to IETF RFCs.

> 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 any 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]).

The IANA instructions are correct and consistent.

> 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.

The instructions to the Designated Experts are clear.

[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 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?

This document represents a broad agreement of the working group.

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

This document has strong consensus without any significant points of contention.

> 3. Has anyone threatened an appeal or otherwise indicated extreme discontent?

No.

> 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 protocol.  References to
these implementations are included in the architecture 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. These implementations communicate using the auth scheme defined in
this document (see e.g. https://developer.apple.com/news/?id=huqjyh7k,
https://www.fastly.com/blog/private-access-tokens-stepping-into-the-privacy-respecting-captcha-less).

This document does not contain any reference to these implementations.

> 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 incubator 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.

N/A

> 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]?

N/A

> 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.

N/A

## 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?

Yes.

> 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 is a security-oriented draft, developed in the SEC area.  Common security-
related issues have been thoroughly addressed.

> 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?

"Proposed Standard".  This draft defines a concrete protocol element and syntax
that can be implemented interoperably to issue privacy pass tokens. 
The Datatracker state is correct.

> 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.

Yes.  There are four authors.

> 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?

All normative references are to IETF RFCs.

> 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 any 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]).

The IANA instructions are correct and consistent.

> 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.

The instructions to the Designated Experts are clear.

[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 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?

This document represents a broad agreement of the working group.

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

This document has strong consensus without any significant points of contention.

> 3. Has anyone threatened an appeal or otherwise indicated extreme discontent?

No.

> 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 architecture 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. These implementations communicate using the auth scheme defined in
this document (see e.g. https://developer.apple.com/news/?id=huqjyh7k,
https://www.fastly.com/blog/private-access-tokens-stepping-into-the-privacy-respecting-captcha-less).

This document does not contain any reference to these implementations.

> 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 incubator 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.

N/A

> 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]?

N/A

> 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.

N/A

## 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?

Yes.

> 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 is a security-oriented draft, developed in the SEC area.  Common security-
related issues have been thoroughly addressed.

> 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?

"Proposed Standard".  This draft defines a concrete protocol element and syntax
that can be implemented interoperably to issue privacy pass tokens. 
The Datatracker state is correct.

> 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.

Yes.  There are five authors.

> 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?

All normative references are to IETF RFCs.

> 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 any 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]).

The IANA instructions are correct and consistent.

> 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.

The instructions to the Designated Experts are clear.

[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/