We have been talking about providing the resource or audience as the input.
The resource type would be more abstract than audience. That is something we would need to discuss in a spec. The problem foe POP is that the same scope may cover multiple resource endpoints. Especially when using a symmetric key you need to specify what Resource server you are sending the token to so that it can be encrypted with the correct key. John B. > On Jan 20, 2016, at 7:47 PM, Nat Sakimura <sakim...@gmail.com> wrote: > > +1 > > Also, I have always thought that it would be good if one could ask for a > particular resource type, and the server could respond with the actual > location of it with the associated access token. This is because it is often > undesirable to tell the client the location of the resource before the > authorization from the privacy point of view. > > So, the processing flow in this case will be: > > The client request an access to the resource type in the scope of the > authorization request. > The client request an access token to the resource type to the token endpoint > with audience/resource/scope parameter. > The token endpoint responds with token response with oauth-meta header > indicating the URL of the resource as in draft-sakimura-oauth-meta. > Best, > > Nat > > > 2016年1月21日(木) 7:27 John Bradley <ve7...@ve7jtb.com > <mailto:ve7...@ve7jtb.com>>: > +1 > >> On Jan 20, 2016, at 7:25 PM, Mike Jones <michael.jo...@microsoft.com >> <mailto:michael.jo...@microsoft.com>> wrote: >> >> 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 <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 >> <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 >> >> <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 >> <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 >> > <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 >> > <https://www.ietf.org/mailman/listinfo/oauth> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
