Re: [OAUTH-WG] updated Distributed OAuth ID

Dick Hardt <dick.hardt@gmail.com> Tue, 24 July 2018 20:21 UTC

Return-Path: <dick.hardt@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 C9412130DE4 for <oauth@ietfa.amsl.com>; Tue, 24 Jul 2018 13:21:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Jloi4XW5KW4v for <oauth@ietfa.amsl.com>; Tue, 24 Jul 2018 13:21:38 -0700 (PDT)
Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (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 16EE4130E02 for <oauth@ietf.org>; Tue, 24 Jul 2018 13:21:38 -0700 (PDT)
Received: by mail-pg1-x536.google.com with SMTP id v13-v6so3650569pgr.10 for <oauth@ietf.org>; Tue, 24 Jul 2018 13:21:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FB2yLYLjrjNGqpg8spxK+abZ8/4BZ/qabdQdMNJfMDE=; b=Oukmxw5ie7l4S3fOKZrIYvqlGBOshoV7yRRt6mp2UqEyLr94TTy1emX/IfOIdNIRJ0 RNbvewLdf0gPZq8Bpkb3sMo0EfBq/hR0KyNPDfby55j5sQoTelWnp3w18YaAZq+bwYfr CAJ6pbdDU+iFs6xurdQOaPO/8NPnPDhEamM5ofytiHqBu1zx/iauJjDJhn30aNHNl5lO 9bGPFxZzZJgJMb29c+2OOb0cPoJhMNCjZ6M65dpvdQmTS3faxxeuG67mGufG3HSQqMud PMZ75eZ3Rvz79H5vKF6vO16R6MWjluArl2TUu4jL+DrHQFvErW5ImZv2brrpxW9HpSAG ka7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FB2yLYLjrjNGqpg8spxK+abZ8/4BZ/qabdQdMNJfMDE=; b=dgow3YZKe5W5/DDK1jH+ntInjOIMiWHR9PYQMrGAkHk912t576A5L6yYnEJO9+lbrr a9Sk7sFqcQzqVHdWz7XyYN9bkod6e5Rlh9SEBh8ItPIU1rHD5Fm5G3eYcD3KPnP/ALUf oDrVIzF7JUtd7/tj0o7nvGY9bnm6WnJZeRTTQLiiy7OAWAdVnVe4fhI1S8HLt3dBzrxC 5l2y/uCmf3N0VmaFeRzZtj3OHCPCpnnhZAf7gqUEEPQDQSUokhSgAqijjyy1ZKxHchEa zNE1VKovJ58onFHUkvirsxhGP/Fl+c/5jEl/imhGNljKZ+2ONtHftp4YMIyzINIkyhPG wIbA==
X-Gm-Message-State: AOUpUlEozH1Ah1GCBsfQGPU8DGtb7WFWXSC1PnerhgLNxivGSzrSDg4y RK78J7fmCsqciXxpjBhKrV0zjJhB/xIC1z0Joea0yvon
X-Google-Smtp-Source: AAOMgpfSPvYsReOJZx7ASmbSrLy+bLNT9pLdQkP1ThP6zsnPlCZxv93WOr/n/AL0JOMtGmD0NJiiWNe3IFnJlb7qZmc=
X-Received: by 2002:aa7:84c2:: with SMTP id x2-v6mr18996808pfn.220.1532463697507; Tue, 24 Jul 2018 13:21:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a17:90a:9ce:0:0:0:0 with HTTP; Tue, 24 Jul 2018 13:21:17 -0700 (PDT)
In-Reply-To: <E9F22C9E-AD03-45B9-9BBB-E98EC84178B8@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>
From: Dick Hardt <dick.hardt@gmail.com>
Date: Tue, 24 Jul 2018 13:21:17 -0700
Message-ID: <CAD9ie-usNZebvx4HE1Kc-ya1Fr+H_6LAPWLK2OOLdQomWVP-tw@mail.gmail.com>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: oauth@ietf.org
Content-Type: multipart/alternative; boundary="000000000000523b890571c4823a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/-vzOzmOIdy6WDQY12YFhCq3rqHk>
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: Tue, 24 Jul 2018 20:21:40 -0000

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>om>:
>>
>> 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>om>:
>>> >
>>> > 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.
>>
>>
>