Subject: [OAUTH-WG] Saml2 Bearer and base64url question

From: Sergey Beryozkin <[email-masked]>
Date: Mon, 18 Feb 2013 16:13:48 +0000

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

---

From: John Bradley <[email-masked]>
Date: Mon, 18 Feb 2013 13:54:49 -0300

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.   

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.

John B.

On 2013-02-18, at 1:13 PM, Sergey Beryozkin <[email-masked]> wrote:

> - 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
> 
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Sergey Beryozkin <[email-masked]>
Date: Mon, 18 Feb 2013 17:00:35 +0000

> 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<[email-masked]>  wrote:
>
>> Hi,
>>
>> RFC4648 [1] says:
>>