Subject: [OAUTH-WG] Audience parameter in authorization flow

From: Sergey Beryozkin <[email-masked]>
Date: Sun, 18 Aug 2013 19:32:20 +0300

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

---

From: Justin Richer <[email-masked]>
Date: Mon, 19 Aug 2013 10:09:08 -0400

Both of those make sense to me, and it mimics what "scope" does today. 
Namely, clients can usually register for a list of scopes that they want 
access to, then at authorization time they ask for a particular set to 
be approved by the user.

  -- Justin

On 08/18/2013 12:32 PM, Sergey Beryozkin wrote:
> Hi Hannes, All,
>
> Regarding [1], where would you expect an audience parameter be 
> provided during the authorization flow ?
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Sergey Beryozkin <[email-masked]>
Date: Mon, 19 Aug 2013 21:59:15 +0300

Hi,

Thanks for the feedback,
> access to, then at authorization time they ask for a particular set to

As a side note having a dedicated audience parameter is preferred in our 
case as it lets generalize the processing of the audience parameter and 
help the actual OAuth2 data services not to worry about it; I've heard 
that a scope can be used to emulate the 'audience' but it becomes very 
application specific,

Thanks, Sergey

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 21 Aug 2013 16:30:25 +0000

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-masked] [mailto:[email-masked]] On Behalf
> Of ext Sergey Beryozkin
> Sent: Sunday, August 18, 2013 6:32 PM
> To: <[email-masked]>
> Subject: [OAUTH-WG] Audience parameter in authorization flow
> 
> Hi Hannes, All,
>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 21 Aug 2013 09:35:10 -0700

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-masked]

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 21 Aug 2013 18:40:59 +0200

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...

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 21 Aug 2013 16:45:36 +0000

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-masked] [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Wednesday, August 21, 2013 9:41 AM
To: Phil Hunt
Cc: <[email-masked]>
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.

On 08/21/2013 06:35 PM, Phil Hunt wrote:
>>> From: [email-masked] [mailto:[email-masked]] On 
>>> Behalf Of ext Sergey Beryozkin

---

From: Phil Hunt <[email-masked]>
Date: Wed, 21 Aug 2013 09:46:39 -0700

Yes.  The trade off is that each client_id becomes associated with a target.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Justin Richer <[email-masked]>
Date: Wed, 21 Aug 2013 12:49:08 -0400

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

---

From: Phil Hunt <[email-masked]>
Date: Wed, 21 Aug 2013 10:19:43 -0700

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
[email-masked]

On 2013-08-21, at 9:49 AM, Justin Richer <[email-masked]> 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
>