Hi,
Thanks for the feedback,
On 19/08/13 17:09, Justin Richer wrote:
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.
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
-- 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 ?
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
