The Privacy Pass HTTP Authentication Scheme
draft-ietf-privacypass-auth-scheme-15

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

Many thanks to Martin Thomson for his in-depth HTTPDIR review: https://lists.w3.org/Archives/Public/ietf-http-wg/2023JulSep/0156.html, and to the authors for addressing Martin's comments.

[Ballot comment]
I have very little useful to contribute here -- I read the document, and it seems like it makes good sense and provides a useful facility... however, I think that my primary viewpoint can best be summarized by stealing a line from Eric's ballot: "Thank you for the work done on this document. As it is fairly outside of my area of expertise, I trust the responsible AD on the actual contents.".

As an aside, I think that Paul W's concerns are covered in 2.1 - "Comparison of the origin name that issued the authentication challenge against elements in the origin_info list is done via case-insensitive equality checks."

[Ballot comment]
Thanks for working on this specification.

This specification does not raise transport related issues, however, I kind of agree with Martin's concerns on assumptions and user interaction. On top of the, section 3 only describe when this is used in a website context. I didn't find what are the other context and how that would be different or what need to be done differently. I think I needs to be clarified as well. Hence, supporting Francesca's discuss.

I also think the privacy pass architecture document and this specification should have been at least reviewed together or preferably architecture doc should have get to us first to review/approve. I don't expect lots will change in the architecture after IESG evaluation but still there are some possibilities. As this document relay's on the architecture terminologies it feels odd to review this when we haven't reviewed the terminologies defined in the architecture doc.

[Ballot discuss]
Hi,

Thanks for this document.  I found the document to be well written and reasonable clear, and I think that this is useful technology (but worry about the centralization aspects that the protocol is likely the encourage). However, I feel that this document is somewhat hard to fully understand without reading the architecture document first (which is only an informative rather than normative reference).  Hence, I have a flagged a few issues which I think rise to the category of discuss but hopefully should not be hard to resolve.

(1) p 15, sec 5.2.  Token Type Registry

  *  Private Metadata: A Y/N value indicating if the output tokens can
      contain private metadata.

This is the first time that some of these fields (e.g., Publicly Verifiable, Public/Private Metadata) have been introduced.  Does the document need any additional prose to describe what they and how they are used?  The current text feels somewhat terse as a description in a standard track document.


(2) p 17, sec 5.2.  Token Type Registry

  *  Nid: N/A

Shoudln't Nk and Nid default to 0 rather than 'N/A'?  This comment also applies to the text above the greased values, or otherwise (at a stretch) it could arguably be interpreted as putting is randomly sized Nk and Nid fields containing random data.


(3) p 18, sec 6.2.  Informative References

  [ARCHITECTURE]
              Davidson, A., Iyengar, J., and C. A. Wood, "The Privacy
              Pass Architecture", Work in Progress, Internet-Draft,
              draft-ietf-privacypass-architecture-13, 15 June 2023,
              .

It seems strange to me that the architecture reference isn't normative.  I.e., I would think that reading aspects of the architecture is a prerequisite to fully understanding the protocol aspects defined here.

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

Many thanks to Martin Thomson for his in-depth HTTPDIR review: https://lists.w3.org/Archives/Public/ietf-http-wg/2023JulSep/0156.html. Martin brings up a number of very valid comments (https://github.com/ietf-wg-privacypass/base-drafts/issues/created_by/martinthomson) some of which I think should be easily addressed. Some of these however seem more important and I am looking forward to the authors replies.

Posting Martin's review below (and CC'ing him in), for archiving purposes.

--
This document describes a new authentication scheme for HTTP that enables
authorization via Privacy Pass.

I've been tracking this work at a high level, but I've never reviewed this
document in any detail until now.  After taking a closer look, I've found quite
a few problems.

https://github.com/ietf-wg-privacypass/base-drafts/issues lists 23 new issues.
https://github.com/ietf-wg-privacypass/base-drafts/pull/459 suggests some
editorial fixes on top of those.

A number of those issues are significant enough to suggest that the document is
not ready.  I expect that most will be easily handled, but there are a couple
of trickier ones.

https://github.com/ietf-wg-privacypass/base-drafts/issues/448 is serious enough
to draw special attention to.  In short, Section 3 of the document is very
problematic as it makes a lot of assumptions about a particular deployment
environment.  Some of those assumptions are -- I think -- bad.  It looks like
the intent of this section is to describe how this mechanism might be deployed
safely to the Web.  This raises a number of concerns:

