Re: [Ace] [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01

George Fletcher <> Tue, 29 January 2019 13:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C3072130E78 for <>; Tue, 29 Jan 2019 05:15:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XFzSkX0qBlXM for <>; Tue, 29 Jan 2019 05:15:07 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A825F12D4E8 for <>; Tue, 29 Jan 2019 05:15:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=a2048; t=1548767706; bh=/GXDzE4L+riIHn7kpgGnDsn4DlQBaHSZ40+rY3eSyJI=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=Onee/SINUTlfwlrmiakK3vhymOf4/M4D5qWKJ1ZJfUvtdU6yEhqDqIwCB4HjkVWWLplzFyGMp0R2x2ZHI+sTzbgVz0fb7gIiT6nkWjJXce3wr6TD2/PuvbzcuIA98WUNrR/3buaIgc7zY+5qCW5Q+oa1QyTU/Bp58jQyylEA00b2WuP7Yw+nl3oqvx7jQxWKPj4IAiEtaqfTSLhd81dZw6Pk2/dBU5kgobWOMOGMWr7UEyvsiw4jApg9b+L2Y9l05LIWvVU7/e/yrFgYG03sO0Ct9nDH1JhaIrerPS0c8fDJDrOT7JFJBsehht7mjL0czF1R8oehOEAk0f4y+363YA==
X-YMail-OSG: _lIGNVkVM1k.iPROOvnnwrIEB4e_XbWGl1.I0T2sikUwsg5dTAo6pK1E0SHqKIV uwmcKlBB05sxspGqe1jhY4DD8ae10p7iiIXgutfD9T2084l8B2Xi1uuKMXlgTwIhOM8bXhQsviqo u5T6_t0K1nRhaDb6aJOWpfjtxEZ.95o8srooznoUA.7StBYClMhNTe.Dyr8Ao3.Mf9YUCZjHE68e 3JWyvTYcwYYwxzxZyexz8ghnrpYdwb1m5Pq.LiC5zlP8ZoCEccYz_1FIP7Qmn1K2BMoAjOyFIwp6 KRtNB3m7wmEwAsg6zAEexL8CsLp6zyxCTBFwEdq6PITwaJ02pCkiiSm2a_QO9rwuepjonqapCXXr TB8OEDrAA5727Twazdn4mHZ9sjeIpaKlVGwaB1CbffmGRlAk0iQCcK1BBFRN86OeJV_QJhYe4RWr L_Kt4mq.dp1dMi0RfLTUFmrMqj.visy7BE1RAORKPpJjaXE2J1sc.ryQeH0hseGp.6AsRPCCyhag iDbN_mgdAJGKHwFpcqwRRcNRZvDvRwDiKDGNdCb09x99ZGmhAc.XaI_4A4yS404U_NZArjEuyU.. 7C_WMykaYesM4Hn72x1ILdxMRCGQ67_B_6FqgcTGrRsCcqsEU.95dCXR.KBtiSAoKuCMwXWo7gCl frTTFnlF27nRKCdqvr_b5drltaesjI.4QDmi6JL29X8PSZfUGaeeExMxp9kObJEVOmAcvtfCstJb btTnOMvCULj88cVD1.BkKJdBv2DMrbzqyMBsiwqedk84OpSEbE7YJrNsGVMQt9GqAN0mKtw.UfX5 d4L1a38v70hSFLRM3iAzpuYiaH9pnmfKcRYq1px1IYyOu.NC0AbUNAV2MVJVwNix9zHLlH6xc.1M jkjI_uMr8XzfoBwx.1ax12mcBffJ7Udli6FejNc8DzjmGVy3L4LdO0HiudZ130ZjWsvUGysX6gQ9 .N8kDcbJ1LEY6YuixkmvZ.qvhVCLemzI7toUO_HrMZNO3oDCwfYavde6OcfsdDxiWyfKSoxG3hZk WlYteZyxVn8.z6X18paMCBjcui7jVQNT.zCCtNvKiguNfDWQ0eGoBBPfOOLh_iVI6vw--
Received: from by with HTTP; Tue, 29 Jan 2019 13:15:06 +0000
Received: from (EHLO []) ([]) by (Oath Hermes SMTP Server) with ESMTPA ID 759dc410db180f06b2e23284340785dc; Tue, 29 Jan 2019 13:15:02 +0000 (UTC)
To: Ludwig Seitz <>,,
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: George Fletcher <>
Organization: AOL LLC
Message-ID: <>
Date: Tue, 29 Jan 2019 08:15:01 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------735FC6F53AF1B8CBF59CD64C"
Content-Language: en-US
Archived-At: <>
Subject: Re: [Ace] [OAUTH-WG] Shepherd write-up for draft-ietf-oauth-resource-indicators-01
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 29 Jan 2019 13:15:10 -0000

Thank you so much for the background!

I believe that since the latest draft of the resource indicators spec 
[1] allows for abstract identifiers, and since a URN is also a URI, you 
could easily use a URN syntax to accomplish the use case outlined in 
your email.


The spec currently outlines examples where the "resource identifier" is 
not a "single resource" in the context of a fully qualified API endpoint.

    Another example, for an API like SCIM [RFC7644  <>] that has
        multiple endpoints such as "",
        "", and
        "" The client would use
        "" as the resource so that the issued
        access token is valid for all the endpoints of the SCIM API.

Using "" is semantically equivalent to 
using "temperatureSensorGroup4711", at least to me:)



