I understood. Thanks. -- nov
On Mar 12, 2012, at 2:30 AM, Eran Hammer <[email protected]> wrote: > That use case was removed from the specification. Either way, it is up to the > authorization server to decide which registration options to offer the client > if they make such a grant type available in the future, and how it will apply > the security policies. IOW, those proposing such an extension in the future > will have to figure out how this should be handled. > > EH > >> -----Original Message----- >> From: nov matake [mailto:[email protected]] >> Sent: Sunday, March 11, 2012 10:21 AM >> To: Eran Hammer >> Cc: nov matake; [email protected] WG >> Subject: Re: [OAUTH-WG] Clarification of "client application consisting of >> multiple components" >> >> So what is the usecase of response_type=token%20code ? >> I thought, in that usecase, token was for the client's client-side component, >> code was for the client's server-side component, and both of them have the >> same client_id. >> >> -- >> nov >> >> On Mar 12, 2012, at 12:57 AM, Eran Hammer <[email protected]> wrote: >> >>> If you have two components each with different security profile, you must >> assign each a different client_id. Otherwise, there is no way to enforce the >> rest of the spec's security requirements. >>> >>> EH >>> >>>> -----Original Message----- >>>> From: [email protected] [mailto:[email protected]] On >>>> Behalf Of nov matake >>>> Sent: Sunday, March 11, 2012 8:25 AM >>>> To: [email protected] WG >>>> Subject: [OAUTH-WG] Clarification of "client application consisting >>>> of multiple components" >>>> >>>> Hi, >>>> >>>> I just found this sentence in the latest draft. >>>> >>>> Does it mean "an application consisting of server-side and >>>> client-side component (eg. foursquare iPhone app) MUST have separate >>>> client_id for each component" ? >>>> Or can I image something like Facebook is doing right now? (register >>>> each component for a single client_id separately) >>>> >>>> == >>>> 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. The authorization >>>> server MAY provider tools to manage such complex clients through a >> single administration interface. >>>> == >>>> >>>> -- >>>> nov <[email protected]> >>>> _______________________________________________ >>>> OAuth mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/oauth >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
