On Tue, Jan 25, 2011 at 11:08 PM, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > Thanks Marius. > >> -----Original Message----- >> From: Marius Scurtescu [mailto:mscurte...@google.com] >> Sent: Tuesday, January 25, 2011 5:02 PM >> To: Eran Hammer-Lahav >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt >> >> On Thu, Jan 20, 2011 at 9:41 PM, Eran Hammer-Lahav >> <e...@hueniverse.com> wrote: >> > Forgot to mention that I don't have any outstanding comments in my >> queue so if your feedback was not incorporated into -12, and you feel >> strongly about it, bring it up again. >> >> From an older email, adapted to v12: >> >> >> 1. The token_type parameter is required in responses from the server. >> If the server supports multiple formats, which one will be used? In this >> case, >> would it make sense to allow the client to request a specific format? >> >> For example, if the authorization server supports both MAC and BEARER, >> which one will the server issue? > > It might in some cases, but I suspect most providers are going to decide > which scheme provides the right level of security for them and just use that. > If you are going to allow both MAC and BEARER, you are basically letting > clients decide which level to operate at. Do you have a need or plan to > support multiple token types?
For now we are planning to support only bearer, but I am sure some form of signed tokens will follow sooner than later. At which point we would have to support both. In most cases I think it is up to the client to decide. >> 2. Section 8.2. What about applications using legacy parameters? Does not >> make much sense to register them, and they cannot be changed to x_. >> Broken record: using a prefix for all registered parameters is much cleaner >> (as >> opposed to requiring that all no-registered parameters use a prefix). >> >> For Google it is impossible to comply with this requirement. > > What legacy parameters do you have? Since OAuth 2.0 endpoints are brand new, > this is probably about extension parameters in the authorization endpoint > from OAuth 1.0 or AuthSub? I think the legacy parameters problem is pretty > small, given the number of existing *token* and *authorization* endpoints > with custom parameters (that were not pulled into the specification such as > scope), but it would be good to know what we are dealing with. It is about parameters used by the authentication endpoints (aka login page). The new OAuth 2 endpoints have no control over that. > Overall, this is a pretty minor issue. I assume you don't have any conflicts > today with the v2 specification. Any conflicts you might have in the future > (for which this x_ prefix is meant for) with new extensions is probably going > to be minor. And Google can always join the work to make sure they pick a > less conflicting name... this is where the registration process really helps > to avoid clashes. I don't think it makes much sense to register these existing parameters, and they cannot be changed either. I guess that other authorization servers will have similar issues. Here are some examples from the top of my head: - hd - domain hint, for hosted domain - hl - language selecter - authuser - multiple session user selector Marius _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
