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
