"none" is similar to check immediate in open id. On Fri, Apr 9, 2010 at 5:20 PM, Allen Tom <a...@yahoo-inc.com> wrote:
> +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<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<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
