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
