Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23

[Mike Jones <[e-mail]>]

I disagree.  The add-on is necessary exactly because several OAuth experts (Breno, Marius, Nat, John, Nov, and I) all read the new text as a breaking change that prohibited exactly what the new text explicitly allows.  Given you agree that it doesn't change the meaning, there's no harm in adding the text below, and plenty of good for the clarification it provides.

I agree with Nat.  Please add:
  Each component MAY have the same client_id, in which case the server
  judges the client type and the associated security context  based on
  the response_type parameter in the request.

Or if you dislike that, just add:
  Each component MAY have the same client_id.

                                                            Thanks,
                                                            -- Mike

From: [e-mail] [mailto:[e-mail]] On Behalf Of Eran Hammer
Sent: Thursday, March 15, 2012 7:45 AM
To: Nat Sakimura; Breno de Medeiros; OAuth WG
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23

This add-on is unnecessary. It already says the authorization server can handle it any way it wants. The fact that other registration options are possible clearly covers the client identifier reuse case. As for the response type, that's not an issue but more of an optimization for an edge case raised.

EH

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]<mailto:[mailto:[e-mail]]> On Behalf Of Nat Sakimura
Sent: Thursday, March 15, 2012 2:04 AM
To: Breno de Medeiros; OAuth WG
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23


So, Eran's first proposal:

  A client application consisting of multiple components, each with its
  own client type (e.g. a distributed client with both a confidential
  server-based component and a public browser-based component), MUST
  register each component separately as a different client to ensure
  proper handling by the authorization server, unless the authorization
  server provides other registration options to specify such complex clients.

kind of meets my concern. There seems to be another issue around the usefulness of return_type in such case raised by Breno, and if I understand it correctly, Eran's answer was that these separate components may have the same client_id so that return_type is a valid parameter to be sent at the request.

So, to clarify these, perhaps changing the above text slightly to the following solves the problem?

  A client application consisting of multiple components, each with its
  own client type (e.g. a distributed client with both a confidential
  server-based component and a public browser-based component), MUST
  register each component separately as a different client to ensure
  proper handling by the authorization server, unless the authorization
  server provides other registration options to specify such complex clients.
  Each component MAY have the same client_id, in which case the server
  judges the client type and the associated security context  based on
  the response_type parameter in the request.

Would it solve your problem, Breno?

Best,

=nat