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 90DBD3A684A for ; Sat, 3 Jul 2010 12:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.861 X-Spam-Level: X-Spam-Status: No, score=-0.861 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, 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 UaorgnoqkB33 for ; Sat, 3 Jul 2010 12:14:46 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 36A2B3A6834 for ; Sat, 3 Jul 2010 12:14:46 -0700 (PDT) Received: by iwn10 with SMTP id 10so2062155iwn.31 for ; Sat, 03 Jul 2010 12:14:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=+P+9UjxpD5Zw7CKIko5jQp/1+8rbF1SLabXFkkfZpF0=; b=mTNJOVc9qrlpZebheYmGF7WnHZRY5vi8uGjo3twtJTMLoaPf8LbAgIkc4MtMKVPhCh LEsdmk4feerTdvU98+KHojjTdeTWGBkZwh/ThLc2zxvBWp2mSvri8FBcI7uExI7NCxr6 u2SgRK3Lwq+QH0jnZbFgxqxvl4lZKxeQFABEM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=vRi8qhJiKPf0QvHsTYM5NCMya075PCNGJ5wNr6iMHuYOif4+L75FZkpobEMgpOsTrT aP8skZ1pZmekRexijXQrYh1jFIQeK3D0o7Dl1mQZbPYqJklHYSezIm/OwlMmCoNApv8D aewy6fRCGuirDHJsU3zXJFo9N1T47ObEjW+Dg= Received: by 10.231.37.7 with SMTP id v7mr818726ibd.147.1278184498423; Sat, 03 Jul 2010 12:14:58 -0700 (PDT) MIME-Version: 1.0 Sender: naitiks@gmail.com Received: by 10.231.170.9 with HTTP; Sat, 3 Jul 2010 12:14:38 -0700 (PDT) In-Reply-To: <6B008ED4-4536-4A95-89B6-917696E6AF79@gmail.com> References: <2625894F-2979-40BD-81E1-05A6EB8723CD@facebook.com> <3DC7AEF8-3283-4970-BB98-3D680A3E2429@gmail.com> <6B008ED4-4536-4A95-89B6-917696E6AF79@gmail.com> From: Naitik Shah Date: Sat, 3 Jul 2010 12:14:38 -0700 X-Google-Sender-Auth: vb0t0-po7KEx7E0XO1sg2gPAT-A Message-ID: To: Dick Hardt Content-Type: multipart/alternative; boundary=0003255759fefc6751048a808492 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 19:14:48 -0000 --0003255759fefc6751048a808492 Content-Type: text/plain; charset=UTF-8 On Sat, Jul 3, 2010 at 9:42 AM, Dick Hardt wrote: > > 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. >> >> 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 + / = 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. > The thing I was trying to say was that it's less predictable. That it might work just fine when you're experimenting with the API because at that point your token did not contain any pluses, but then suddenly started failing after you sent a link to your app to someone because their encoded token contains a plus. This hit-or-miss to me is worse than being able to tell by looking at the first few characters of the urlencoded JSON blob which will give a definitive answer as to how many times the token has been urlencoded. > >> 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. > > Exactly :) I'm imagining our documentation where we want to be library agnostic, and have almost psuedo code like code snippets. I said this earlier -- while base64 may be common in standard libraries built into languages, the base64url version isn't. In order to not have a "cpan install base64url" (and gem install, easy_install, mvn install..) -- we'ed most likely document a str_replace() call in addition to a base64 call. And I'm worried that developers will miss this detail. > > > > >> > >> >> 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. > I agree multiple encodings makes libraries harder :) But I think the stark difference between OAuth1 vs 2 wrt to signing actually makes the Authorization header less valuable (again, for signing only). I'm pretty happy with this because I thought this header was more complex for developers anyways (while big corporations with authentication infrastructure love it) :) But the reason I think so is that now the header is not just the signature, but also the signed payload. This means an application isn't just making a http request as before with a bunch of query or post parameters. It's instead making a "JSON request" that may or may not have query/post params. It's just not as separate as before. > > > >> > * 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. > > Yep, this and all the reasons you and Luke mentioned in the parallel thread. -Naitik --0003255759fefc6751048a808492 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Jul 3, 2010 at 9:42 AM, Dick Hardt <dick.hardt@gmail.com> wrote:

On 2010= -07-03, at 9:13 AM, Naitik Shah wrote:
> I think Naitik is saying that accidentally doing base64 and not b= ase64url will send some '+'s along.

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

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

The pluses are not=C2= =A0guaranteed. They may or may not be there depending on the data stream yo= u're encoding. If you don't urlencode the JSON, you'll get a &q= uot;{", 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 de= velopers may incorrectly use base64 instead of base64url. If they used base= 64, and if there is a + / =3D or % in the string, the server can send a use= ful note saying what is wrong. There may not be one of those characters dep= ending on the input string, but if there is, then the server can suggest wh= at the error might be using base64 instead of base64url. If the token conta= ins 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 s= hould never get any %7B or other encoding in the token as it is url safe.

The thing I was trying to = say was that it's less predictable. That it might work just fine when y= ou're experimenting with the API because at that point your token did n= ot contain any pluses, but then suddenly started failing after you sent a l= ink to your app to someone because their encoded token contains a plus. Thi= s hit-or-miss to me is worse than being able to tell by looking at the firs= t few characters of the urlencoded JSON blob which will give a definitive a= nswer as to how many times the token has been urlencoded.

=C2=A0
=

When I wrote a sample in Perl, it was pretty easy to make it base64ur= l which then provides a consistent encoding.

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

I used a standard CPAN library= .


=
Exactly :) I'm imagining our documentation where we want to be lib= rary agnostic, and have almost psuedo code like code snippets. I said this = earlier -- while base64 may be common in standard libraries built into lang= uages, the base64url version isn't. In order to not have a "cpan i= nstall base64url" (and gem install, easy_install, mvn install..) -- we= 'ed most likely document a str_replace() call in addition to a base64 c= all. And I'm worried that developers will miss this detail.

=C2=A0
=
=C2=A0



>
>> I am unclear on what your point is.
>>
>> The token would be included as one of the headers. This is often p= referable as it separates the authorization layer (in header) from applicat= ion layer parameters (query string or message body)
>
> With our proposal, we were focussed on url parameters (hence the choic= e 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 choi= ce dictate which encoding to use.

I understand what you are saying. having multiple encodings makes lib= raries harder, and leads to the issues that motivated base64url over url-en= coding=C2=A0

Glad we ag= ree on that.

I agree multiple encodings makes lib= raries harder :)

But I think the stark difference = between OAuth1 vs 2 wrt to signing actually makes the Authorization header = less valuable (again, for signing only). I'm pretty happy with this bec= ause I thought this header was more complex for developers anyways (while b= ig corporations with authentication infrastructure love it) :) But the reas= on I think so is that now the header is not just the signature, but also th= e signed payload. This means an application isn't just making a http re= quest as before with a bunch of query or post parameters. It's instead = making a "JSON request" that may or may not have query/post param= s. It's just not as separate as before.


=C2=A0

>
> * 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, w= hich makes the left split easier.

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

=

Yep, this and all the reasons= you and Luke mentioned in the parallel thread.



-Naitik
--0003255759fefc6751048a808492--