One more question - is the <title> technique used in production? I think you'd mentioned that it was ... if so, can you point me to the docs where it's currently used?
On Jun 22, 2010, at 11:00 PM, Luke Shepard wrote: > Two points: > > 1/ I agree that it can be onerous for clients to host web pages. It's not a > matter of expense but of complexity. > > BUT > > 2/ As we discussed previously in our in-person meeting, this should be > handled by a different endpoint, and not be the responsibility for the > provider. If Google wishes to support this for their desktop apps, then it > should provide an endpoint that handles the OAuth response and puts it in the > <title>. I can say that Facebook has no interest in supporting this hack on > the server side, but clients that want it can use their own html file that > does it for them. > > For example, for Javascript web apps it is a pain to host a cross-domain > receiver file. So we host one on behalf of developers (called xd_proxy.php). > But it is not part of our server-side logic. > > If you want to write a spec for that, then great, but the <title> hack does > not belong in the main spec. > > On Jun 22, 2010, at 4:30 PM, Marius Scurtescu wrote: > >> On Tue, Jun 22, 2010 at 4:26 PM, Eran Hammer-Lahav <e...@hueniverse.com> >> wrote: >>> In that case, I suggest an extension. But I just don't think this needs it. >>> Why involve the server at all in this? The client should just host a web >>> page somewhere with the format it wants or the language for the user. >>> >>> With $10 hosting, every client can host a web page somewhere. >> >> Hard to tell, you could be right. Keep in mind that this page has to >> be reliable and secure, $10 will probably not give you that. An authz >> server can easily provide all this at almost no cost. >> >> Marius >> >>> >>> EHL >>> >>>> -----Original Message----- >>>> From: Marius Scurtescu [mailto:mscurte...@google.com] >>>> Sent: Tuesday, June 22, 2010 4:17 PM >>>> To: Eran Hammer-Lahav >>>> Cc: OAuth WG (oauth@ietf.org) >>>> Subject: Re: native app support (was: Next draft) >>>> >>>> On Tue, Jun 22, 2010 at 4:07 PM, Eran Hammer-Lahav >>>> <e...@hueniverse.com> wrote: >>>>> >>>>>> -----Original Message----- >>>>>> From: Marius Scurtescu [mailto:mscurte...@google.com] >>>>>> Sent: Tuesday, June 22, 2010 3:35 PM >>>>>> To: Eran Hammer-Lahav >>>>>> Cc: OAuth WG (oauth@ietf.org) >>>>>> Subject: Re: native app support (was: Next draft) >>>>>> >>>>>> On Tue, Jun 22, 2010 at 3:14 PM, Eran Hammer-Lahav >>>>>> <e...@hueniverse.com> wrote: >>>>>>> In OAuth 1.0a, we needed it for the patch. I don't think this needs >>>>>>> to be in >>>>>> the spec because it doesn't help interop. If the server supports such >>>>>> a scheme, it should document it. It also falls under "previously >>>>>> established redirection URI" which happens to point at the server. >>>>>> >>>>>> OK, that makes sense. >>>>>> >>>>>> What about: >>>>>>> Also, this page should put the verification code and the client >>>>>>> state (code and state) in the page title in a standard way such >>>>>>> that the native app can extract them from the window title. WRAP >>>>>>> defined how the title should be formed. >>>>>> >>>>>> Extension? >>>>> >>>>> I don't think this needs a spec. Just something provided by the server. >>>>> Does >>>> the client need any special handling? It can always just use a static web >>>> page >>>> to do this, no? >>>> >>>> A spec would help so all servers provide code and state in a consistent >>>> format. Client libraries can then provide methods to parse this. Also, >>>> client >>>> apps connecting to multiple servers can expect some consistency. >>>> >>>> Marius >>>> >>>>> >>>>> EHL >>>>> >>>>>> >>>>>> Marius >>>>>> >>>>>>> >>>>>>> EHL >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Marius Scurtescu [mailto:mscurte...@google.com] >>>>>>>> Sent: Tuesday, June 22, 2010 1:02 PM >>>>>>>> To: Eran Hammer-Lahav >>>>>>>> Cc: OAuth WG (oauth@ietf.org) >>>>>>>> Subject: Re: native app support (was: Next draft) >>>>>>>> >>>>>>>> On Tue, Jun 8, 2010 at 10:46 AM, Marius Scurtescu >>>>>>>> <mscurte...@google.com> wrote: >>>>>>>>> In order to properly support native applications I suggest the >>>>>>>>> following changes: >>>>>>>>> [...] >>>>>>>>> 2. optional redirect_uri (default result page) >>>>>>>>> >>>>>>>>> Some native apps do not have a redirect_uri, as a result two >>>>>>>>> things are >>>>>>>> needed: >>>>>>>>> >>>>>>>>> 2.1 Either make redirect_uri optional or define a standard value >>>>>>>>> that signals that the client does not have such a page. >>>>>>>>> >>>>>>>>> 2.2 The authz server must supply a default result page, if there >>>>>>>>> is no redirect_uri. Also, this page should put the verification >>>>>>>>> code and the client state (code and state) in the page title in >>>>>>>>> a standard way such that the native app can extract them from >>>>>>>>> the window title. WRAP defined how the title should be formed. >>>>>>>> >>>>>>>> Should this also go to an extension? It is not introducing any new >>>>>>>> parameters, not sure if it belongs there. OAuth 1 at least defined >>>>>>>> the >>>>>> "oob" special value. >>>>>>>> >>>>>>>> Marius >>>>>>> >>>>> >>> >> _______________________________________________ >> 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
