Subject: [Unbearable] Base64url encoding in draft-ietf-tokbind-https

From: John Bradley <[email-masked]>
Date: Fri, 29 Jul 2016 18:30:26 -0400

Brian Campbell has pointed out to me that in testing Chrome 54.0.2811.0 it is sending Sec-Token-Binding headers with padding.

In https://tools.ietf.org/html/draft-ietf-tokbind-https-05#section-2 <https://tools.ietf.org/html/draft-ietf-tokbind-https-05#section-2> we say
 The header field name is "Sec-Token-Binding", and
   EncodedTokenBindingMessage is a base64url encoding (see [RFC4648]
   Section 5 <https://tools.ietf.org/html/rfc4648#section-5>) of the TokenBindingMessage as defined in
   [I-D.ietf-tokbind-protocol <https://tools.ietf.org/html/draft-ietf-tokbind-https-05#ref-I-D.ietf-tokbind-protocol>]

When we did JOSE we found RFC4648 <https://tools.ietf.org/html/rfc4648#section-5> a touch to vague on padding.  in principal encoders and decoders will work both ways.
However for interoperability and space saving we required the producer to send non padded to avoid confusion.

We also added a appendix to help people with base64url without padding.
https://tools.ietf.org/html/rfc7515#appendix-C <https://tools.ietf.org/html/rfc7515#appendix-C>

Can the authors  look at clarifying this,  as written sending with or without padding is allowed by my reading.

Including the appendix would also be fine with me if people think it would help clarify things for developers.

Thanks.

John B.