1. This is an IETF document.  The W3C is probably in a better position to come
to conclusions about what is (or isn't) appropriate for deployment to the Web.

2. The bounds on user agent behaviour are not specified in sufficient detail.
There is definitely a case to be made for this to be deployed to the web as
envisaged, with different implementations making their own choices.  But if the
intent is to describe the nature of the risks involved in deployment to the
Web, then there is not enough detail to guide the successful implementation and
deployment of this feature.

3. There are a number of implicit assumptions throughout that are not
adequately explained.  For instance, there is discussion of use of this
mechanism across origins or sites, despite that violating established Web
norms.  There is discussion of that cross-site transfer occurring without user
involvement, which is a oft-used safeguard against such privacy leaks.  But the
necessary preconditions for that transfer are not articulated.  There are
potentially scenarios where this sort of transfer could be safe, but there are
great many where it is absolutely not.  The document seems to be assuming that
the token carries a very particular signal along with it, namely that the
client acts on behalf of an entity that the attester (and transitively, the
issuer) believe not to be abusive.

I've suggested in the issue that this section needs considerable revision.
There are general requirements on the use of the protocol that are currently
buried in amoungst Web-specific requirements.  Those will need to be teased
out.  It's possible that the accompanying architecture document could cover
this material, but I'm not seeing it there.

Then there are the Web-specific requirements that really belong in a
Web-specific document, which is probably something that the W3C is in a better
position to produce than the IETF.  Here, the precise set of safeguards will
probably be some mixture of client-specific policy and widely-agreed policy, so
getting that mix right will need careful consideration.

Despite all this, I'm generally supportive of this protocol.  It is a design
that should work well in a great many contexts, but getting this right for the
Web requires more than this document provides.

[Ballot comment]
# Internet AD comments for draft-ietf-privacypass-auth-scheme-11
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/

## Discuss

## Comments

### S4

* The discussion of exact match of the origin list would imply that DNS
  case-insensitive comparison does not apply.  In other words, an origin_info
  of "a.example.com,b.example.com" would not match
  "a.example.COM,b.EXAMPLE.com", even though the individual origins would
  compare equally in some other contexts.

  Should this be noted explicitly somewhere (perhaps here and/or in S2.1)?

## Nits

### S2.1.1

* "contexts does only needs to exist"
  s/does //?

### S3

* "Tokens challenges can be performed" -> "Token challenges ..."

[Ballot comment]
# GEN AD review of draft-ietf-privacypass-auth-scheme-11

CC @larseggert

Thanks to Gyan S. Mishra for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/WAaMS_xTQgjC4sJVa_JC4rImVe0).

## Comments

### Section 5.2, paragraph 15
```
    This registry also will also allow provisional registrations to allow
    for experimentation with protocols being developed.  Designated
    experts review, approve, and revoke provisional registrations.
```
How/why/when do experts revoke provisional registrations? AFAIK this
is not something that they usually do for other registries. Can
provisional registrations be upgraded to regular ones without
codepoint changes? This all might need more text, or maybe we can
rely on the "private use" range for this?

## 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 1, paragraph 4
```
-    authentiation response (using the Authorization request header
+    authentication response (using the Authorization request header
+            +
```

#### Section 5.2, paragraph 17
```
-    [RFC8701]).  Implemenations SHOULD select reserved values at random
+    [RFC8701]).  Implementations SHOULD select reserved values at random
+                        +
```

#### Section 5.2, paragraph 18
```
-    attribute is "None".  The iniital list of Values is as follows:
-                                  -
+    attribute is "None".  The initial list of Values is as follows:
+                                +
```

### Outdated references

Document references `draft-ietf-privacypass-protocol-10`, but `-11` is the
latest available revision.

### Grammar/style

#### Section 2.1, paragraph 32
```
quest redemption contexts does only needs to exist within the scope of the re
                                    ^^^^^
```
The auxiliary verb "do" requires the base form of the verb.

#### Section 2.1.2, paragraph 3
```
okenChallenge). * "token_key_id" is an Nid-octet identifier for the the toke
                                    ^^
```
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

#### Section 2.1.2, paragraph 3
```
id" is an Nid-octet identifier for the the token authentication key. The val
                                  ^^^^^^^
```
Possible typo: you repeated a word.

#### Section 2.2, paragraph 12
```
sure a good user experience. Tokens challenges can be performed without expl
                            ^^^^^^^^^^^^^^^^^
```
Possible agreement error.

## 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 comment]
Thank you for the work done on this document. As it is fairly outside of my area of expertise, I trust the responsible AD on the actual contents.

I have nevertheless some non-blocking comments:

1) the abstract is really opaque for a newcomer, suggest to define what 'privacy pass' is used for

2) section 2.1.1, I strongly suggest to avoid linking anything to an IP address/prefix has devices can switch between IPv6/IPv4 (happy eyeball) or multiple interfaces (cellular / Wi-Fi)

