Looking at the spec, the problem is you can still only authorize one api at a time. You couldn't specify multiple audience apis and match them up with scopes.
A while ago I did start to write some stuff up about a structured scope specification where scope becomes a JSON multi-value structure so that multiple scopes and end-points could be defined. I abandoned it after seeing that the same thing could be accomplished (as Google did) by defining the relationship during registration. I agree, it precludes being able to change on the fly, but came to the conclusion that is pretty rare (we're not talking about browsers for the most part). Aside…this is why I include "target" in the SCIM Registration draft. Phil @independentid www.independentid.com phil.h...@oracle.com On 2013-08-21, at 9:49 AM, Justin Richer <jric...@mitre.org> wrote: > I think it makes sense to have both, and this would parallel what we've got > with the "scope" parameter today. At registration, the client is saying "this > is what I want to be able to use" and the server is saying "this is what > you're allowed to use". At auth time, the client is saying "this is what I'm > using now" and the user is saying "this is what you're authorized to use now". > > If there were a standardized "audience" parameter at the auth endpoint, it > could easily be added to the registration's client model in parallel. > > -- Justin > > On 08/21/2013 12:46 PM, Phil Hunt wrote: >> Yes. The trade off is that each client_id becomes associated with a target. >> >> Phil >> >> @independentid >> www.independentid.com >> phil.h...@oracle.com >> >> >> >> >> >> >> >> On 2013-08-21, at 9:45 AM, Anthony Nadalin <tony...@microsoft.com> 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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of >>> Hannes Tschofenig >>> Sent: Wednesday, August 21, 2013 9:41 AM >>> To: Phil Hunt >>> Cc: <oauth@ietf.org> >>> 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 >>>> phil.h...@oracle.com >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 2013-08-21, at 9:30 AM, "Tschofenig, Hannes (NSN - FI/Espoo)" >>>> <hannes.tschofe...@nsn.com> 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: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On >>>>>> Behalf Of ext Sergey Beryozkin >>>>>> Sent: Sunday, August 18, 2013 6:32 PM >>>>>> To: <oauth@ietf.org> >>>>>> 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 >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
