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

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

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.

I support Francesca's DISCUSS.

Thank you for addressing my DISCUSS and COMMENT feedback.

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

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.

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

# 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

Discussed cleared.  Thanks for accommodating.