3) section 2.1.1, I find weird the use of 'location' for an IP address as it hints to geographical location and mobile devices can change geographical locations while keeping the same IP address

Hope this helps

-éric

[Ballot discuss]
(a) There is guidance in the architecture and issuance documents; and this document to construct an end-to-end solution.  However, for the purposes of these document, those other are only informative.  There appears to be a few places of under-specification or implicit assumptions.

** Section 2.2
  For token types that support public verifiability, origins verify the
  token authenticator using the public key of the issuer, and validate
  that the signed message matches the concatenation of the client nonce
  and the hash of a valid TokenChallenge. 

-- Please explain what “public verifiability” means.  I didn’t see this term in the architecture document.

-- Implementation details of the authenticator/token seem to be leaking into this text (i.e., properties of the nonce || hash TokenChallenge).  Does this suggest requirements for the construction of the token? Put in another way, where is the normative guidance that requires that construction?  I couldn’t find other language in this document on the cryptographic properties of the Token.

** Section 2.2.  Since this section is describing the redemption process, I missed something obvious -- how does the origin know it got a “good” token”.  I was expecting to see language which say that there is a token-specific verification steps of the Token’s cryptographic assurances.

(b) Section 2.2. 
  *  "challenge_digest" is a 32-octet value containing the hash of the
      original TokenChallenge, SHA256(TokenChallenge).

It appears that challenge_digest uses a hard coded hash function (SHA256).  What is the hash agility plan?

[Ballot comment]
** Section 1.  Typo. s/authentiation/authentication/

** Section 2.
  Origins SHOULD minimize the number of challenges sent on a particular
  client session, such as a unique TLS session between a client and
  origin (referred to as the "redemption context" in [ARCHITECTURE]).
  Clients can have implementation-specific policy to minimize the
  number of tokens that can be retrieved by origins, so origins are
  advised to only request tokens when necessary within a single
  session.

-- Why does the origin guidance use normative language but the client guidance does not – i.e., s/Clients can have/Clients MAY have/.

-- Why repeat “so origins are advised to only request tokens when necessary within a single session”, if the prior sentence already uses a SHOULD to caution against this behavior.

** Section 2.1

*  "token-key", which contains a base64url encoding of the public key
      for use with the issuance protocol indicated by the challenge.

Recommend adding language to remind the reader that the procedures of the issuance protocol are out of scope.

** Section 2.2. 
  *  "challenge_digest" is a 32-octet value containing the hash of the
      original TokenChallenge, SHA256(TokenChallenge).

-- Please provide a normative reference to SHA256.

** Section 2.2.  Typo. s/the the/the/

** Section 2.2.
*  "authenticator" is a Nk-octet authenticator that covers the
      preceding fields in the token.  The value of this field is defined
      by the token_type and corresponding issuance protocol.  The value
      of constant Nk depends on token_type, as defined in Section 5.2.

-- Could a bit more be said about the purpose of this field.  Please also explain what “cover” means in this context.

-- Will the security properties of these authenticators vary by token_type?  If so, please explicitly state that?

** Section 3.
  Origins need not block useful work on token
  authentication.  Instead, token authentication can be used in similar
  ways to CAPTCHA validation today, but without the need for user
  interaction.  If issuance is taking a long time, a website could show
  an indicator that it is waiting, or fall back to another method of
  user validation.

Can “Origins need not block useful work on token authentication”, please be clarified?  Specifically:

-- What is “useful work”?

-- Isn’t a website displaying an indicator that it is waiting blocking use of the website?

** Section 3.
  An origin MUST NOT assume that token challenges will always yield a
  valid token.  Clients might experience issues running the issuance
  protocol, e.g., because the attester or issuer is unavailable, or
  clients might simply not support the requested token type.  Origins
  SHOULD account for such operational or interoperability failures by
  offering clients an alternative type of challenge such as CAPTCHA for
  accessing a resource.

If the origin _MUST_ assumed that a challenge might not always yield a token, is the origin willing to not have the clients connect?  I ask because the fall back mechanism is framed only as a “SHOULD”?

** Section 3.

  In particular, clients SHOULD ignore token
  challenges with some non-zero probability.  Likewise, origins SHOULD
  randomly choose to not challenge clients for tokens with some non-
  zero probability.

-- Since there is normative guidance around greasing, what is a/the recommended probability values?

-- Is this normative guidance saying that periodically clients SHOULD fail intentionally per some distribution?

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

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

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

First, in the Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry located at:

https://www.iana.org/assignments/http-authschemes/

a new authentication scheme is to be registered as follows:

