+1 - we'll end up requiring some parameter, as agent sniffing can't handle all our needs.
- cmort On 4/10/10 12:08 AM, "Torsten Lodderstedt" <tors...@lodderstedt.net> wrote: +1 Am 10.04.2010 02:20, schrieb Allen Tom: Re: [OAUTH-WG] A display parameter for user authorization requests +1 Not sure If it's possible for different SPs to agree on the specs for each mode, but as we learned from implementing OpenID, it's very useful for the client to have an interface to indicate to the AS how the UI should be rendered. At least in Yahoo's case, we'd like to see all the display modes you listed, although I'm unclear what "none" is. Allen On 4/9/10 3:24 AM, "Luke Shepard" <lshep...@facebook.com> wrote: I am still not sure why we *need* discovery in order to just add a "display" parameter to the spec. I would like to see a set like the following supported: - popup - fullpage - touch (for smart phones (like iPhone)-like phones) - mobile (for older-mobile phones) - none As Allen mentioned, the "popup" mode was already defined with some success in OpenID UX: http://svn.openid.net/repos/specifications/user_interface/1.0/trunk/openid-user-interface-extension-1_0.html#anchor4 I agree that it can be difficult to standardize all of these right now - I think the best is to see what's being used in production now by different players and see if we can get agreement on that. At least some broad categories could be established now to aid interop. From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Tuesday, March 30, 2010 6:34 PM To: Marius Scurtescu; Anthony Nadalin Cc: OAuth WG Subject: Re: [OAUTH-WG] A display parameter for user authorization requests They are, but thinking about interop for both parts is the same work. Once you figure out what the client might need, you figure out what the server may support. At that point discovery is as simple as giving these different options names and putting this information somewhere. I am not saying a spec must cover both, but it is worth thinking about it at the same time. For example, a decision about allowing requesting custom size popup vs. fixed popup options vs. pre-defined categories, all require different discovery needs. If the feature allows the client to say "I want a 400x500 popup", you just need to say "popups are supported". But if you want just allow full browser or popup (of fixed sizes), and do not require a server to support all of them, you need to express what is supported. Given the wide range of UI options, without either mandating everything or discovery, this feature offers little interop value (which means little reason to write as a standard). EHL On 3/30/10 5:58 PM, "Marius Scurtescu" <mscurte...@google.com> wrote: Aren't these independent issues? Regardless how the client figures what the server supports (discovery or hard code configuration) it must have a way to tell the Authorization Server its preferences when it sends the user over. Marius On Tue, Mar 30, 2010 at 8:50 PM, Anthony Nadalin <tony...@microsoft.com> wrote: > So I doubt that the client always knows what the server supports, the server > should be open in allowing all parties to find out what is supported > > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of > Brian Eaton > Sent: Tuesday, March 30, 2010 5:44 PM > To: Raffi Krikorian > Cc: OAuth WG > Subject: Re: [OAUTH-WG] A display parameter for user authorization requests > > On Tue, Mar 30, 2010 at 5:25 PM, Raffi Krikorian <ra...@twitter.com> wrote: >> why does a client need to discover what the server supports? >> presumably the client would already know given that they are integrating >> with it? > > +1. > _______________________________________________ > 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 ________________________________ _______________________________________________ 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
