[OAUTH-WG] Multiple authorization servers for one resource server

Takahiko Kawasaki <daru.tk@gmail.com> Sat, 12 March 2016 03:02 UTC

Return-Path: <daru.tk@gmail.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 A70EC12D554 for <oauth@ietfa.amsl.com>; Fri, 11 Mar 2016 19:02:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8aP2niGKrr9 for <oauth@ietfa.amsl.com>; Fri, 11 Mar 2016 19:02:28 -0800 (PST)
Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3AA712DAEE for <oauth@ietf.org>; Fri, 11 Mar 2016 19:02:27 -0800 (PST)
Received: by mail-lb0-x231.google.com with SMTP id k15so180161576lbg.0 for <oauth@ietf.org>; Fri, 11 Mar 2016 19:02:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc; bh=GqwmB+zV42lQWJTDiGZ+mQvUVMpB7dvDXyAs9Wf+Iu8=; b=DP6CCEfPPtY4gNaSPGb1R/PuZuBmeOszLdjBS5UUnfNAyiu4dLUKP0MBz3xjYscwHw bVCL1WMq5CpeelqpxJRRYJER+QaciWFvub2ZsH9l/aotlGe+72fFydiwMaJkh5bRVC+/ oNw89fF+NoGWOvMzSyTXz0JTSa+iqT060k4WFjoYb7eTSLNyYpBKjhdl1wTE1jc+95Od uP3hTdVo69aK669+h2K2QXwYe5/uTPhRrKpPMOYgyFoqGyxCDuM8ZyztM6OlcmS4/hoI zAE0LXAoRz+XYZ7Q9diEI6TBC+6GEP0ftj3peX2RpkUhQwOQVo9SdDCZpyN46/aop7Td mzig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc; bh=GqwmB+zV42lQWJTDiGZ+mQvUVMpB7dvDXyAs9Wf+Iu8=; b=R6U5C5VNz91yVPjLV99YkUr6iuaEEIjS5QcA+7zCAQoWpazmDMtlnlXLDn+J9o8NPt zltr06hJgcilCTQ4WA5utEghmAjweDo+UXs4jAc/Eyp9fpGN2JNbToQ+RmO+TZKMN3is n+mWGssQO84fmykLKaT49aJ718kWCQhnSvbryoiel9TLVRYMtefyS6FS1H6H1vJPYYcL SocNqdmU3fem39Q+ZYKP/m6tU421vgx+TAQrFLzZCkzJB+f0LDhlogT4sr9xi49eaNYz 3HL3T71OXrLLfk/NmmPhSs8XRDrdec+OE7XjCMuP7xx4wwrGTEBpM2tF2OckiSDQWaHz qfuw==
X-Gm-Message-State: AD7BkJK4sfidbVEVcyILvY0/8QstULufSffnfRMNwzGEhrUeMbH8zUH9oz3TgASh5gWAA51idLEQBzjr1B78mQ==
MIME-Version: 1.0
X-Received: by 10.25.127.216 with SMTP id a207mr4677816lfd.116.1457751746045; Fri, 11 Mar 2016 19:02:26 -0800 (PST)
Received: by 10.112.129.100 with HTTP; Fri, 11 Mar 2016 19:02:26 -0800 (PST)
Date: Sat, 12 Mar 2016 12:02:26 +0900
Message-ID: <CAGpwqP-coOvKeud4Bk=LgeF5N-wor=Uid==hZQPoiSDby0pa3A@mail.gmail.com>
From: Takahiko Kawasaki <daru.tk@gmail.com>
To: "oauth@ietf.org" <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="001a113ec4dafe7157052dd14693"
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/PUecY9DRXaXw05hV8xline_j7bg>
Subject: [OAUTH-WG] Multiple authorization servers for one resource server
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Sat, 12 Mar 2016 03:02:29 -0000

Hello,

I have a question.

If there exist multiple authorization servers that can issue access tokens
for one resource server, when the resource server receives an access token
from a client application, as the first step, the resource server has to
determine which authorization server to use for access token introspection.

Is there any standard way to determine which authorization server to use?

There may be several ways, for example:

(1) Embed information about the access token issuer in the access token.
(2) Add a request parameter to identify the access token issuer.
(3) Separate protected resource endpoints for each authorization server.

If there is a standard way, I'd like to know it.

Best Regards,
Takahiko Kawasaki