Re: [OAUTH-WG] OAuth Digest, Vol 58, Issue 72

["amir abdulahi " <[e-mail]>]

[e-mail][e-mail][e-mail][e-mail][e-mail]
Sentall outlook from hotmail ovi my Nokia yahoo gmail facebook aol live msn other e-mail PhoneSoftwarOpera in likes CCLmailGoogle yahoomail


-----Original Message-----
From: [e-mail]
Sent: 8/21/2013 4:46:56 PM
To: [e-mail]
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
        [e-mail]

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
        [e-mail]

You can reach the person managing the list at
        [e-mail]

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)"
        <[e-mail]>
To: ext Sergey Beryozkin <[e-mail]>, "<[e-mail]>"
        <[e-mail]>
Subject: Re: [OAUTH-WG] Audience parameter in authorization flow
Message-ID:
        <[e-mail]>
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: [e-mail] [mailto:[e-mail]] On Behalf
> Of ext Sergey Beryozkin
> Sent: Sunday, August 18, 2013 6:32 PM
> To: <[e-mail]>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth


------------------------------

Message: 2
Date: Wed, 21 Aug 2013 16:34:44 +0000
From: "Tschofenig, Hannes (NSN - FI/Espoo)"
        <[e-mail]>
To: oauth mailing list <[e-mail]>
Subject: [OAUTH-WG] Dynamic Client Registration Conference Call: Thu
        22 Aug, 2pm PDT: Conference Bridge Details
Message-ID:
        <[e-mail]>
Content-Type: text/plain; charset="us-ascii"

Here is the conference bridge and Webex information.


------------------------------

Message: 3
Message-ID: <[e-mail]>

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 <[e-mail]>
To: "Tschofenig, Hannes (NSN - FI/Espoo)" <[e-mail]>
Cc: "<[e-mail]>" <[e-mail]>
Subject: Re: [OAUTH-WG] Audience parameter in authorization flow
Message-ID: <[e-mail]>
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>
[e-mail]







On 2013-08-21, at 9:30 AM, "Tschofenig, Hannes (NSN - FI/Espoo)" <[e-mail]> 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: [e-mail] [mailto:[e-mail]] On Behalf
>> Of ext Sergey Beryozkin
>> Sent: Sunday, August 18, 2013 6:32 PM
>> To: <[e-mail]>
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth



------------------------------

Message: 5
Date: Wed, 21 Aug 2013 18:40:59 +0200
From: Hannes Tschofenig <[e-mail]>
To: Phil Hunt <[e-mail]>
Cc: "<[e-mail]>" <[e-mail]>
Subject: Re: [OAUTH-WG] Audience parameter in authorization flow
Message-ID: <[e-mail]>
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>
> [e-mail]
>
>
>
>
>
>
>
> On 2013-08-21, at 9:30 AM, "Tschofenig, Hannes (NSN - FI/Espoo)" <[e-mail]> 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: [e-mail] [mailto:[e-mail]] On Behalf
>>> Of ext Sergey Beryozkin
>>> Sent: Sunday, August 18, 2013 6:32 PM
>>> To: <[e-mail]>
>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>



------------------------------

Message: 6
Date: Wed, 21 Aug 2013 16:45:36 +0000
From: Anthony Nadalin <[e-mail]>
To: Hannes Tschofenig <[e-mail]>, Phil Hunt
        <[e-mail]>
Cc: "<[e-mail]>" <[e-mail]>
Subject: Re: [OAUTH-WG] Audience parameter in authorization flow
Message-ID:
        <[e-mail]>

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: [e-mail] [mailto:[e-mail]] On Behalf Of Hannes Tschofenig
Sent: Wednesday, August 21, 2013 9:41 AM
To: Phil Hunt
Cc: <[e-mail]>
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>
> [e-mail]
>
>
>
>
>
>
>
> On 2013-08-21, at 9:30 AM, "Tschofenig, Hannes (NSN - FI/Espoo)" <[e-mail]> 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: [e-mail] [mailto:[e-mail]] On
>>> Behalf Of ext Sergey Beryozkin
>>> Sent: Sunday, August 18, 2013 6:32 PM
>>> To: <[e-mail]>
>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>

_______________________________________________
OAuth mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/oauth


------------------------------

Message: 7
Date: Wed, 21 Aug 2013 09:46:39 -0700
From: Phil Hunt <[e-mail]>
To: Anthony Nadalin <[e-mail]>
Cc: "<[e-mail]>" <[e-mail]>
Subject: Re: [OAUTH-WG] Audience parameter in authorization flow
Message-ID: <[e-mail]>
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>
[e-mail]







On 2013-08-21, at 9:45 AM, Anthony Nadalin <[e-mail]> 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: [e-mail] [mailto:[e-mail]] On Behalf Of Hannes Tschofenig
> Sent: Wednesday, August 21, 2013 9:41 AM
> To: Phil Hunt
> Cc: <[e-mail]>
> 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>
>> [e-mail]
>>
>>
>>
>>
>>
>>
>>
>> On 2013-08-21, at 9:30 AM, "Tschofenig, Hannes (NSN - FI/Espoo)" <[e-mail]> 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: [e-mail] [mailto:[e-mail]] On
>>>> Behalf Of ext Sergey Beryozkin
>>>> Sent: Sunday, August 18, 2013 6:32 PM
>>>> To: <[e-mail]>
>>>> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth



------------------------------

_______________________________________________
OAuth mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/oauth


End of OAuth Digest, Vol 58, Issue 72
*************************************