Re: [Rats] Call for charter consensus

Laurence Lundblade <lgl@island-resort.com> Fri, 18 January 2019 18:51 UTC

Return-Path: <lgl@island-resort.com>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 490D81312E7 for <rats@ietfa.amsl.com>; Fri, 18 Jan 2019 10:51:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 g2KOZTLApq6Q for <rats@ietfa.amsl.com>; Fri, 18 Jan 2019 10:51:21 -0800 (PST)
Received: from p3plsmtpa11-08.prod.phx3.secureserver.net (p3plsmtpa11-08.prod.phx3.secureserver.net [68.178.252.109]) (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 BE0371312F3 for <rats@ietf.org>; Fri, 18 Jan 2019 10:51:21 -0800 (PST)
Received: from [192.168.1.82] ([76.192.164.238]) by :SMTPAUTH: with ESMTPSA id kZEcgvWKoMJPGkZEdg1Wxb; Fri, 18 Jan 2019 11:51:19 -0700
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Laurence Lundblade <lgl@island-resort.com>
In-Reply-To: <20190118184219.GL81907@kduck.mit.edu>
Date: Fri, 18 Jan 2019 10:51:18 -0800
Cc: "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>, "rats@ietf.org" <rats@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <87CF924F-3B71-4639-99B7-7E5A7916ABAF@island-resort.com>
References: <6C7E1E60-2507-4B1E-98DB-AB572C239ACD@cisco.com> <B60D5D8B-F434-45CD-9CB6-3C33E1EA91D3@island-resort.com> <20190118184219.GL81907@kduck.mit.edu>
To: Benjamin Kaduk <kaduk@mit.edu>
X-Mailer: Apple Mail (2.3445.9.1)
X-CMAE-Envelope: MS4wfFLqc8ubNR++9fl1hqTIEsNhYVCBBRy7XW099PTi6M7SnEVS7U4gss2gYh39lUnYocz/w75X/KOT/tYrFeHn/l1MrzX5fRTtQGCuzmWt3BjUgph/QRwR bt0thj0LqYNqLKgLJnFbRcS7OzJ7ne9WE1TnRGE8PMateBNQMnQ2/F84L93O3F23xAPgKy4lJ2wQH70z8kPqjXWGpPQhzNTiC+Wlqwor8O+MqK6BlbEzTGyE
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/9LjkguV_8HGZvvvnPuJPgCb4FXk>
Subject: Re: [Rats] Call for charter consensus
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote Attestation Procedures <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Jan 2019 18:51:25 -0000

On Jan 18, 2019, at 10:42 AM, Benjamin Kaduk <kaduk@mit.edu> wrote:
> 
> Hi Laurence,
> 
> On Thu, Jan 17, 2019 at 10:17:30PM -0800, Laurence Lundblade wrote:
>> Hi Nancy,
>> 
>> The charter lists some types of claims/assertions in the introduction.  That list does not include things like GPS Location, public part of key pairs generated on device, enforced conditions for use of that key, identity of an app requesting a token, and app/user defined claims. Most of these types of claims have been implemented already either by FIDO, Android attestation or other products.  A vision here is that Android or other types of apps prove who they are to the server and pass a lot of data to the relying party via the token, often as input to authentication and financial transaction risk engines. 
>> 
>> 
>> I assume it will continue to hold that anyone can add any proprietary claim they want, but a lot of the types of claims/assertions I just mentioned would be valuable as a standard. Some will be relatively easy to standardize. Some may not be. My first thought is that some of the easy obvious ones should be in scope, but we need to draw a line somewhere so we’re not creating claims forever. Not sure where that line is.
> 
> Those are good points.  I think it's probably premature to wire down a
> specific list of claims at charter time, so the list in the introduction
> should be treated as exemplary rather than normative, as is typical for
> charter introductions.  Perhaps we want to add another bullet "other
> factors that could influence trust decisions" to make that more clear.


That definitely works for me.

LL