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
