Re: [OAUTH-WG] updated Distributed OAuth ID

Torsten Lodderstedt <torsten@lodderstedt.net> Sat, 21 July 2018 16:49 UTC

Return-Path: <torsten@lodderstedt.net>
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 5F012130DC4 for <oauth@ietfa.amsl.com>; Sat, 21 Jul 2018 09:49:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 MP8OyvA-syQX for <oauth@ietfa.amsl.com>; Sat, 21 Jul 2018 09:49:09 -0700 (PDT)
Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2560A127333 for <oauth@ietf.org>; Sat, 21 Jul 2018 09:49:09 -0700 (PDT)
Received: from [80.187.120.149] (helo=[10.150.89.103]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from <torsten@lodderstedt.net>) id 1fgv47-0000Kn-0U; Sat, 21 Jul 2018 18:49:07 +0200
Content-Type: multipart/signed; boundary="Apple-Mail-E12ECF2A-90C9-487C-BF96-94BC9F394B69"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (1.0)
From: Torsten Lodderstedt <torsten@lodderstedt.net>
X-Mailer: iPad Mail (15F79)
In-Reply-To: <CAD9ie-s2nwXovWM3OfDG8MJvs+TVzX_KearbW1Uq_6Nz9X_5mg@mail.gmail.com>
Date: Sat, 21 Jul 2018 18:49:05 +0200
Cc: oauth@ietf.org
Content-Transfer-Encoding: 7bit
Message-Id: <419D8DCF-817B-484F-8EB7-FEB4C5BA51DC@lodderstedt.net>
References: <CAD9ie-sW7EbfuJWc8_fkLO0wGg9kd0VR=xuO346yOoMK8ZGiyQ@mail.gmail.com> <B976F6E6-95E3-4B50-A54B-C207FA4D82A7@lodderstedt.net> <CAD9ie-sUM3jQm8pN1e4wUpSAJw=DW=xDXJS--R6icpjJsnV_AA@mail.gmail.com> <3A81E7C4-5FE1-448A-BB3D-540D30BF2637@lodderstedt.net> <CAD9ie-s2nwXovWM3OfDG8MJvs+TVzX_KearbW1Uq_6Nz9X_5mg@mail.gmail.com>
To: Dick Hardt <dick.hardt@gmail.com>
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/pjROkBHGmB9vtbOJgaEiiAvO1T0>
Subject: Re: [OAUTH-WG] updated Distributed OAuth ID
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.27
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, 21 Jul 2018 16:49:12 -0000

Hi Dick,

Am 19.07.2018 um 15:46 schrieb Dick Hardt <dick.hardt@gmail.com>:

>> I think any scenario with multiple resource servers relying on the same AS for authorization where the client acts on behalf of the resource owner qualifies for grant type code and distributed OAuth. 
>> 
>> Let’s assume a user wants to authorize a client for access to her cloud storage, email account and contacts when setting app the respective app.
> 
> Would you walk me through the user experience that happened for the client to do discovery on these three resources? In other words, what did the user do to get the client to call the resource and get back the 401 response?

I would assume the user enters the URLs or identifies the respective service providers in the app (e.g. by entering her email address). The client then sends an initial request as described in your draft and gets back the 401.

Doing so for several resources will give the client the AS URL for all involved resources. If the client compares the iss claims it will figure our all resources are protected by the same AS and can authorize access via a single authz code grant flow.

kind regards,
Torsten.