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

Mike Jones <> Sun, 13 November 2016 06:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 698A91295BE for <>; Sat, 12 Nov 2016 22:37:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Status: No, score=-2.011 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0X989E3M-sMY for <>; Sat, 12 Nov 2016 22:37:12 -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 549BB1295EC for <>; Sat, 12 Nov 2016 22:37:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=giK8RvSk6a1cqrVJ6MuAmPOTjXnKEIHjivb+31mXxLY=; b=blN3tYRJyyIPss+yndI0xzCp4CR/nh2gAqMUC3hBml0ehE1ivX9J9P0CfTky9XNdgyfynbZznK8MBOa0fdUMB0uNHjO73LGjIniM27EuZuGdH7ncwHQOFBAs81HUYE1ae8YJZzlYWMOBKEI734RG/aimUfhefdylMy7bdHLBfSo=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.6; Sun, 13 Nov 2016 06:37:08 +0000
Received: from ([]) by ([]) with mapi id 15.01.0707.015; Sun, 13 Nov 2016 06:37:08 +0000
From: Mike Jones <>
To: Torsten Lodderstedt <>, "" <>
Thread-Topic: [OAUTH-WG] Comments on draft-jones-oauth-resource-metadata-00
Thread-Index: AQHR7nMq9VN5jV0CyUuUVt511dz2nqDXAaWAgAAQcsA=
Date: Sun, 13 Nov 2016 06:37:08 +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: []
x-microsoft-exchange-diagnostics: 1; CO2PR03MB2360; 7:TRDQDDPPgYIPCRj7JHZX3ODsbmL+Jzkz/HHa25hu71SltfysCutPsUe5zwlSbAZlH9fxU6BDgj+3ajRxpHayZ9Q1WA/fRRMW+2ebHW9mwZntTCIEGd8jfcOx+zWbh7aVY/5ZD5WkDyXqFc9DsSBSTQFGIhMuYXLYfWPYrSGUErC3YSJryWrRBoKDn0PgLssBGb+MZ8PR+MX9KHhQC2nsxXSu2SNJ3OCrFPrw4fzA1yEL+GQoMp0T45xTdW56XPodB4TFDBBUmUSxW1NLR9+wX/019jK36+f9LIoJ6fSuwbhQ0WP2HcYq1ezAmTUmQaQ7m+IRF90Vw/CrxSBNN5ZxaDdoklhBOFWhElCXm5pTassm+3qdOPV3/Ym5bu+RxSYV
x-ms-office365-filtering-correlation-id: 33e5d4f2-2aa9-42b9-fc0d-08d40b8f7dbf
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CO2PR03MB2360;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(158342451672863)(149059832740258)(192374486261705)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(6045074)(6060229)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6046074)(6061226); SRVR:CO2PR03MB2360; BCL:0; PCL:0; RULEID:; SRVR:CO2PR03MB2360;
x-forefront-prvs: 012570D5A0
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(336003)(377454003)(199003)(189002)(5001770100001)(66066001)(74316002)(97736004)(7906003)(33656002)(87936001)(8936002)(2950100002)(229853002)(122556002)(2900100001)(7736002)(77096005)(5660300001)(54356999)(9686002)(189998001)(50986999)(76176999)(101416001)(2501003)(6116002)(86362001)(3280700002)(102836003)(586003)(5005710100001)(3846002)(10090500001)(7846002)(68736007)(76576001)(86612001)(3660700001)(8990500004)(81156014)(2906002)(790700001)(99286002)(106356001)(81166006)(230783001)(106116001)(4326007)(105586002)(92566002)(8676002)(7696004)(10290500002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR03MB2360;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CO2PR03MB235854922A12B3E4CCE498C7F5BD0CO2PR03MB2358namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2016 06:37:08.1823 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR03MB2360
Archived-At: <>
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 06:37:15 -0000

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 <>;
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,
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?


OAuth mailing list<>