Re: [Txauth] alternative charter writeup

Justin Richer <jricher@mit.edu> Thu, 16 January 2020 20:58 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 287FE12008D for <txauth@ietfa.amsl.com>; Thu, 16 Jan 2020 12:58:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 D5bfnlcF7dWk for <txauth@ietfa.amsl.com>; Thu, 16 Jan 2020 12:58:31 -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 2CC9F120026 for <txauth@ietf.org>; Thu, 16 Jan 2020 12:58:30 -0800 (PST)
Received: from [192.168.1.16] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 00GKwQp7020150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 16 Jan 2020 15:58:27 -0500
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Justin Richer <jricher@mit.edu>
In-Reply-To: <B6D4450B-CE5F-410B-A21D-C494CD4483A6@amazon.com>
Date: Thu, 16 Jan 2020 15:58:26 -0500
Cc: Torsten Lodderstedt <torsten@lodderstedt.net>, "txauth@ietf.org" <txauth@ietf.org>, Dick Hardt <dick.hardt@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5A7FEF06-954E-47B1-B3CE-AD5DE2329B52@mit.edu>
References: <857A822F-E819-443E-8D92-5A5BD682D3AF@mit.edu> <3CC78FFE-8115-4693-8FEF-EC9B9BDDD786@lodderstedt.net> <BFD1E625-BAEB-4367-821B-D75511928E76@mit.edu> <B6D4450B-CE5F-410B-A21D-C494CD4483A6@amazon.com>
To: "Richard Backman, Annabelle" <richanna@amazon.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/MTcd6NeEob9od59OS_U8bPzpfNM>
Subject: Re: [Txauth] alternative charter writeup
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: Thu, 16 Jan 2020 20:58:33 -0000

I think that’s exactly the reason — the case of getting information about the user directly from the TX endpoint is well established. People don’t want to make another round trip just to figure out who’s there, when a lot of time that’s the first thing they care about, and then the’d make the determination of whether to follow other APIs after that. 

So if I can send you a very basic set of authn info from the callback, like an identifier and VoT style login information, then you can figure out if you need to know more about that user or not. But these basic claims do get elevated to the same level as other returned artifacts from the transaction, like the access tokens.

 — Justin

> On Jan 16, 2020, at 2:12 PM, Richard Backman, Annabelle <richanna@amazon.com> wrote:
> 
> The only reason I can think of to single out identity within the charter is if there is some work or feature that is within scope for the working group, but only for identity claims (e.g., returning identity claims from the transaction endpoint). Repeating a question I posed earlier, what is it about identity claims that make them worthy of special consideration?
> 
> – 
> Annabelle Richard Backman
> AWS Identity
> 
> 
> On 1/16/20, 8:51 AM, "Justin Richer" <jricher@mit.edu> wrote:
> 
>    On Jan 16, 2020, at 11:15 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
>> 
>> 
>> 
>>> Am 16.01.2020 um 16:45 schrieb Justin Richer <jricher@mit.edu>:
>>> 
>>> - Approval of identity claims and multiple resources in a single interaction
>> 
>> This sounds a bit incomplete to me. I assume the user would approve „the attestation of identity claims“. I furthermore think the user would approve „access to multiple APIs“. I would prefer API over resource because it is more universal. For example, the protocol could also be used to create resources.
> 
>    Point taken, but this isn’t meant to be an exhaustive list of what it can do, merely the list of things we’re positive we want it to do. I also prefer “API” over “resource”, but concede that “resource” can be a writeable thing too. Even then I’m happy to tweak the language here. 
> 
>     — Justin
>