Return-Path: X-Original-To: oauth@core3.amsl.com Delivered-To: oauth@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAA143A67F4 for ; Sat, 3 Jul 2010 09:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.682 X-Spam-Level: X-Spam-Status: No, score=-1.682 tagged_above=-999 required=5 tests=[AWL=-0.573, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WfxLumYe47nr for ; Sat, 3 Jul 2010 09:42:25 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 8E57A3A67D0 for ; Sat, 3 Jul 2010 09:42:25 -0700 (PDT) Received: by pxi20 with SMTP id 20so2153014pxi.31 for ; Sat, 03 Jul 2010 09:42:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:message-id:references:to :x-mailer; bh=v8bE6SQDUAGRWJ+YqT8fF1nZ81HuYUo6oSvcu9cJzFA=; b=deTvnQmHJDefU0IICt/By3jTsdbloXYK3RiU5hII4U5n3o1Rc6i+hVtBuO5x3Vmxgl /nupGdh5SVLnkCiW1zX0jlxbGKCYSpUhtylPOkOPxTWyFRw1pFYBOG37/ZA1fQrz1c5E rfhafbC8ZGa/l6vPsBmMJkDvbjpVI/bxgXEjQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=CCt7u9tzALkvvSXp0YDnvmj/3/OqUHt0NoawwH9OdZ15nIUSyBbgEnDQHq+1OMOKQc uRsYiNJitWjqDE6HiBKUo5I45Tly1T7PWS7YwAY86VkUEEyb5d0dE01B+l9Je3ULaC2P cSuaQ4OJ3Qsa6vCBF7SAooIB222aAN+mtvHXM= Received: by 10.114.57.14 with SMTP id f14mr570676waa.180.1278175355620; Sat, 03 Jul 2010 09:42:35 -0700 (PDT) Received: from [192.168.1.5] ([24.130.32.55]) by mx.google.com with ESMTPS id k23sm30849126waf.17.2010.07.03.09.42.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 03 Jul 2010 09:42:34 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-1--779557441 From: Dick Hardt In-Reply-To: Date: Sat, 3 Jul 2010 09:42:33 -0700 Message-Id: <6B008ED4-4536-4A95-89B6-917696E6AF79@gmail.com> References: <2625894F-2979-40BD-81E1-05A6EB8723CD@facebook.com> <3DC7AEF8-3283-4970-BB98-3D680A3E2429@gmail.com> To: Naitik Shah X-Mailer: Apple Mail (2.1081) Cc: OAuth WG Subject: Re: [OAUTH-WG] Understanding the reasoning for Base64 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 16:42:26 -0000 --Apple-Mail-1--779557441 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2010-07-03, at 9:13 AM, Naitik Shah wrote: > > I think Naitik is saying that accidentally doing base64 and not = base64url will send some '+'s along. >=20 > if there are '+'s in the token, then it is easy for someone helping to = spot the problem. also easy for servers to send back an error message = saying, "hey, looks like you are using base64 instead of base64url = encoding" >=20 > ie, it is easy to detect the error -- urlencoding / decoding is hard = to detect as an error >=20 > The pluses are not guaranteed. They may or may not be there depending = on the data stream you're encoding. If you don't urlencode the JSON, = you'll get a "{", if you do it once, you'll get a "%7B", if you do it = twice, you'll get a "%257B" -- seems easier to detect. Your earlier point was that developers may incorrectly use base64 = instead of base64url. If they used base64, and if there is a + / =3D or = % in the string, the server can send a useful note saying what is wrong. = There may not be one of those characters depending on the input string, = but if there is, then the server can suggest what the error might be = using base64 instead of base64url. If the token contains ANY character = that is not in base64url, then the server can say that it is not = base64url encoded. That seems pretty fool proof to detect. Note that you should never get = any %7B or other encoding in the token as it is url safe. >=20 > When I wrote a sample in Perl, it was pretty easy to make it base64url = which then provides a consistent encoding. >=20 > Did it involve a string replace call? Or a third party library? I used a standard CPAN library. > =20 >=20 >=20 >=20 > > > >> I am unclear on what your point is. > >> > >> The token would be included as one of the headers. This is often = preferable as it separates the authorization layer (in header) from = application layer parameters (query string or message body) > > > > With our proposal, we were focussed on url parameters (hence the = choice of urlencode after it was all put together). I think it makes = total sense to not do the encoding as part of the sig spec, and let the = transport choice dictate which encoding to use. >=20 > I understand what you are saying. having multiple encodings makes = libraries harder, and leads to the issues that motivated base64url over = url-encoding=20 Glad we agree on that. > > > > * We'd like the signature first (so you can left split instead of = right split) >=20 > What are the advantages of left split vs right split? >=20 > Built in split function with a limit is more common, which makes the = left split easier. Size limit I am assuming? Since the size of the signature is known, this = makes it safer to have it first? Makes sense to me. --Apple-Mail-1--779557441 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
> I think Naitik is saying = that accidentally doing base64 and not base64url will send some '+'s = along.

if there are '+'s in the token, then it is easy for someone = helping to spot the problem. also easy for servers to send back an error = message saying, "hey, looks like you are using base64 instead of = base64url encoding"

ie, it is easy to detect the error -- urlencoding / decoding is hard to = detect as an error

The pluses are = not guaranteed. They may or may not be there depending on the data = stream you're encoding. If you don't urlencode the JSON, you'll get a = "{", if you do it once, you'll get a "%7B", if you do it twice, you'll = get a "%257B" -- seems easier to = detect.

Your earlier point = was that developers may incorrectly use base64 instead of base64url. If = they used base64, and if there is a + / =3D or % in the string, the = server can send a useful note saying what is wrong. There may not be one = of those characters depending on the input string, but if there is, then = the server can suggest what the error might be using base64 instead of = base64url. If the token contains ANY character that is not in base64url, = then the server can say that it is not base64url = encoded.

That seems pretty fool proof to = detect. Note that you should never get any %7B or other encoding in the = token as it is url safe.
When I wrote a sample in Perl, it was pretty easy to make it = base64url which then provides a consistent = encoding.

Did it involve a string = replace call? Or a third party = library?

I used a standard = CPAN library.

 



>
>> I am unclear on what your point is.
>>
>> The token would be included as one of the headers. This is = often preferable as it separates the authorization layer (in header) = from application layer parameters (query string or message body)
>
> With our proposal, we were focussed on url parameters (hence the = choice of urlencode after it was all put together). I think it makes = total sense to not do the encoding as part of the sig spec, and let the = transport choice dictate which encoding to use.

I understand what you are saying. having multiple encodings makes = libraries harder, and leads to the issues that motivated base64url over = url-encoding 

Glad we = agree on that.

>
> * We'd like the signature first (so you can left split instead of = right split)

What are the advantages of left split vs right = split?

Built in split function with = a limit is more common, which makes the left split = easier.

Size limit I am = assuming? Since the size of the signature is known, this makes it safer = to have it first? Makes sense to = me.

= --Apple-Mail-1--779557441--