On 3/30/10 4:16 PM, David Recordon wrote: > On Tue, Mar 30, 2010 at 3:07 PM, Richard Barnes <rbar...@bbn.com> wrote: >> This seems rather application-specific. What semantics do these things take >> on when HTTP is just being used as a transport, e.g., for a virtual world >> system (see VWRAP)? >> >> Also, maybe I'm misunderstanding things here, but since it's the Client that >> send the browser to the authorization page, doesn't the Client control how >> the authorization page is displayed? In an iframe, popup, etc... > > Yes, but the Client needs to make sure that the authorization page > will fit in whatever constraints they're choosing. This might be a > popup window but could also be a full page redirect. There's also the > case in the Web Client flow where the Client just wants an immediate > response of yes/no (ala OpenID's checkid_immediate mode) versus > presenting any UI in the first request. > > >> Perhaps what you want here is a set of different authorization URIs that >> result in different appearances (e.g., desktop vs. mobile)? You're already >> assuming that the application developer knows which of these options he >> wants. > > There are a few ways to go about it: > 1) different mainly duplicative versions of the Web Client and Web Server > flows > 2) multiple modes within the existing Web Client and Web Server flows > 3) different user authorization endpoints which can be used with > either the Web Client or Web Server flow > 4) an optional parameter like in this proposal > > I'd rather have this be something more dynamic than multiple hard > coded user authorization URLs and duplicating flows seems more > confusing to developers.
I agree that defining multiple but essentially similar flows is a bad idea. This seems like a good opportunity for defining an extension, mostly because many IETF folks would probably prefer a separation between meaning and presentation. But personally I'm willing to be convinced otherwise. :) Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
