Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt

[Eran Hammer-Lahav <[e-mail]>]

Thanks Marius.

> -----Original Message-----
> From: Marius Scurtescu [mailto:[e-mail]]
> Sent: Tuesday, January 25, 2011 5:02 PM
> To: Eran Hammer-Lahav
> Cc: [e-mail]
> 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-mail]> 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?
 
> 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.

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.

EHL