Yes. The trade off is that each client_id becomes associated with a target.
Phil @independentid www.independentid.com [email protected] On 2013-08-21, at 9:45 AM, Anthony Nadalin <[email protected]> wrote: > I think binding audience at registration time is to limiting as we see > audience being on a per token request level and also see the audience being > part of the restrictions for "act as" or "on behalf of" support > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Hannes Tschofenig > Sent: Wednesday, August 21, 2013 9:41 AM > To: Phil Hunt > Cc: <[email protected]> > Subject: Re: [OAUTH-WG] Audience parameter in authorization flow > > That's certainly true although the referenced document did not talk about the > registration phase but rather about the time when the client talks to the > authorization server to obtain an access token. > > Maybe UMA has provided a story for this already... > > On 08/21/2013 06:35 PM, Phil Hunt wrote: >> This could be bound up in the client registration process since oauth >> clients don't authorize for random "targets". >> >> Phil >> >> @independentid >> www.independentid.com >> [email protected] >> >> >> >> >> >> >> >> On 2013-08-21, at 9:30 AM, "Tschofenig, Hannes (NSN - FI/Espoo)" >> <[email protected]> wrote: >> >>> Hi Sergey, >>> >>> The idea of the audience was to provide a way for the client to indicate >>> the resource server it wants to talk to explicitly rather than overloading >>> the scope field. We certainly need that capability for the MAC token work. >>> >>> The audience information is provided when the client interacts with the AS. >>> >>> Ciao >>> Hannes >>> >>> >>>> -----Original Message----- >>>> From: [email protected] [mailto:[email protected]] On >>>> Behalf Of ext Sergey Beryozkin >>>> Sent: Sunday, August 18, 2013 6:32 PM >>>> To: <[email protected]> >>>> Subject: [OAUTH-WG] Audience parameter in authorization flow >>>> >>>> Hi Hannes, All, >>>> >>>> Regarding [1], where would you expect an audience parameter be >>>> provided during the authorization flow ? >>>> >>>> It appears to me it should be provided during the initial redirect >>>> (similarly to a parameter like redirect_uri). >>>> >>>> Also, would it make sense to support pre-registered audience values, >>>> example, a client registers and specifies an audience during the >>>> registration ? >>>> >>>> Thanks, Sergey >>>> >>>> [1] http://tools.ietf.org/html/draft-tschofenig-oauth-audience-00 >>>> _______________________________________________ >>>> 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 _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
