+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" <[email protected]> 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-use > r-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: [email protected] [mailto:[email protected]] 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" <[email protected]> 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 <[email protected]> > 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: [email protected] [mailto:[email protected]] 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 <[email protected]> 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 >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/oauth >> > >> > _______________________________________________ >> > OAuth mailing list >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/oauth >> > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
