Decide whether strict base64url belongs in this output-encoding library

[jmanico]

Reviewed 2026-09-25 (America/Los_Angeles) against main at bd249f5. Execution order and cross-issue ownership: #169. Batch 06.

This scope replaces the dated implementation prescriptions in the original report and earlier comments; linked historical evidence remains useful but must be rechecked before implementation.

Review disposition

The proposal delegates transport encoding to Java 8's Base64 API and proposes canonical decoding. No submitted implementation is present and no security regression is established. Its decoding/canonicalization surface conflicts with this library's documented output-encoding scope, so resolve that product/API decision before adding public methods or tag bindings.

• Record whether to reject, document JDK use, or accept a narrowly justified utility. Base64url is transport encoding, not XSS prevention, validation, authentication, encryption or token-signature verification.
• If accepted, specify byte/String types, canonical padding policy, null/error contracts, strict UTF-8 decoding and malformed UTF-16 handling for String encoding. Default UTF-8 replacement can silently map different Java strings to the same bytes; choose/reject explicitly.
• Define rejection of nonalphabet/whitespace, invalid lengths, padding variants and nonzero trailing bits; errors must not echo input. Test canonical round trips and negative cases with the JDK codec as an implementation primitive, not a new codec implementation.
• Specify bounded allocation/Writer semantics for large input and explain why byte grouping does not fit the existing char-to-char Encoder/EncodedWriter contract.
• Decide whether view-layer exposure is useful; if accepted, encoding only, no decoder tags, and update facade/TLD/parity tests deliberately rather than weakening Guard facade mappings and JSP/Jakarta parity #167's invariants.
• Document output-context restrictions and version the new API deliberately. Leave ESAPI delegates unchanged.

Implementation is deferred pending this explicit decision. #142/#128 own the larger scope/versioning policy. Deferral is not evidence that 1.5's backlog gate is complete.

[Akhil-1527]

Hi, I'd like to work on this one. I'd follow the proposal in the issue: a new org.owasp.encoder.Base64Url class built on java.util.Base64, unpadded output as the canonical form, and a strict decoder that only accepts input that re-encodes to the same string, with an error that doesn't echo the input. Encode.forBase64Url would forward to it, and both taglibs would get the forBase64Url tag and EL function. I'd include the tests, Javadoc, README and CHANGELOG updates from the acceptance criteria. Could you assign it to me?