Subject: [OAUTH-WG] [Errata Verified] RFC7800 (6187)

From: RFC Errata System <[email-masked]>
Date: Sat, 30 May 2020 18:34:04 -0700 (PDT)

The following errata report has been verified for RFC7800,
"Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)". 

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6187

--------------------------------------
Status: Verified
Type: Editorial

Reported by: Pete Resnick <[email-masked]>
Date Reported: 2020-05-26
Verified by: Benjamin Kaduk (IESG)

Section: 7.1

Original Text
-------------
   [JWK]      Jones, M., "JSON Web Key (JWK)", RFC 7517,
              DOI 10.17487/RFC7157, May 2015,
              <http://www.rfc-editor.org/info/rfc7517>.

Corrected Text
--------------
   [JWK]      Jones, M., "JSON Web Key (JWK)", RFC 7517,
              DOI 10.17487/RFC7517, May 2015,
              <http://www.rfc-editor.org/info/rfc7517>.

Notes
-----
DOI has a typo: 7157 instead of 7517.

--------------------------------------
RFC7800 (draft-ietf-oauth-proof-of-possession-11)
--------------------------------------
Title               : Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)
Publication Date    : April 2016
Author(s)           : M. Jones, J. Bradley, H. Tschofenig
Category            : PROPOSED STANDARD
Source              : Web Authorization Protocol
Area                : Security
Stream              : IETF
Verifying Party     : IESG

---

From: "Pete Resnick" <[email-masked]>
Date: Sat, 30 May 2020 22:55:01 -0500

"Verified", not "Hold For Document Update"?

pr

-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 30 May 2020 21:09:24 -0700

The new text is clearly the right thing, and there is no need
to debate it if/when the document gets updated.  "Don't hold
it; do it now", so to speak -- and noting that (my
understanding/recollection of) the plan for
https://www.rfc-editor.org/rfc/inline-errata/rfc7800.html is that only
verified errata, not those in other states, will be displayed.

(Yes, that link 404s at the moment, I assume a caching issue.)

-Ben

---

From: "Pete Resnick" <[email-masked]>
Date: Sat, 30 May 2020 23:22:33 -0500

But 
https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/, 
in particular:

1. Only errors that could cause implementation or deployment problems or 
significant confusion should be Verified.
2. Things that are clearly wrong but could not cause an implementation 
or deployment problem should be Hold for Document Update.
5. Typographical errors which would not cause any confusions to 
implementation or deployments should be Hold for Document Update.

Did something change these criteria?

pr

---

From: Barry Leiba <[email-masked]>
Date: Sun, 31 May 2020 13:47:02 -0400

> But https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/, in particular:
>
> Only errors that could cause implementation or deployment problems or significant confusion should be Verified.
> Things that are clearly wrong but could not cause an implementation or deployment problem should be Hold for Document Update.
> Typographical errors which would not cause any confusions to implementation or deployments should be Hold for Document Update.
>

They're guidelines, not absolute rules, and judgment is expected.  I
support the guidelines, but I also appreciate and support Ben's good
judgment.  I, at least, am happy to leave it at that.

(That said, I did mark John Levine's errata report against RFC 20 as HFDU....)

Barry

---

From: "Pete Resnick" <[email-masked]>
Date: Sun, 31 May 2020 12:58:54 -0500

On 31 May 2020, at 12:47, Barry Leiba wrote:

>> Only errors that could cause implementation or deployment problems or 
>> Things that are clearly wrong but could not cause an implementation 
>> Typographical errors which would not cause any confusions to 
> They're guidelines, not absolute rules, and judgment is expected.

Sure, but I was replying to Ben's statement that, "The new text is 
clearly the right thing, and there is no need to debate it if/when the 
document gets updated.  'Don't hold it; do it now', so to speak". That's 
not what Verified ever meant before. If the meaning has changed, that's 
fine, but someone should let the community know and update the IESG 
Statement. (Personally, I'm all for that, as I've found the current 
definitions absurd and confusing. All clearly wrong Editorial errata 
should be marked "Verified", IMO.) But that's not about applying 
judgement; that's changing the definition of the terms used.

pr

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 31 May 2020 15:27:42 -0700

> document gets updated.  'Don't hold it; do it now', so to speak". That's 

To be clear, that was an off-the-cuff remark and not a considered opinion.

> definitions absurd and confusing. All clearly wrong Editorial errata 

They're also not especially internally consistent.  The first point quoted
lists causing "significant confusion" as grounds for Verified, but the
second point doesn't, even though it lists the other two items and one
might expect it to mirror the first point.

Would having a link to go a completely different document than one should
be seeing cause "significant confusion"?  For some people, I think it
would.  I've certainly had such cases, myself, before -- IIRC I put a
Discuss on a document that referenced RFC 7519 when it meant 7159 (in that
case, the "wrong" document was close-enough to topical to be plausible,
albeit incorrect).

-Ben