+1
Am 10.04.2010 02:20, schrieb Allen Tom:
+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-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:* [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
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