Authentication Scheme Name: PrivateToken
Reference: [ RFC-to-be; Section 2 ]
Notes:

Second, a new registry is to be created on a new page in the IANA Matrix located at:

https://www.iana.org/protocols

The new registry will be named the Privacy Pass Token Type registry. The new Registry Page will be named "Privacy Pass Parameters." The identifiers will range from 0 - 65535. The registry policy for the new registry is Specification Required as defined by RFC8126.

The new registry has initial values as follows:

Token TokenChallenge Publicly Public Private
Value Name Structure Verifiable Metadata Metadata Nk Nid Reference Notes
-------+----------+------------+---------------+-------------+----------+-------------+-----+------------+-----------------+-----
0x0000 Reserved N/A N/A N/A N/A N/A [ RFC-to-be ]

0x0001-
0x02A9 Unassigned

0x02AA Reserved N/A N/A N/A N/A N/A [ RFC-to-be ]

0x02AB-
0x1131 Unassigned

0x1132 Reserved N/A N/A N/A N/A N/A [ RFC-to-be ]

0x1133-
0x2E95 Unassigned

0x2E96 Reserved N/A N/A N/A N/A N/A [ RFC-to-be ]

0x2E97-
0x3CD2 Unassigned

0x3CD3 Reserved N/A N/A N/A N/A N/A [ RFC-to-be ]

0x3CD4-
0x4472 Unassigned

0x4473 Reserved N/A N/A N/A N/A N/A [ RFC-to-be ]

0x4474-
0x5A62 Unassigned

0x5A63 Reserved N/A N/A N/A N/A N/A [ RFC-to-be ]

0x5A64-
0x6D31 Unassigned

0x6D32 Reserved N/A N/A N/A N/A N/A [ RFC-to-be ]

0x6D33-
0x7F3E Unassigned

0x7F3F Reserved N/A N/A N/A N/A N/A [ RFC-to-be ]

0x7F40-
0x8D06 Unassigned

0x8D07 Reserved N/A N/A N/A N/A N/A [ RFC-to-be ]

0x8D08-
0x916A Unassigned

0x916B Reserved N/A N/A N/A N/A N/A [ RFC-to-be ]

0x916C-
0xA6A3 Unassigned

0xA6A4 Reserved N/A N/A N/A N/A N/A [ RFC-to-be ]

0xA6A5-
0xBEAA Unassigned

0xBEAB Reserved N/A N/A N/A N/A N/A [ RFC-to-be ]

0xBEAC-
0xC3F2 Unassigned

0xC3F3 Reserved N/A N/A N/A N/A N/A [ RFC-to-be ]

0xC3F4-
0xDA41 Unassigned

0xDA42 Reserved N/A N/A N/A N/A N/A [ RFC-to-be ]

0xDA43-
0xE943 Unassigned

0xE944 Reserved N/A N/A N/A N/A N/A [ RFC-to-be ]

0xE945-
0xF056 Unassigned

0xF057 Reserved N/A N/A N/A N/A N/A [ RFC-to-be ]

0xF058-
0xFEFF Unassigned

0xFF00-
0xFFFF Private Use N/A N/A N/A N/A N/A [ RFC-to-be ]

The IANA Functions Operator understands that these are the only actions 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 Specialist

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

From: The IESG
To: IETF-Announce
CC: draft-ietf-privacypass-auth-scheme@ietf.org, ietf@bemasc.net, 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 HTTP Authentication Scheme) to Proposed Standard


The IESG has received a request from the Privacy Pass WG (privacypass) to
consider the following document: - 'The Privacy Pass HTTP Authentication
Scheme'
  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-07-07. 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 defines an HTTP authentication scheme that can be used
  by clients to redeem Privacy Pass tokens with an origin.  It can also
  be used by origins to challenge clients to present an acceptable
  Privacy Pass token.




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



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

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

The document is intended to address a specific charter point for the PRIVACYPASS
working group: to "specify a HTTP-layer API for the protocol".  Initial proposals
defined a REST API, but the proposal was ultimately streamlined to this form. The
working group has a clear consensus that this is the right approach and adequately
addresses the need for an "HTTP-layer API".

> 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 and enables the use of Privacy Pass tokens
in HTTP.  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 three 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.

The document is intended to address a specific charter point for the PRIVACYPASS
working group: to "specify a HTTP-layer API for the protocol".  Initial proposals
defined a REST API, but the proposal was ultimately streamlined to this form. The
working group has a clear consensus that this is the right approach and adequately
addresses the need for an "HTTP-layer API".

> 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 and enables the use of Privacy Pass tokens
in HTTP.  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 three 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/