IETF Logo Mail Archive

Re: [OAUTH-WG] updated Distributed OAuth ID

Torsten Lodderstedt <torsten@lodderstedt.net> Mon, 23 July 2018 07:42 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 CD284130E1E for <oauth@ietfa.amsl.com>; Mon, 23 Jul 2018 00:42:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 dYmaXjMSgsGl for <oauth@ietfa.amsl.com>; Mon, 23 Jul 2018 00:42:25 -0700 (PDT)
Received: from smtprelay07.ispgateway.de (smtprelay07.ispgateway.de [134.119.228.99]) (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 E58F212D949 for <oauth@ietf.org>; Mon, 23 Jul 2018 00:42:24 -0700 (PDT)
Received: from [80.187.100.135] (helo=[10.77.119.75]) by smtprelay07.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from <torsten@lodderstedt.net>) id 1fhVU5-0005Cl-K1; Mon, 23 Jul 2018 09:42:22 +0200
Content-Type: multipart/signed; boundary="Apple-Mail-4036E3F1-8D72-4D07-A6A6-0942840AC992"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (1.0)
From: Torsten Lodderstedt <torsten@lodderstedt.net>
X-Mailer: iPhone Mail (15F79)
In-Reply-To: <CAD9ie-tNDcWdT0iwNFYoL4x+gB6Yr=QNSjAOrV7ZjwqyLaUQeQ@mail.gmail.com>
Date: Mon, 23 Jul 2018 09:42:20 +0200
Cc: oauth@ietf.org
Content-Transfer-Encoding: 7bit
Message-Id: <0E9E324F-D6EB-45AB-B066-BFAA87B91A21@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> <419D8DCF-817B-484F-8EB7-FEB4C5BA51DC@lodderstedt.net> <CAD9ie-tNDcWdT0iwNFYoL4x+gB6Yr=QNSjAOrV7ZjwqyLaUQeQ@mail.gmail.com>
To: Dick Hardt <dick.hardt@gmail.com>
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/8iJWMw1FC2acQvzvadmzjtB8FcQ>
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: Mon, 23 Jul 2018 07:42:28 -0000

Hi Dick,

> Am 23.07.2018 um 00:52 schrieb Dick Hardt <dick.hardt@gmail.com>:
> 
> Entering in an email address that resolves to a resource makes sense. It would seem that even if this was email, calendar etc. -- that those would be different scopes for the same AS, not even different resources. That is how all of Google, Microsoft work today.

I don’t know how those services work re OAuth resources. To me it’s not obvious why one should make all those services a single OAuth resource. I assume the fact OAuth as it is specified today has no concept of identifying a resource and audience restrict an access token led to designs not utilizing audience restriction. 

Can any of the Google or Microsoft on this list representatives please comment?

In deployments I‘m familiar with email, calendar, contacts, cloud and further services were treated as different resources and clients needed different (audience restricted) access tokens to use it.

In case of YES, the locations of a user’s services for account information, payment initiation, identity, and electronic signature are determined based on her bank affiliation (bank identification code). In general, each of these services may be provided/operated by a different entity and exposed at completely different endpoints (even different DNS domains).

kind regards,
Torsten.

v2.23.0 | Report a Bug | By Email