Re: [OAUTH-WG] Status of draft-tschofenig-oauth-audience

Mike Jones <> Wed, 20 January 2016 22:25 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B4F471B29AD for <>; Wed, 20 Jan 2016 14:25:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BEpHlfYGd4rt for <>; Wed, 20 Jan 2016 14:25:38 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9DB101B29AE for <>; Wed, 20 Jan 2016 14:25:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jo8MxEaVI3BGRgTYHNzcaNjBPSW8MvUuMLnivmhJpio=; b=R7kZH5WcMnHYHFU0cnCfobg81uydq172DVpGz/mRPol2MYlUtqnUNPvCJhoP2kPLFrc1kN5lB6rsvZw6KDmjK1/tBOMfMqbp8ZRplqmuI1Zf4I/ca/ArNCMYbHJptbfLESkKeQALVFjUNvn6OCQubxqYw4sgj6iY6secmySzX7Y=
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.1.365.19; Wed, 20 Jan 2016 22:25:35 +0000
Received: from ([]) by ([]) with mapi id 15.01.0365.024; Wed, 20 Jan 2016 22:25:35 +0000
From: Mike Jones <>
To: Brian Campbell <>, Hannes Tschofenig <>
Thread-Topic: [OAUTH-WG] Status of draft-tschofenig-oauth-audience
Thread-Index: AQHRU2z5bd5WDYhJ/0CRjTQN4ztm9p8EdoyAgACDlICAAAE0AA==
Date: Wed, 20 Jan 2016 22:25:35 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: [2001:4898:80e8:2::37e]
x-ms-office365-filtering-correlation-id: b4d5a5d6-778d-4e8e-04f6-08d321e89dd6
x-microsoft-exchange-diagnostics: 1; BY2PR03MB444; 5:ITk1+7V7X2fJspbRRfqCVmSuSBfR9sjj1p7r4giMauKdblO/AqKeHhwHLR4R2SMvKV5dnB+MRPqYFTn8/DyKzol4dW7fOzXDDzqjESJbfMxsMhR/lyhy43ZPEttbEenayXP/e/xK4qMUCH5RcWLm4A==; 24:A+0NvQAwjATxzPaUiJl9A3DkjBXEiXsMb9HRpM7q75gt+teWI7K1wM0MQRVBZORMTJVJjAItQvHiKFQ45KZbudut0Aa3nsYb2NaKxYkrgiI=
x-exchange-antispam-report-test: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444; UriScan:;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001)(61426038)(61427038); SRVR:BY2PR03MB444; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB444;
x-forefront-prvs: 0827D7ACB9
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(164054003)(189002)(377454003)(199003)(479174004)(87936001)(15975445007)(92566002)(106116001)(105586002)(19617315012)(19580405001)(5004730100002)(106356001)(8990500004)(54356999)(5008740100001)(10090500001)(19609705001)(5001960100002)(11100500001)(4326007)(2906002)(77096005)(5002640100001)(790700001)(1096002)(50986999)(19625215002)(76176999)(97736004)(10400500002)(102836003)(19580395003)(99286002)(586003)(2950100001)(10290500002)(33656002)(122556002)(5005710100001)(81156007)(16236675004)(40100003)(1220700001)(6116002)(101416001)(2900100001)(93886004)(5001770100001)(19300405004)(189998001)(86612001)(5003600100002)(86362001)(76576001)(74316001)(230783001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB444;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442A47609A3B5AD87169294F5C20BY2PR03MB442namprd_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jan 2016 22:25:35.1831 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB444
Archived-At: <>
Cc: oauth <>
Subject: Re: [OAUTH-WG] Status of draft-tschofenig-oauth-audience
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 20 Jan 2016 22:25:40 -0000

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 [] 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): has an audience parameter has an aud parameter 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<> 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 <<>> 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.


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]
> _______________________________________________
> OAuth mailing list

OAuth mailing list<>