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.