While I agree it's a bit of an abusive practice, it is a pervasive one, and I'm worried about our ability to actually change the behavior of these platforms ( Mozilla is in the list as well ).
So - it's a bit of a trade off. I certainly don't want to add anything to the spec that won't get approved. On the other hand, pragmatically, I'm mostly concerned with securing these devices and how my customer's credentials are used with them. I know the pattern of usage emerged on-top of Oauth 1; I suspect it will emerge in Oauth2, so I'd be inclined to offer some guidance. I'll defer to your advise on how best to handle it within the IETF and the spec... -cmort On 4/9/10 9:45 PM, "Eran Hammer-Lahav" <e...@hueniverse.com> wrote: (+apps-discuss as this is of general interest to the area) On 4/9/10 1:26 PM, "Chuck Mortimore" <cmortim...@salesforce.com> wrote: > A number of the modern application platforms (Android, iPhone, iPad) have > support for registering custom url schemes for native applications. This > allows them to receive callbacks from web browsers, without resorting to copy > paste, or window title polling. For instance, the authorization server may > redirect the devices browser to: > > HTTP/1.1 302 Found > Location: myapp://oauth_callback?code=i1WsRn1uB1 > > This results in the application launching and the URL being passed to it's > callback handler. > > There are a few issues I see with handling these in current form: > > * The Web Callback flow is not appropriate, as the client secret cannot be > secured > * The Native Application flow best describes these types of clients, but > doesn't handle the flow > * The User Agent flow would likely work, but the description would lead > implementers away from this, and I'd be concerned that the implementations may > gravitate towards handling cross domain javascript tunneling > > I believe all of the pieces are here to support this, but I'd be interested in > seeing stronger guidance for implementers on how to handle these clients. > > - cmort The first problem with including this approach in an IETF specification is that it indirectly violates IETF standards, namely the rules governing how new URI schemes should be discussed, approved, and registered. This is also of interest to the W3C TAG. The way this should probably be done is by registering a new URN scheme like app which will look something like: app:application_name:comma_delimited_parameters With application_name either a domain-name-namespaced value (e.g. app:microsoft.com:excel:parameters) or registry based. But without such a mechanism (feel free to offer other ideas), to suggest in an IETF standard that developers should go and make up random URI schemes for their clients is both bad policy and not likely to pass Last Call. If this group has the appetite for such a feature, I would be happy to draft a very short proposal for such a new URN scheme, which we can then publish separately or include in the OAuth spec. In practice, until companies like Apple and Microsoft (the two leading OS vendors), and Google (with Android) support such a generic application URN, people will continue to do so. But if we propose a standard path, we can then mention the "abusive" practice and declare it deprecated, pointing people to the right way of doing it. That will help in getting adoption long term. Thoughts? EHL
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