On 1/29/19 2:56 AM, Ludwig Seitz wrote:
> On 28/01/2019 23:12, George Fletcher wrote:
>> I also don't know that this raises to the level of "concern" but I 
>> find the parameter name of "req_aud" odd. Given that the parameter in 
>> the resource-indicators spec is 'resource' why not use a parameter 
>> name of 'audience'. That said, I have not read the thread on the ACE 
>> working group list so there could be very good reasons for the chosen 
>> name:)
>> I do think that there is a lot of overlap (in most cases) between 
>> 'resource' and 'audience' and having two parameters that cover a lot 
>> of the same semantics is going to be confusing for developers. When 
>> calling an API at a resource server, the 'audience' and the 
>> 'resource' are pretty equivalent. Maybe in other use cases they are 
>> distinctly separate?
> To give you all the background of "req_aud" from ACE (sorry for the 
> long text):
> Originally in ACE we had defined the "aud" parameter for requests to 
> the token endpoint with the semantics that the client was requesting a 
> token for a certain audience (i.e. requesting that the AS copy the 
> "aud" parameter value into the "aud" claim value of the token).
> We were then told that this collided with a use of "aud" in OAuth, 
> that specifies the intended audience of Authorization Servers (if I 
> remember correctly), so we decided to rename our parameter to 
> "req_aud" for "requested audience".
> Mike Jones then made us aware of the work on resource indicators, but 
> upon closer examination I found the "resource" parameter to be more 
> limited than the "req_aud", since resource specifically states:
> "Its value MUST be an absolute URI ... the "resource" parameter URI 
> value is an identifier representing the identity of the resource"
> My interpretation of this is that "resource" refers to a single 
> resource, which is more constrained than the definition of the "aud" 
> claim from 7519, which uses a StringOrURI value.  For example my 
> intent was to use "aud" and "req_aud" for group identifiers 
> ("temperatureSensorGroup4711") and other non-uri strings 
> (hash-of-public-key), which I cannot do with "resource". We therefore 
> decided to keep the "req_aud" parameter in 
> draft-ietf-ace-oauth-params, even though is clearly overlaps with 
> "resource".
> Any comments and suggestions about that line of reasoning (especially 
> from the OAuth point of view) are very welcome.
> /Ludwig

Identity Standards Architect
Verizon Media                     Work:
Mobile: +1-703-462-3494           Twitter:
Office: +1-703-265-2544           Photos: