amirabdul...@hotmail.com....@nokia.com....@ovi.com....@yahoomail.com....@gmail.com Sentall outlook from hotmail ovi my Nokia yahoo gmail facebook aol live msn other e-mail PhoneSoftwarOpera in likes CCLmailGoogle yahoomail
-----Original Message----- From: oauth-requ...@ietf.org Sent: 8/21/2013 4:46:56 PM To: oauth@ietf.org Subject: OAuth Digest, Vol 58, Issue 72 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to https://www.ietf.org/mailman/listinfo/oauth Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send OAuth mailing list submissions to oauth@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/oauth or, via email, send a message with subject or body 'help' to oauth-requ...@ietf.org You can reach the person managing the list at oauth-ow...@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of OAuth digest..." Today's Topics: 1. Re: Audience parameter in authorization flow (Tschofenig, Hannes (NSN - FI/Espoo)) 2. Dynamic Client Registration Conference Call: Thu 22 Aug, 2pm PDT: Conference Bridge Details (Tschofenig, Hannes (NSN - FI/Espoo)) 3. (no subject) 4. Re: Audience parameter in authorization flow (Phil Hunt) 5. Re: Audience parameter in authorization flow (Hannes Tschofenig) 6. Re: Audience parameter in authorization flow (Anthony Nadalin) 7. Re: Audience parameter in authorization flow (Phil Hunt) ---------------------------------------------------------------------- Message: 1 Date: Wed, 21 Aug 2013 16:30:25 +0000 From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofe...@nsn.com> To: ext Sergey Beryozkin <sberyoz...@gmail.com>, "<oauth@ietf.org>" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Audience parameter in authorization flow Message-ID: <1373e8ce237fcc43bca36c6558612d2aa27...@uschmbx001.nsn-intra.net> Content-Type: text/plain; charset="us-ascii" 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 ------------------------------ Message: 2 Date: Wed, 21 Aug 2013 16:34:44 +0000 From: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofe...@nsn.com> To: oauth mailing list <oauth@ietf.org> Subject: [OAUTH-WG] Dynamic Client Registration Conference Call: Thu 22 Aug, 2pm PDT: Conference Bridge Details Message-ID: <1373e8ce237fcc43bca36c6558612d2aa27...@uschmbx001.nsn-intra.net> Content-Type: text/plain; charset="us-ascii" Here is the conference bridge and Webex information. ------------------------------ Message: 3 Message-ID: <mailman.2439.1377103616.3815.oa...@ietf.org> ly with what we have already in the dynamic client registration document (a= nd folks may have actually missed it). There are two use cases described in= the WG document, namely=20 - Use Case #1: Open Registration (Appendix B.1) - Use Case #2: Protected Registration (Appendix B.2) Then, we could talk about some more sophisticated use cases where informati= on for protected registration is provided by a third party.=20 -------------------- Meeting Number: 702 442 101=20 Meeting Password: oauth=20 -------------------------------------------------------=20 To join the online meeting=20 -------------------------------------------------------=20 1. Go to https://nsn.webex.com/nsn/j.php?ED=3D268691357&UID=3D0&PW=3DNOTlkZ= jIwNTEy&RT=3DMiMzMA%3D%3D=20 2. Enter your name and email address.=20 3. Enter the meeting password: oauth=20 4. Click "Join Now".=20 To view in other time zones or languages, please click the link:=20 https://nsn.webex.com/nsn/j.php?ED=3D268691357&UID=3D0&PW=3DNOTlkZjIwNTEy&O= RT=3DMiMzMA%3D%3D=20 -------------------------------------------------------=20 To join the teleconference only=20 -------------------------------------------------------=20 Global Dial-In Numbers: http://www.nokiasiemensnetworks.com/nvc=20 Conference Code: 944 910 5485 ------------------------------ Message: 4 Date: Wed, 21 Aug 2013 09:35:10 -0700 From: Phil Hunt <phil.h...@oracle.com> To: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofe...@nsn.com> Cc: "<oauth@ietf.org>" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Audience parameter in authorization flow Message-ID: <cf5728a9-5271-4b57-a2b3-40a9fc1bc...@oracle.com> Content-Type: text/plain; charset=us-ascii This could be bound up in the client registration process since oauth clients don't authorize for random "targets". Phil @independentid www.independentid.com<http://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 ------------------------------ Message: 5 Date: Wed, 21 Aug 2013 18:40:59 +0200 From: Hannes Tschofenig <hannes.tschofe...@gmx.net> To: Phil Hunt <phil.h...@oracle.com> Cc: "<oauth@ietf.org>" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Audience parameter in authorization flow Message-ID: <5214ed9b.3070...@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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<http://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 > ------------------------------ Message: 6 Date: Wed, 21 Aug 2013 16:45:36 +0000 From: Anthony Nadalin <tony...@microsoft.com> To: Hannes Tschofenig <hannes.tschofe...@gmx.net>, Phil Hunt <phil.h...@oracle.com> Cc: "<oauth@ietf.org>" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Audience parameter in authorization flow Message-ID: <1d4b764800be4cff991f02a91948d...@by2pr03mb189.namprd03.prod.outlook.com> Content-Type: text/plain; charset="us-ascii" 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<http://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 ------------------------------ Message: 7 Date: Wed, 21 Aug 2013 09:46:39 -0700 From: Phil Hunt <phil.h...@oracle.com> To: Anthony Nadalin <tony...@microsoft.com> Cc: "<oauth@ietf.org>" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Audience parameter in authorization flow Message-ID: <5aa05ffa-99ab-4702-bc20-c209ff264...@oracle.com> Content-Type: text/plain; charset=us-ascii Yes. The trade off is that each client_id becomes associated with a target. Phil @independentid www.independentid.com<http://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<http://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 End of OAuth Digest, Vol 58, Issue 72 *************************************
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
