RFC 7515, "JSON Web Signature (JWS)", May 2015

Errata ID: 8508
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Ryan Desmond
Date Reported: 2025-07-11
Rejected by: Deb Cooley
Date Rejected: 2025-10-28

Section Sec 2, Appendix C says:

2.  Terminology

   These terms are defined by this specification:

   Base64url Encoding
      Base64 encoding using the URL- and filename-safe character set
      defined in Section 5 of RFC 4648 [RFC4648], with all trailing '='
      characters omitted (as permitted by Section 3.2) and without the
      inclusion of any line breaks, whitespace, or other additional
      characters.  Note that the base64url encoding of the empty octet
      sequence is the empty string.  (See Appendix C for notes on
      implementing base64url encoding without padding.)


Appendix C.  Notes on Implementing base64url Encoding without Padding

   This appendix describes how to implement base64url encoding and
   decoding functions without padding based upon standard base64
   encoding and decoding functions that do use padding.

   To be concrete, example C# code implementing these functions is shown
   below.  Similar code could be used in other languages.

   ...

     static byte [] base64urldecode(string arg)
     {
       string s = arg;
       s = s.Replace('-', '+'); // 62nd char of encoding
       s = s.Replace('_', '/'); // 63rd char of encoding
       switch (s.Length % 4) // Pad with trailing '='s
       {
         case 0: break; // No pad chars in this case
         case 2: s += "=="; break; // Two pad chars
         case 3: s += "="; break; // One pad char
         default: throw new System.Exception(
           "Illegal base64url string!");
       }
       return Convert.FromBase64String(s); // Standard base64 decoder
     }

   As per the example code above, the number of '=' padding characters
   that needs to be added to the end of a base64url-encoded string
   without padding to turn it into one with padding is a deterministic
   function of the length of the encoded string.  Specifically, if the
   length mod 4 is 0, no padding is added; if the length mod 4 is 2, two
   '=' padding characters are added; if the length mod 4 is 3, one '='
   padding character is added; if the length mod 4 is 1, the input is
   malformed.

It should say:

2.  Terminology

   These terms are defined by this specification:

   Base64url Encoding
      Base64 encoding using the URL- and filename-safe character set
      defined in Section 5 of RFC 4648 [RFC4648], all trailing '='
      characters SHOULD be omitted (as permitted by Section 3.2) and
      any line breaks, whitespace, or other additional characters SHALL
      be excluded.  Note that the base64url encoding of the empty octet
      sequence is the empty string.  (See Appendix C for notes on
      implementing base64url encoding without padding.)


Appendix C.  Notes on Implementing base64url Encoding without Padding

      ...

      NOTE: The decoding function allows padded input, which is not recommended.

Notes:

The definition for Base64url is more strict than RFC4648, but doesn't qualify that with keyword from RFC 2119. The corrected text uses RFC 2119 keywords to be more specific and consistent. I do propose allowing but discouraging extraneous padding, which is currently ambiguous. An alternate solution would be using SHALL be omitted in the definition and either adding a note in appendix C or a conditional to throw an exception for non-compliant input.
--VERIFIER NOTES--
The term definition clearly says what “Base64url Encoding” means in this specification.
Among other things, it meaning of that term includes the detail "with all trailing '=' characters omitted” — unconditionally so.

The proposed replacement text would replace this clear definition with a “SHOULD”, which is incorrect — there is no circumstance in which a “=“ is permitted in RFC 7515 “Base64url Encoding”.

The proposed change would be a deviation from the WG intent.

Report New Errata