Re: [Txauth] TxAuth Charter (Take 3.5)

Justin Richer <jricher@mit.edu> Wed, 29 January 2020 08:41 UTC

Return-Path: <jricher@mit.edu>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0B79120241 for <txauth@ietfa.amsl.com>; Wed, 29 Jan 2020 00:41:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 w77-phjvbk_C for <txauth@ietfa.amsl.com>; Wed, 29 Jan 2020 00:41:19 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 DB06912022D for <txauth@ietf.org>; Wed, 29 Jan 2020 00:41:18 -0800 (PST)
Received: from [10.38.98.116] ([83.219.75.72]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00T8fB11006615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 29 Jan 2020 03:41:13 -0500
From: Justin Richer <jricher@mit.edu>
Message-Id: <73C0643D-F020-4354-9591-EBB05D161669@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_AD850734-7B70-4E97-91FE-F75F51ADF6D7"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 29 Jan 2020 09:41:04 +0100
In-Reply-To: <7ED74044-CA39-437C-8844-1C16DB3B1EC7@lodderstedt.net>
Cc: Dick Hardt <dick.hardt@gmail.com>, "rdd@cert.org" <rdd@cert.org>, "txauth@ietf.org" <txauth@ietf.org>
To: Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org>
References: <CAD9ie-topDftG2XOMO0ri0iXQiJGrhH-9-nVndPC238e=EOskg@mail.gmail.com> <7ED74044-CA39-437C-8844-1C16DB3B1EC7@lodderstedt.net>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/1X2bvZdso6b1_ubP4xDICeyScK8>
Subject: Re: [Txauth] TxAuth Charter (Take 3.5)
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jan 2020 08:41:21 -0000

I completely agree that modularity of the documents is key, but keep in mind that the charter specifies only the total end result and not how the documents are split up. How we slice things is a key decision that the working group needs to make. I don’t think we’ll see everything in in a single document, but I do think we’ll see a lot more in a “core” document than is in OAuth 2 today. 

We aren’t setting out to just mash together OAuth 2 and all of its extensions, including OIDC — anything like that would clearly be suited for the OAuth WG. 

I think that if we’re careful and deliberate, especially if we’re not dragging legacy decisions “just because”, then we have a chance to make things really work here without getting overly complex. Much of OIDC’s complexity stems from it adding functionality to OAuth 2 or overcoming limitations in OAuth 2. A lot of that can go away if we are building these aspects together from the start. 

 — Justin

> On Jan 29, 2020, at 8:04 AM, Torsten Lodderstedt <torsten=40lodderstedt.net@dmarc.ietf.org> wrote:
> 
> 
> 
>> Am 29.01.2020 um 07:01 schrieb Dick Hardt <dick.hardt@gmail.com>:
>> 
>> 
>> 
>> 
>> On Tue, Jan 28, 2020 at 9:09 PM Torsten Lodderstedt <torsten@lodderstedt.net <mailto:torsten@lodderstedt..net>> wrote:
>> 
>> 
>> > Am 29.01.2020 um 02:13 schrieb Dick Hardt <dick.hardt@gmail.com <mailto:dick.hardt@gmail.com>>:
>> > 
>> > All identity claim use cases. A set of these are solved by OpenID Connect, which is an extension to OAuth 2.0. TxAuth would also be a superset of OpenID Connect in addition to OAuth.
>> 
>> Don’t you think this would make TxAuth a bit complicated? What would be the benefit?
>> 
>> Not any more than today, as many consumer IdPs have both in the same flows, and that is what is in the proposed charter. 
>> 
>> Having the information all in one document would make it simpler to implement and understand.
>> 
> 
> I doubt. If i calculate the size of all relevant oauth specs + all relevant openid connect specs (including verified claims), that will most likely be a multi 100 pages spec that few people will fully understand and be able to review/contribute to and fully & correctly implement.
> 
> Modularity and extensibility is key to success of this initiative.
> 
>> Did you have chance to look at XAuth Torsten?
> 
> Not in detail.
> 
>> 
>> -- 
>> Txauth mailing list
>> Txauth@ietf.org <mailto:Txauth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> -- 
> Txauth mailing list
> Txauth@ietf.org <mailto:Txauth@ietf.org>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>