Between language preferences, display configuration, and immediate check, I think it might be worth to move that work to another draft. Timeline-wise, this has the potential of slowing us down. I also fear getting what is now a pretty simple spec much more complicated.
Anyone cares to try a first draft or outline? I can do the editorial work if needed, but someone needs to write something first. EHL On 4/12/10 11:04 AM, "Luke Shepard" <lshep...@facebook.com> wrote: Yes- I threw that in there as one way of handling an immediate response. We will need the ability to do a background ping in an iframe, similar to checkid_immediate in OpenID. I agree that the parameters are functionally different ... on the other hand, they are mutually exclusive (you won't ever have a display and an immediate parameter set to the same) so by making it one parameter, you avoid certain error cases (i.e., what does a server do with "display=page&immediate=true") From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Evan Gilbert Sent: Monday, April 12, 2010 9:51 AM To: Chuck Mortimore Cc: OAuth WG Subject: Re: [OAUTH-WG] A display parameter for user authorization requests +1 in general Question about display=none - I missed this part before, and proposed a different parameter (immediate=true) for the same purpose - http://www.ietf.org/mail-archive/web/oauth/current/msg01694.html. Anyone have thoughts on whether we should have a separate parameter for immediate mode? I could go either way, but have a slight preference for two parameters. "immediate" feels like a significant functional difference while the display variations are more of a UI hint. Evan On Sat, Apr 10, 2010 at 1:07 PM, Chuck Mortimore <cmortim...@salesforce.com> wrote: +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 <http://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 <http://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 <http://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 <http://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 <http://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 <http://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 > <http://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 <http://OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <http://OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org <http://OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth ________________________________ _______________________________________________ OAuth mailing list OAuth@ietf.org <http://OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org <http://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
