Re: [OAUTH-WG] Rename callback => callback_uri

Evan Gilbert <uidude@google.com> Fri, 16 April 2010 19:32 UTC

Return-Path: <uidude@google.com>
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 E9C773A691E for <oauth@core3.amsl.com>; Fri, 16 Apr 2010 12:32:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.64
X-Spam-Level:
X-Spam-Status: No, score=-105.64 tagged_above=-999 required=5 tests=[AWL=0.336, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 qPtX8fedZNZK for <oauth@core3.amsl.com>; Fri, 16 Apr 2010 12:32:02 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 5ADDB3A681F for <oauth@ietf.org>; Fri, 16 Apr 2010 12:32:00 -0700 (PDT)
Received: from kpbe12.cbf.corp.google.com (kpbe12.cbf.corp.google.com [172.25.105.76]) by smtp-out.google.com with ESMTP id o3GJVqU9002640 for <oauth@ietf.org>; Fri, 16 Apr 2010 12:31:52 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1271446312; bh=uGF6fHUtt9coQeQB7UI22oEVAr8=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=wID9+7ns/YrA8yZNcKdxH9xY8K5idvRxYg2h2F4kUQurYA15xuXRm9PNxGmL7mlNV 3di1olRulkVCiOKhidnFA==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:x-system-of-record; b=IM4gaSQM2Q9q2hzIjeoTYmxmdFPC1bwJ4yKueMTmSh01i18cj6wCHz6st32/qzHBu 8J/Zr03otkffno2dPPhug==
Received: from qw-out-1920.google.com (qwa14.prod.google.com [10.241.193.14]) by kpbe12.cbf.corp.google.com with ESMTP id o3GJVpWE001115 for <oauth@ietf.org>; Fri, 16 Apr 2010 12:31:51 -0700
Received: by qw-out-1920.google.com with SMTP id 14so389951qwa.8 for <oauth@ietf.org>; Fri, 16 Apr 2010 12:31:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.78.131 with HTTP; Fri, 16 Apr 2010 12:31:22 -0700 (PDT)
In-Reply-To: <E81D4800-784B-45B4-87A4-0C3960EB20C8@bbn.com>
References: <9C30AE64-7DB8-4B6B-879B-61CB71BF74BB@facebook.com> <C7EC567E.322EE%eran@hueniverse.com> <2513A610118CC14C8E622C376C8DEC93D54D66DCA7@SC-MBXC1.TheFacebook.com> <CA16E5C8-7987-4D5B-9038-E705E6630A07@bbn.com> <2513A610118CC14C8E622C376C8DEC93D54D66DCF5@SC-MBXC1.TheFacebook.com> <i2pc8689b661004161205g949c17a1z245fd80199140ea4@mail.gmail.com> <E81D4800-784B-45B4-87A4-0C3960EB20C8@bbn.com>
From: Evan Gilbert <uidude@google.com>
Date: Fri, 16 Apr 2010 12:31:22 -0700
Received: by 10.229.213.77 with SMTP id gv13mr1902147qcb.63.1271446304638; Fri, 16 Apr 2010 12:31:44 -0700 (PDT)
Message-ID: <h2hc8689b661004161231j7aeb103bzb3ceb76e2bf929@mail.gmail.com>
To: Richard Barnes <rbarnes@bbn.com>
Content-Type: multipart/alternative; boundary="0016362843aa57a24e04845fa97c"
X-System-Of-Record: true
Cc: Naitik Shah <naitik@facebook.com>, OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Rename callback => callback_uri
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Apr 2010 19:32:04 -0000

On Fri, Apr 16, 2010 at 12:26 PM, Richard Barnes <rbarnes@bbn.com> wrote:

> Ok, I think I get it.  Thanks for the explanation.
>
> It seems we have a collision of layers here!  When OAuth parameters are
> being passed as request parameters (GET or POST), they can collide with
> parameters being used by an application (e.g., for JSONP).  In effect,
> encoding OAuth in this way creates a set of "reserved words" that
> applications can't use.


> In the short run, it's probably an OK hack to rename parameters to
> something unlikely to collide, e.g., "oauth_*".  (Note: This applies to all
> OAuth parameters, not just "callback").
>

(this discussion is going on in a separate thread)


>
> In the long run, though, doesn't this problem kind of argue that we
> shouldn't be passed as application-layer things (request parameters), but
> rather as HTTP-layer things, e.g., in an Authorization header?
>

These all have to work as a browser GET request


>
> --Richard
>
>
>
>
> On Apr 16, 2010, at 3:05 PM, Evan Gilbert wrote:
>
>  We should use the same name in the User-Agent and Web Callback flows.
>> Also, although the authorization server won't be allowing JSONP requests,
>> "callback" has become a bit of a defacto standard for JSONP and it would be
>> nice to use a term that isn't overloaded?
>>
>> Can we make them both "redirection"? Even better, maybe "redirect_uri"?
>>
>> On Fri, Apr 16, 2010 at 9:50 AM, Luke Shepard <lshepard@facebook.com>
>> wrote:
>> Facebook API requests are protected resources. They can be called either
>> in a browser or in a server-to-server environment.
>>
>> For example, a JSONP call for my name looks like this:
>>
>>
>> https://api.facebook.com/restserver.php?api_key=361900759629&call_id=1271436355034&callback=FB.RestServer._callback&format=json&method=fql.query&query=SELECT%20name%20FROM%20user%20WHERE%20uid%3D2901279&v=1.0
>>
>> The output (you can play with it here:
>> http://fbrell.com/fb.api/everyone-data ):
>>
>>       FB.RestServer._callback([{"name":"Luke Shepard"}]);
>>
>> If we want that protected resource to take an access token as well, then
>> it would look like:
>>
>>
>> https://api.facebook.com/restserver.php?....&callback=FB.RestServer._callback&access_token=ACCESS_TOKEN
>>
>> The "callback" parameter is used pretty universally for JSONP requests.
>> For instance, see the Jquery docs: http://api.jquery.com/jQuery.getJSON/
>>
>> -----Original Message-----
>> From: Richard Barnes [mailto:rbarnes@bbn.com]
>> Sent: Friday, April 16, 2010 9:10 AM
>> To: Luke Shepard
>> Cc: Eran Hammer-Lahav; Naitik Shah; OAuth WG
>> Subject: Re: [OAUTH-WG] Rename callback => callback_uri
>>
>> Could you clarify a little more the environment in which this
>> confusion arose?  What do you mean when you say "The protected
>> resource typically accepts 'callback' as a parameter to support
>> JSONP."?  What sort of software are you including in this?
>>
>> --Richard
>>
>>
>> On Apr 15, 2010, at 5:41 PM, Luke Shepard wrote:
>>
>> > We already had one developer try it out and get confused because the
>> > server tried to treat the callback URL as a JSONP callback.
>> >
>> > The protected resource typically accepts "callback" as a parameter
>> > to support JSONP. If a developer accidentally passes in callback
>> > there (maybe they got confused) then the server can't give a normal
>> > error message - instead it needs to either detect that it looks like
>> > a URL or otherwise reject it.
>> >
>> > On a related note, I think it's more confusing calling it something
>> > different in the user-agent flow (redirector) when it's essentially
>> > doing the same thing.
>> >
>> >
>> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
>> > Behalf Of Eran Hammer-Lahav
>> > Sent: Thursday, April 15, 2010 5:37 AM
>> > To: Naitik Shah; OAuth WG
>> > Subject: Re: [OAUTH-WG] Rename callback => callback_uri
>> >
>> > I don't think it is that confusing. Its a completely different
>> > context from where JSON-P is used (note that in the User-Agent flow
>> > it is called something else).
>> >
>> > EHL
>> >
>> >
>> > On 4/10/10 12:35 PM, "Naitik Shah" <naitik@facebook.com> wrote:
>> >
>> > With the simplified params, the callback url parameter is now just
>> > "callback". Since most major API providers already use "callback" to
>> > signify JSON-P callback, can we rename this to "callback_uri"? This
>> > will help avoid collisions and confusion.
>> >
>> >
>> > -Naitik
>> > _______________________________________________
>> > 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
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>