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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] 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: oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>
[mailto:oauth-boun...@ietf.org]<mailto:[mailto:oauth-boun...@ietf.org]> 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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
