On 18/02/13 16:54, John Bradley wrote:
A base64url decoder doesn't need the padding bytes in this case. They are
really only useful if you are concatenating outputs together. The number of
missing pads characters can be calculated from the number of base64url encoded
octets to be decoded.
So the padding and any other line wraps SHOULD NOT be included. If the
recipient is known to have a problem with missing padding then they must be
%encoded if the transport requires it.
The above is helpful, thanks
I will grant you that changing it to MUST NOT may be clearer to people. I
suspect that it is easier to fix broken decoders than try and accommodate them.
Now that I have a better understanding, either SHOULD or MUST will work
for me at least :-)
Cheers, Sergey
John B.
On 2013-02-18, at 1:13 PM, Sergey Beryozkin<sberyoz...@gmail.com> wrote:
Hi,
RFC4648 [1] says:
"The pad character "=" is typically percent-encoded when used in an
URI [9], but if the data length is known implicitly, this can be
avoided by skipping the padding; see section 3.2."
while the SAML2 Bearer token draft says:
"The SAML Assertion XML data MUST be encoded using
base64url, where the encoding adheres to the definition in Section 5
of RFC4648 [RFC4648] and where the padding bits are set to zero. To
avoid the need for subsequent encoding steps (by "application/
x-www-form-urlencoded" [W3C.REC-html401-19991224], for example), the
base64url encoded data SHOULD NOT be line wrapped and pad characters
("=") SHOULD NOT be included."
I'd appreciate some clarifications on the above:
- SHOULD NOT implies that actually including the pad characters("=") is still
going to work, right ? Why was it so important that the spec decided to mention it at all
?
- 'SHOULD NOT be included' implies the pad characters ("=") will be
percent-encoded or not included at all ? If it is the latter, how will the decoder
correctly read the assertion ?
Thanks, Sergey
[1] http://tools.ietf.org/html/rfc4648#section-5
[2] http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-15#section-2.1
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
