Re: [OAUTH-WG] updated Distributed OAuth ID

Torsten Lodderstedt <torsten@lodderstedt.net> Wed, 25 July 2018 08:47 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 A06EE130E51 for <oauth@ietfa.amsl.com>; Wed, 25 Jul 2018 01:47:24 -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 Q6_k5-qe75uK for <oauth@ietfa.amsl.com>; Wed, 25 Jul 2018 01:47:21 -0700 (PDT)
Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.35]) (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 F37B8130E4A for <oauth@ietf.org>; Wed, 25 Jul 2018 01:47:20 -0700 (PDT)
Received: from [80.187.110.206] (helo=[10.110.206.20]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from <torsten@lodderstedt.net>) id 1fiFS1-00067G-Sy; Wed, 25 Jul 2018 10:47:18 +0200
Content-Type: multipart/signed; boundary="Apple-Mail-C14DF983-A490-46DF-AA87-664FDE712C8A"; protocol="application/pkcs7-signature"; micalg="sha1"
Content-Transfer-Encoding: 7bit
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Mime-Version: 1.0 (1.0)
Date: Wed, 25 Jul 2018 09:22:16 +0200
Message-Id: <4EEF266D-12A7-432C-A758-BF5CE14ABEEF@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> <0E9E324F-D6EB-45AB-B066-BFAA87B91A21@lodderstedt.net> <CAD9ie-uXvg=bLLeK8PzhWjd_Any5cvxDisnAdy9hquLqWwR6Fw@mail.gmail.com> <0FC092A4-9E3D-4F1A-A494-9B619F90C3AA@lodderstedt.net> <CAD9ie-tBrskz5OqYFqpTg1jiaeDXAte7f+SFx1Pqh8LLFVd7jQ@mail.gmail.com> <E9F22C9E-AD03-45B9-9BBB-E98EC84178B8@lodderstedt.net> <CAD9ie-usNZebvx4HE1Kc-ya1Fr+H_6LAPWLK2OOLdQomWVP-tw@mail.gmail.com> <D82025E1-3547-418E-97AE-E63423B734E1@lodderstedt.net> <CAD9ie-u3XgkEV1csyDVJ6mPnVUHqB-mtGcQbfAGozVU_FNtcMg@mail.gmail.com> <C8DD3E1A-1736-4F62-BF68-F5214B692732@lodderstedt .net>
Cc: oauth@ietf.org
In-Reply-To: <C8DD3E1A-1736-4F62-BF68-F5214B692732@lodderstedt.net>
To: Dick Hardt <dick.hardt@gmail.com>
X-Mailer: iPhone Mail (15F79)
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/rorKH1Di7RvzfpACYc1Rxv2jrqE>
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: Wed, 25 Jul 2018 08:47:25 -0000

> 
> We are building up the scheme. One banking group is deployed.
> 
>> 
>> Today, a separate flow us required for each RS, correct?
> 
> We support combined flows because this is a key requirement for us. But this comes at a price: we cannot tightly audience restrict our tokens. We use handles and Introspection to ensure every RS only gets to know the data it needs to know. And we must use sender constraint tokens in order to prevent token leakage. Having an interoperable way to obtain structured and audience restricted access tokens would simply development, reduce coupling between AS & RS and improve performance.

I forgot to mention, a deployment supporting strict resource server specific audience restriction with structured access tokens is in place at Deutsche Telekom for years now ( even predating OAuth 2.0). As the only drawback, encoding of resource servers in scopes and refresh token handling to obtain RS-specific access tokens is proprietary.

> 
>> 
>> In the future, you would like the client to ask for multiple resources that are managed by the same AS, correct?
>> 
>> 
>>> On Tue, Jul 24, 2018 at 1:47 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
>>> For every bank (and their customers) there is a set of services run by the bank or other entities, which rely on the AS of the particular bank for authorization. In some cases, a service may bring its own AS to the party (due to technical restrictionions). So an RP binding to a certain bank-specific service ecosystem needs to determine which AS every RS relies on. Authorization requests for RS relying on the same AS (the bank) can be combined into s single request/flow resulting in an optimized UX.
>>> 
>>>> Am 24.07.2018 um 22:21 schrieb Dick Hardt <dick.hardt@gmail.com>:
>>>> 
>>>> I'm trying to understand the use case. 
>>>> 
>>>> It still is vague. Are you saying that each of these is run by a different entity, but all trust the bank as the authorization server to manage if the user has granted permission to use the resource rather than managing it themselves? 
>>>> 
>>>> account information, payment initiation, identity, and electronic signature 
>>>> 
>>>>>> On Tue, Jul 24, 2018 at 8:59 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
>>>>>> 
>>>>>> And who is the AS?
>>>>> 
>>>>> In case of yes, it’s typically the bank. At Deutsche Telekom, it is the central AS/IDP. 
>>>>> 
>>>>> Why are you asking?
>>>>> 
>>>>>> 
>>>>>>>> On Mon, Jul 23, 2018 at 12:50 PM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
>>>>>>>> 
>>>>>>> 
>>>>>>>> Am 23.07.2018 um 13:58 schrieb Dick Hardt <dick.hardt@gmail.com>:
>>>>>>>> 
>>>>>>>> In your examples, are these the same AS?
>>>>>>> 
>>>>>>> yes
>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On Mon, Jul 23, 2018 at 3:42 AM Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
>>>>>>>>> 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.
>>>>>> 
>>>> 
>>