Re: [OAUTH-WG] Audience parameter in authorization flow

Anthony Nadalin <tonynad@microsoft.com> Wed, 21 August 2013 16:46 UTC

Return-Path: <tonynad@microsoft.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DDD821F843F for <oauth@ietfa.amsl.com>; Wed, 21 Aug 2013 09:46:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.389
X-Spam-Level:
X-Spam-Status: No, score=-3.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCQsm9z9GZUU for <oauth@ietfa.amsl.com>; Wed, 21 Aug 2013 09:45:52 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0241.outbound.protection.outlook.com [207.46.163.241]) by ietfa.amsl.com (Postfix) with ESMTP id 21CFA11E80C5 for <oauth@ietf.org>; Wed, 21 Aug 2013 09:45:40 -0700 (PDT)
Received: from BY2PR03MB191.namprd03.prod.outlook.com (10.242.36.143) by BY2PR03MB208.namprd03.prod.outlook.com (10.242.36.156) with Microsoft SMTP Server (TLS) id 15.0.745.25; Wed, 21 Aug 2013 16:45:39 +0000
Received: from BY2PR03MB189.namprd03.prod.outlook.com (10.242.36.140) by BY2PR03MB191.namprd03.prod.outlook.com (10.242.36.143) with Microsoft SMTP Server (TLS) id 15.0.745.25; Wed, 21 Aug 2013 16:45:37 +0000
Received: from BY2PR03MB189.namprd03.prod.outlook.com ([169.254.6.82]) by BY2PR03MB189.namprd03.prod.outlook.com ([169.254.6.157]) with mapi id 15.00.0745.000; Wed, 21 Aug 2013 16:45:37 +0000
From: Anthony Nadalin <tonynad@microsoft.com>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>, Phil Hunt <phil.hunt@oracle.com>
Thread-Topic: [OAUTH-WG] Audience parameter in authorization flow
Thread-Index: AQHOnDCkyq+lVs2A30av5TP3RarnFZmf3xiAgAABVACAAAGggIAAAJ9A
Date: Wed, 21 Aug 2013 16:45:36 +0000
Message-ID: <1d4b764800be4cff991f02a91948d2c0@BY2PR03MB189.namprd03.prod.outlook.com>
References: <5210F714.80305@gmail.com> <1373E8CE237FCC43BCA36C6558612D2AA272E8@USCHMBX001.nsn-intra.net> <CF5728A9-5271-4B57-A2B3-40A9FC1BC983@oracle.com> <5214ED9B.3070406@gmx.net>
In-Reply-To: <5214ED9B.3070406@gmx.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e8:ed31::3]
x-forefront-prvs: 0945B0CC72
x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(479174003)(52084003)(24454002)(13464003)(377424004)(199002)(189002)(164054003)(51704005)(19580395003)(79102001)(15974865002)(74366001)(19580405001)(54356001)(83322001)(76482001)(54316002)(56776001)(74316001)(15202345003)(53806001)(80976001)(63696002)(76786001)(46102001)(69226001)(74876001)(80022001)(77096001)(56816003)(65816001)(81542001)(74662001)(83072001)(4396001)(47446002)(81686001)(50986001)(59766001)(76796001)(77982001)(19580385001)(76576001)(47736001)(31966008)(81342001)(47976001)(33646001)(49866001)(51856001)(74502001)(81816001)(74706001)(42262001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB191; H:BY2PR03MB189.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ed31::3; RD:InfoNoRecords; A:1; MX:1; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossPremises-AuthAs: Internal
X-MS-Exchange-CrossPremises-AuthMechanism: 03
X-MS-Exchange-CrossPremises-AuthSource: BY2PR03MB189.namprd03.prod.outlook.com
X-MS-Exchange-CrossPremises-SCL: 1
X-MS-Exchange-CrossPremises-messagesource: StoreDriver
X-MS-Exchange-CrossPremises-BCC:
X-MS-Exchange-CrossPremises-originalclientipaddress: 2001:4898:80e8:ed31::3
X-MS-Exchange-CrossPremises-avstamp-service: 1.0
X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0;
X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent
X-MS-Exchange-CrossPremises-ContentConversionOptions: False; 00160000; True; ; iso-8859-1
X-OrganizationHeadersPreserved: BY2PR03MB191.namprd03.prod.outlook.com
X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Audience parameter in authorization flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Aug 2013 16:46:09 -0000

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-bounces@ietf.org [mailto:oauth-bounces@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
> phil.hunt@oracle.com
>
>
>
>
>
>
>
> On 2013-08-21, at 9:30 AM, "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@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-bounces@ietf.org [mailto:oauth-bounces@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