[Openid-specs-fapi] padding of s_hash with =

Joseph Heenan joseph at authlete.com
Wed Feb 7 03:24:01 UTC 2018


Hi Nat,

Thanks. I agree it is defined there, but OIDC Core doesn't appear to state that this is the definition it is using!

(It is unhelpful that RFC7515 and RFC4648 both define the term 'base64url', but in different ways.)

Joseph


> On 7 Feb 2018, at 12:07, Nat Sakimura <nat at sakimura.org> wrote:
> 
> It is defined in RFC7515
> 
> Quote: 
> 
> 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.) 
> 
> 
> Outlook for Android <https://aka.ms/ghei36> から取得
> 
> 
> 
> 
> On Wed, Feb 7, 2018 at 9:56 AM +0900, "Joseph Heenan" <joseph at authlete.com <mailto:joseph at authlete.com>> wrote:
> 
> Hi Nat,
> 
> As per discussion on the FAPI WG call, I'm struggling to understand where in the specs it says that the base64url encoding of s_hash (and c_hash and at_hash) are not padded with '='.
> 
> I fully accept that for all practical purposes these should not be padded, but I can't find where in the specs it says that. One vendor is padding s_hash and believes they are compliant with the spec as written.
> 
> http://openid.net/specs/openid-connect-core-1_0.html <http://openid.net/specs/openid-connect-core-1_0.html> says simply "base64url encoded". It doesn't appear to reference any specific spec for base64url.
> 
> The canonical reference for base64url is I believe https://tools.ietf.org/html/rfc4648#section-5 <https://tools.ietf.org/html/rfc4648#section-5>
> 
> This states:
> 
>>    The pad character "=" is typically percent-encoded when used in an
>>    URI [9 <https://tools.ietf.org/html/rfc4648#ref-9>], but if the data length is known implicitly, this can be
>>    avoided by skipping the padding; see section 3.2 <https://tools.ietf.org/html/rfc4648#section-3.2>.
> 
> 
> and section 3.2 states:
> 
>>    Implementations MUST include appropriate pad characters at the end of
>>    encoded data unless the specification referring to this document
>>    explicitly states otherwise.
> 
> This clearly states the value should be padded, as OIDC does not explicitly say padding should be skipped.
> 
> I searched further and found https://tools.ietf.org/html/rfc7515 <https://tools.ietf.org/html/rfc7515>. This does explicitly state:
> 
>>    Base64url Encoding
>>       Base64 encoding using the URL- and filename-safe character set
>>       defined in Section 5 of RFC 4648 <https://tools.ietf.org/html/rfc4648#section-5> [RFC4648 <https://tools.ietf.org/html/rfc4648>], with all trailing '='
>>       characters omitted (as permitted by Section 3.2 <https://tools.ietf.org/html/rfc7515#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 <https://tools.ietf.org/html/rfc7515#appendix-C> for notes on
>>       implementing base64url encoding without padding.)
> 
> 
> So it appears we have two RFCs, which defines base64url differently.
> 
> OIDC Core does not appear to explicitly state which definition of base64url it is using - can you point at anything I've missed?
> 
> I think perhaps the FAPI definition of s_hash should explicitly reference rfc7515's definition.
> 
> Thanks
> 
> Joseph
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20180207/8da755a9/attachment-0001.html>


More information about the Openid-specs-fapi mailing list