Re: [OAUTH-WG] Comments on draft-jones-oauth-resource-metadata-00

"Phil Hunt (IDM)" <> Sun, 13 November 2016 11:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B20A01296BD for <>; Sun, 13 Nov 2016 03:03:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.687
X-Spam-Status: No, score=-5.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Aw0gxjMghGPx for <>; Sun, 13 Nov 2016 03:03:24 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C06731296E0 for <>; Sun, 13 Nov 2016 03:03:24 -0800 (PST)
Received: from ( []) by (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id uADB3Mss005822 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 13 Nov 2016 11:03:22 GMT
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id uADB3LTC017572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 13 Nov 2016 11:03:22 GMT
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id uADB3LtE000391; Sun, 13 Nov 2016 11:03:21 GMT
Received: from [] (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 13 Nov 2016 03:03:20 -0800
Content-Type: multipart/alternative; boundary="Apple-Mail-1BDC4C29-426C-4249-B737-9E4D5372FB1E"
Mime-Version: 1.0 (1.0)
From: "Phil Hunt (IDM)" <>
X-Mailer: iPhone Mail (14B100)
In-Reply-To: <>
Date: Sun, 13 Nov 2016 20:03:17 +0900
Content-Transfer-Encoding: 7bit
Message-Id: <>
References: <> <> <> <>
To: Torsten Lodderstedt <>
X-Source-IP: []
Archived-At: <>
Cc: "" <>
Subject: Re: [OAUTH-WG] Comments on draft-jones-oauth-resource-metadata-00
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 13 Nov 2016 11:03:27 -0000

For example scim has many resources. But it is reasonable to discover at its root since clients may ask for other resources. The as would not likely change across a single scim provider. 


> On Nov 13, 2016, at 5:27 PM, Torsten Lodderstedt <> wrote:
> I see your point but do you really think this is needed and efficient enough for practical use?
> Basing metadata handling on single resources (distinct URLs including different query parameters, right?) in my opinion means:
> - the client needs to discovery the AS for every of those URLs
> - the client needs to acquire an access token per URL
> - I'm not quite sure what it means when it comes to token binding
> I think it would be good idea to have a container on a more coarse grain level in order to make that more efficient. If every resource (distinct URL) belongs to such a container (let's call it resource server or something else), the client-side handling should become     easier.
> BTW: we don't have different meta data for token endpoint and authorization endpoint of a particular AS, right? So the comparision does not completely fit.
> What do you think?
> best regards,
> Torsten.
>> Am 13.11.2016 um 15:37 schrieb Mike Jones:
>> Actually, it’s intentionally a particular resource that the metadata applies to – exactly as the AS metadata applies to a particular AS.  It is *not* metadata about all resources that might be managed by a resource server, just as the AS metadata is not about all ASs that a particular server (such as a multi-tenant server) might manage.
>> Bear in mind that just as different ASs are likely to use different keys for security reasons, even if they are on the same physical server – such as in the multi-tenant case, different resources need to be able to use different keys, even if they are hosted at the same resource server.  That mandates the metadata being resource-specific.
>> For what it’s worth, if we ever do an OAuth 3.0, I believe we should get rid of the “resource server” term entirely.  It doesn’t have any actionable semantics tied to it and its existence only encourages confusion.
>> Thanks for reading the draft, Torsten.
>>                                                        -- Mike
>> From: Torsten Lodderstedt [] 
>> Sent: Sunday, November 13, 2016 2:32 PM
>> To: Mike Jones <>;
>> Cc:
>> Subject: Re: [OAUTH-WG] Comments on draft-jones-oauth-resource-metadata-00
>> Hi Mike,
>> just read your spec and I'm also a bit confused about the "resource" meta data element in section 2.
>> I would assume the metadata are provided for a certain resource server managing a set of resources in a particular administrative domain. So I would prefer to name the respective element "resource_server". In the example George gave the URL would be "<tenantid>/". Resource managed by a particular resource server could use sub-paths of the respective URL, such as "<tenantid>/users/<userid>".
>> best regards,
>> Torsten.
>> Am 05.08.2016 um 02:10 schrieb George Fletcher:
>> Mike, thanks for drafting and publishing these specifications. I have a couple of questions regarding the draft-jones-oauth-resource-metadata-00.
>> 1. Is a "protected resource" a server? or an actual API endpoint. The non-normative examples use /.well-known/oauth-protected-resource and /resource1/.well-known/oauth-protected-resource which is a little unclear. I think of "resource" as something like "Mail" or "Instant Messaging".
>> 2. Assuming that "protected resource" means an actual API endpoint, what is the expected location of the metadata for a fully REST compliant API where the full URL points to a specific resource and not the concept of a general API.
>> Using an example of an IdP that supports user management capabilities. Let's assume the IdP supports a REST API of...
>>     CREATE -- POST<tenantid>/users
>>     READ -- GET<tenantid>/users/<userid>
>>     UPDATE -- PUT<tenantid>/users/<userid>
>>     DELETE -- DELETE<tenantid>/users/<userid>
>> Assuming there are 3 tenants (tenantA, tenantB, tenantB) and lots of users. Where does the .well-known/oauth-protected-resource get added?
>>    ??
>> In this case would not the oauth-protected-resource metadata be duplicated across the set of tenants and users? Is that the desired behavior?
>> Thanks,
>> George
>> _______________________________________________
>> OAuth mailing list
> _______________________________________________
> OAuth mailing list