Re: [Rats] Call for adoption (after draft rename) for Yang module draft

Henk Birkholz <henk.birkholz@sit.fraunhofer.de> Wed, 13 November 2019 11:25 UTC

Return-Path: <henk.birkholz@sit.fraunhofer.de>
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 96FBE120013 for <rats@ietfa.amsl.com>; Wed, 13 Nov 2019 03:25:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-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 89u6XMG7ouHu for <rats@ietfa.amsl.com>; Wed, 13 Nov 2019 03:25:30 -0800 (PST)
Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) (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 7F36912003F for <rats@ietf.org>; Wed, 13 Nov 2019 03:25:30 -0800 (PST)
Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.15.2/8.15.2/Debian-10) with ESMTPS id xADBPRpc018819 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Wed, 13 Nov 2019 12:25:28 +0100
Received: from [192.168.16.50] (79.234.112.245) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.468.0; Wed, 13 Nov 2019 12:25:22 +0100
To: "Schönwälder, Jürgen" <J.Schoenwaelder@jacobs-university.de>, Michael Richardson <mcr+ietf@sandelman.ca>
CC: "rats@ietf.org" <rats@ietf.org>, Laurence Lundblade <lgl@island-resort.com>
References: <ce5f8206-74dc-36bb-0093-a93045d5c67f@sit.fraunhofer.de> <0A7E3A4F-8534-4E98-BCB7-1454E07699F4@island-resort.com> <C3AE2645-49C8-4313-BCED-02FEB576B614@cisco.com> <1C8A1884-A37D-45E3-8C11-2FC5A083B245@island-resort.com> <ba12a686-1b34-21a3-388c-bbe01c01a408@sandelman.ca> <4A83CDF5-D29F-4279-8B03-E9D23299EB53@island-resort.com> <0C6940B0-E93F-4274-9D00-DEC4119B8F69@island-resort.com> <85c7c287-48e3-83e7-900e-8e50ce43eba3@sandelman.ca> <147FEACA-56F0-43A0-8F25-639D0613E4BD@island-resort.com> <22fd43c8-7d6e-2dd8-c29a-aa86ee894ff6@sandelman.ca> <20191113111416.22xikah475zyxdro@anna.jacobs.jacobs-university.de>
From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Message-ID: <b788928f-b95b-9bed-954c-0fc8cfd46119@sit.fraunhofer.de>
Date: Wed, 13 Nov 2019 12:25:21 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <20191113111416.22xikah475zyxdro@anna.jacobs.jacobs-university.de>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [79.234.112.245]
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/_D5SIr7T-ijwGBF7jzvQiaHZ7IU>
Subject: Re: [Rats] Call for adoption (after draft rename) for Yang module draft
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: Wed, 13 Nov 2019 11:25:33 -0000

One reason for this - and I tried to express that carefully - is that 
just using the word "token" could be very confusing. We are using 
"Claim" as a synonym to "Assertion" at the moment. Outside of the IETF 
that makes a lot of sense. Inside the IETF, we still have to be a bit 
careful here, as "Claim" is well defined in Web Tokens - and it is a 
data model term (basically: a specific key value representation).

An EAT is a CWT (or JWT, not the point). So both are Claim sets that 
compose tokens. The architecture is intended to be representation (I am 
using this term to dance around the sanity rending 
serialization/encoding words, and to spare Rich some of the pain) 
agnostic. Claims in the architecture are therefore representation 
agnostic, too. Claims in tokens - by RFC definition - are not.

I am not a super big fan of this compromise, but it found consensus, 
removed a blocker, and we were able to progress.

Viele Grüße,

Henk

On 13.11.19 12:14, Schönwälder, Jürgen wrote:
> While there is a lot of talk here about different kinds of "token"
> recently, I note that this term is not defined in
> draft-birkholz-rats-architecture-03.txt nor in
> draft-thaler-rats-architecture-01.txt.