Re: [OAUTH-WG] We appear to still be litigating OAuth, oops

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 24 February 2021 17:05 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EAFA3A181A; Wed, 24 Feb 2021 09:05:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 hGqn6r26qAgm; Wed, 24 Feb 2021 09:05:17 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E76383A1816; Wed, 24 Feb 2021 09:05:16 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 141AC38A2B; Wed, 24 Feb 2021 12:09:26 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id kFomh5ZTpsbw; Wed, 24 Feb 2021 12:09:25 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8695638A29; Wed, 24 Feb 2021 12:09:25 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1604357B; Wed, 24 Feb 2021 12:05:14 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "oauth@ietf.org" <oauth@ietf.org>, ietf@ietf.org
Subject: Re: [OAUTH-WG] We appear to still be litigating OAuth, oops
In-Reply-To: <E84B4446-5F74-402B-8071-A1164EF0B02C@mit.edu>
References: <CAMm+LwgbK3HYDjSHnTN3f6hWSQCQrEjHLNn6z0JpfY7hdxaQpg@mail.gmail.com> <A8128346-B557-472F-B94F-8F624F955FCE@manicode.com> <eb2eaaa7-7f7e-4170-ab87-1cc1fdd3359b@www.fastmail.com> <CAJot-L0PS_3LxEkC-jd1aqXDdYF+z8BajSs4Rhx3LgRPn6wkdQ@mail.gmail.com> <DAB127D7-809F-4EC2-A043-9B15E2DB8E07@tzi.org> <CAJot-L1e8GegjXjADRQ87tGqnSREoO4bEKLX+kPkZFsQpevGQA@mail.gmail.com> <66be0ffe-a638-45a0-ba05-1585ea02e6bf@www.fastmail.com> <CAJot-L2KO2dOzZQJJeB1kbk6_KTQwUYUsoJOoRt=9maynS1jZg@mail.gmail.com> <121f52be-4747-45f3-ad75-79fa2f693d75@beta.fastmail.com> <E84B4446-5F74-402B-8071-A1164EF0B02C@mit.edu>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Wed, 24 Feb 2021 12:05:14 -0500
Message-ID: <26997.1614186314@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/mDzFZ1FwaWbuGcYU6_sRTIS0e6Q>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Feb 2021 17:05:20 -0000

Justin Richer <jricher@mit.edu> wrote:
    > From a technical standpoint, OAuth’s dynamic client registration lets
    > arbitrary clients talk to an AS, but the trust isn’t there in
    > practice.

As an example of a fail even in a closed ecosystem: neither Google nor
Facebook nor LinkedIn nor .. permit one to login to them with themselves.
Even if we believe that there are business reasons why they wouldn't delegate
to another, the fact is that they don't delegate to themselves.

What's the use case?  I'll give you two:
  1) parent/child
  2) boss/secretary (*)

My kid is subject to Google Classroom.  A great idea, rather poorly implemented.
The parent interface is basically non-existent.  The advice, from *GOOGLE*
(and my school board) is, in order to find out what your child is
doing... have them share their password with you, the parent.  I read this,
and went WTF?  Doesn't that go against all of the authentication security
precepts that Google and others have been telling us?

(*) - yes there are limited abilities to do this within gmail.  But, it
      does not extend throughout the ecosystem.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide