Re: [Txauth] alternative charter writeup

"Richard Backman, Annabelle" <richanna@amazon.com> Thu, 16 January 2020 19:12 UTC

Return-Path: <prvs=277cd68f8=richanna@amazon.com>
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 79DF2120963 for <txauth@ietfa.amsl.com>; Thu, 16 Jan 2020 11:12:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.8
X-Spam-Level:
X-Spam-Status: No, score=-11.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazon.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 0MXZNAX8RgfP for <txauth@ietfa.amsl.com>; Thu, 16 Jan 2020 11:12:47 -0800 (PST)
Received: from smtp-fw-33001.amazon.com (smtp-fw-33001.amazon.com [207.171.190.10]) (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 CB81D1208CD for <txauth@ietf.org>; Thu, 16 Jan 2020 11:12:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.com; i=@amazon.com; q=dns/txt; s=amazon201209; t=1579201968; x=1610737968; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=OT/2SA/43tPURQ4dJO0TdIBYsnTsnJy9bQVR3joB+IE=; b=UL4LdEm8zHoK6aQ/Pqnx/32J62iViw6gev5A10sSi81NnoqjXWIggvIZ pOeSb2sMgSVxaqefuMyl8ApQe6Mh8hiK+LtD8/mYFauilj1sAx+7dflil 9QOhYX9X4Omb/CLppHARb7JPqbrzVN4vTb9hMbII9VWn+ALWEoCN66shm o=;
IronPort-SDR: pO7rGafAlubgdanSjvIjEoU9RINhrJg1o5u2mHJkVjWGEHwE9Ud2zAsQhN/y8Gn8bV/5kBAIZ8 C9QTWMfYFwyQ==
X-IronPort-AV: E=Sophos;i="5.70,327,1574121600"; d="scan'208";a="20530068"
Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-1d-474bcd9f.us-east-1.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-33001.sea14.amazon.com with ESMTP; 16 Jan 2020 19:12:34 +0000
Received: from EX13MTAUWC001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162]) by email-inbound-relay-1d-474bcd9f.us-east-1.amazon.com (Postfix) with ESMTPS id D5FABA226C; Thu, 16 Jan 2020 19:12:33 +0000 (UTC)
Received: from EX13D11UWC002.ant.amazon.com (10.43.162.174) by EX13MTAUWC001.ant.amazon.com (10.43.162.135) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 16 Jan 2020 19:12:33 +0000
Received: from EX13D11UWC004.ant.amazon.com (10.43.162.101) by EX13D11UWC002.ant.amazon.com (10.43.162.174) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Thu, 16 Jan 2020 19:12:33 +0000
Received: from EX13D11UWC004.ant.amazon.com ([10.43.162.101]) by EX13D11UWC004.ant.amazon.com ([10.43.162.101]) with mapi id 15.00.1367.000; Thu, 16 Jan 2020 19:12:33 +0000
From: "Richard Backman, Annabelle" <richanna@amazon.com>
To: Justin Richer <jricher@mit.edu>, Torsten Lodderstedt <torsten@lodderstedt.net>
CC: "txauth@ietf.org" <txauth@ietf.org>, "rdd@cert.org" <rdd@cert.org>, Benjamin Kaduk <kaduk@mit.edu>, Dick Hardt <dick.hardt@gmail.com>
Thread-Topic: [Txauth] alternative charter writeup
Thread-Index: AQHVx9g9cyOj1MRzqU6+3+Goa7VakafkXaAAgABoEICAA/l4gIAAld0A//+QawCAAI5HAIAALucAgAPVjwCAAAhfAIAAChsA//+hWgA=
Date: Thu, 16 Jan 2020 19:12:33 +0000
Message-ID: <B6D4450B-CE5F-410B-A21D-C494CD4483A6@amazon.com>
References: <857A822F-E819-443E-8D92-5A5BD682D3AF@mit.edu> <3CC78FFE-8115-4693-8FEF-EC9B9BDDD786@lodderstedt.net> <BFD1E625-BAEB-4367-821B-D75511928E76@mit.edu>
In-Reply-To: <BFD1E625-BAEB-4367-821B-D75511928E76@mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1d.0.190908
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.160.8]
Content-Type: text/plain; charset="utf-8"
Content-ID: <90D18082EFF5B94293A0E2C52367CB0F@amazon.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/57HttY9hndIma01GROjj5w-ZFbI>
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 19:12:49 -0000

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