As mentioned in Prague, Azure Active Directory uses a “resource” request 
parameter to supply the URL of the resource server that the access token is 
intended for.  However, I believe that Google uses scope values for this and 
some Microsoft services are moving towards using scope values as well.  Sorting 
this out soon would be good.

                                                                -- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Brian Campbell
Sent: Wednesday, January 20, 2016 2:18 PM
To: Hannes Tschofenig
Cc: oauth
Subject: Re: [OAUTH-WG] Status of draft-tschofenig-oauth-audience

There does seem to be a need to provide the client a means of telling the AS 
the place(s) and/or entity(s) where it intends to use the token it's asking 
for. And that it's common enough to warrant it's own small spec. This has come 
up several times before and I think has some consensus behind doing it. What 
needs to happen to move forward?
The concept shows up in these three different drafts (that I know of anyway):

https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00#section-3 has an 
audience parameter
https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-02#section-3 
has an aud parameter
http://tools.ietf.org/html/draft-ietf-oauth-token-exchange-03#section-2.1 has 
both an audience and a resource resource

All the above apply only to the token request. However, there are ways of 
requesting/obtaining access tokens that don't involve the token 
endpoint<https://tools.ietf.org/html/rfc6749#section-4.2> so I think it follows 
that  the same facility should be available for the authorization request too.



On Wed, Jan 20, 2016 at 7:27 AM, Hannes Tschofenig 
<hannes.tschofe...@gmx.net<mailto:hannes.tschofe...@gmx.net>> wrote:
Hi Sergey,

that's a good question. After this document was published the
functionality had been integrated into the PoP solution document.
Recently, I got feedback that the functionality should be more generic
and it is independent of the PoP work.

So, I guess it is a good time to discuss the needed functionality and
where it should be included.

Ciao
Hannes


On 01/20/2016 11:25 AM, Sergey Beryozkin wrote:
> Hi
>
> Given that the draft-tschofenig-oauth-audience [1] has expired, I'm
> wondering if it is still relevant.
>
> I know the token introspection response can provide the audience
> value(s), but the question is really how a client is associated with a a
> given audience in the first place. As such [1] may still make sense, for
> example, I can think of two options:
> 1. the client audiences are set out of band during the client
> registration time and all the tokens issued to that client will be
> restricted accordingly
> 2. the client is requesting a specific audience during the grant to
> token exchange as per [1]
>
> I guess 1. is how it is done in practice or is 2. is also a valid option ?
>
>
> Thanks, Sergey
>
>
> [1] https://tools.ietf.org/html/draft-tschofenig-oauth-audience-00
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org<mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to