[email protected][email protected][email protected][email protected][email protected] Sentall outlook from hotmail ovi my Nokia yahoo gmail facebook aol live msn other e-mail PhoneSoftwarOpera in likes CCLmailGoogle yahoomail
-----Original Message----- From: [email protected] Sent: 8/21/2013 4:46:56 PM To: [email protected] 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 [email protected] 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 [email protected] You can reach the person managing the list at [email protected] 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)" <[email protected]> To: ext Sergey Beryozkin <[email protected]>, "<[email protected]>" <[email protected]> Subject: Re: [OAUTH-WG] Audience parameter in authorization flow Message-ID: <[email protected]> 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: [email protected] [mailto:[email protected]] On Behalf > Of ext Sergey Beryozkin > Sent: Sunday, August 18, 2013 6:32 PM > To: <[email protected]> > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth ------------------------------ Message: 2 Date: Wed, 21 Aug 2013 16:34:44 +0000 From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email protected]> To: oauth mailing list <[email protected]> Subject: [OAUTH-WG] Dynamic Client Registration Conference Call: Thu 22 Aug, 2pm PDT: Conference Bridge Details Message-ID: <[email protected]> Content-Type: text/plain; charset="us-ascii" Here is the conference bridge and Webex information. ------------------------------ Message: 3 Message-ID: <[email protected]> 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 <[email protected]> To: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email protected]> Cc: "<[email protected]>" <[email protected]> Subject: Re: [OAUTH-WG] Audience parameter in authorization flow Message-ID: <[email protected]> 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> [email protected] On 2013-08-21, at 9:30 AM, "Tschofenig, Hannes (NSN - FI/Espoo)" <[email protected]> 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: [email protected] [mailto:[email protected]] On Behalf >> Of ext Sergey Beryozkin >> Sent: Sunday, August 18, 2013 6:32 PM >> To: <[email protected]> >> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth ------------------------------ Message: 5 Date: Wed, 21 Aug 2013 18:40:59 +0200 From: Hannes Tschofenig <[email protected]> To: Phil Hunt <[email protected]> Cc: "<[email protected]>" <[email protected]> Subject: Re: [OAUTH-WG] Audience parameter in authorization flow Message-ID: <[email protected]> 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> > [email protected] > > > > > > > > On 2013-08-21, at 9:30 AM, "Tschofenig, Hannes (NSN - FI/Espoo)" > <[email protected]> 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: [email protected] [mailto:[email protected]] On Behalf >>> Of ext Sergey Beryozkin >>> Sent: Sunday, August 18, 2013 6:32 PM >>> To: <[email protected]> >>> 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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > ------------------------------ Message: 6 Date: Wed, 21 Aug 2013 16:45:36 +0000 From: Anthony Nadalin <[email protected]> To: Hannes Tschofenig <[email protected]>, Phil Hunt <[email protected]> Cc: "<[email protected]>" <[email protected]> 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: [email protected] [mailto:[email protected]] On Behalf Of Hannes Tschofenig Sent: Wednesday, August 21, 2013 9:41 AM To: Phil Hunt Cc: <[email protected]> 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> > [email protected] > > > > > > > > On 2013-08-21, at 9:30 AM, "Tschofenig, Hannes (NSN - FI/Espoo)" > <[email protected]> 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: [email protected] [mailto:[email protected]] On >>> Behalf Of ext Sergey Beryozkin >>> Sent: Sunday, August 18, 2013 6:32 PM >>> To: <[email protected]> >>> 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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth ------------------------------ Message: 7 Date: Wed, 21 Aug 2013 09:46:39 -0700 From: Phil Hunt <[email protected]> To: Anthony Nadalin <[email protected]> Cc: "<[email protected]>" <[email protected]> Subject: Re: [OAUTH-WG] Audience parameter in authorization flow Message-ID: <[email protected]> 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> [email protected] On 2013-08-21, at 9:45 AM, Anthony Nadalin <[email protected]> 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: [email protected] [mailto:[email protected]] On Behalf Of > Hannes Tschofenig > Sent: Wednesday, August 21, 2013 9:41 AM > To: Phil Hunt > Cc: <[email protected]> > 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> >> [email protected] >> >> >> >> >> >> >> >> On 2013-08-21, at 9:30 AM, "Tschofenig, Hannes (NSN - FI/Espoo)" >> <[email protected]> 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: [email protected] [mailto:[email protected]] On >>>> Behalf Of ext Sergey Beryozkin >>>> Sent: Sunday, August 18, 2013 6:32 PM >>>> To: <[email protected]> >>>> 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 >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/oauth >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth ------------------------------ _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth End of OAuth Digest, Vol 58, Issue 72 *************************************
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
