That seems to cover it. My problem is that client registration has been treated largely as being out of scope other than some general principals. We are now adding normative text, but still not specifying mechanisms.
Nat's text allows existing practice with complex clients like Facebook with 'token signed_request' response_type. What exact mechanism one uses to register a confidential vs complex client is still out of scope and a bit of handwaving with a MUST. John B. On 2012-03-15, at 5:03 AM, Nat Sakimura wrote: > > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
