Re: [Rats] Profile identifier (was Re: EAT Profiles)
"Smith, Ned" <ned.smith@intel.com> Mon, 26 September 2022 18:54 UTC
Return-Path: <ned.smith@intel.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 50A8BC14CF05 for <rats@ietfa.amsl.com>; Mon, 26 Sep 2022 11:54:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.975
X-Spam-Level:
X-Spam-Status: No, score=-4.975 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.571, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=intel.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnqQowl_TtEX for <rats@ietfa.amsl.com>; Mon, 26 Sep 2022 11:53:59 -0700 (PDT)
Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) (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 4B6F7C14F72D for <rats@ietf.org>; Mon, 26 Sep 2022 11:53:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1664218439; x=1695754439; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=IPy/BUB+bHUSsvqpbZHNf7aq38yf6/dHegzOHRznqZs=; b=Xf+AzTZ1ZZIudMWJrmIAKLpBMeCzRNYtxk+kUoreWExXUFdfWxjEFIco 7H7lY/cBjJSp0+1TU9lFM8N9ULEHwP+85aHjieIxq+h6QM/Rti0RLczAb Ss97rnLHHt6VsjTE9sFrWpVH9OpLx55Qq9umu639EhXtGFs3ZClJB5uR5 p6ToR/WsU4GRxYz2xt+ewr3Kzli4LBN6VVDuFkYVaxjzFs1oFT/rFOOHC Pf1+BLY66lcDsOf03DScGXjNmL5gjJhb/fjFLBqPHw7+AenOanzjzGLHt biMqDMiMnL3L8/NlhKPDFD1FpkOVIVsXR4BYVhZNcXoUSlFIvTwntC0Ye Q==;
X-IronPort-AV: E=McAfee;i="6500,9779,10482"; a="302018368"
X-IronPort-AV: E=Sophos;i="5.93,346,1654585200"; d="scan'208";a="302018368"
Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 26 Sep 2022 11:53:57 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=McAfee;i="6500,9779,10482"; a="746729109"
X-IronPort-AV: E=Sophos;i="5.93,346,1654585200"; d="scan'208";a="746729109"
Received: from fmsmsx602.amr.corp.intel.com ([10.18.126.82]) by orsmga004.jf.intel.com with ESMTP; 26 Sep 2022 11:53:55 -0700
Received: from fmsmsx609.amr.corp.intel.com (10.18.126.89) by fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Mon, 26 Sep 2022 11:53:55 -0700
Received: from fmsmsx608.amr.corp.intel.com (10.18.126.88) by fmsmsx609.amr.corp.intel.com (10.18.126.89) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Mon, 26 Sep 2022 11:53:54 -0700
Received: from FMSEDG603.ED.cps.intel.com (10.1.192.133) by fmsmsx608.amr.corp.intel.com (10.18.126.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31 via Frontend Transport; Mon, 26 Sep 2022 11:53:54 -0700
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (104.47.58.100) by edgegateway.intel.com (192.55.55.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.31; Mon, 26 Sep 2022 11:53:54 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=c5SSOTCbJQlYQrH1qwoHmVmn8uAXtyXyLkgqxJ6bfl/PQY74qTcc1DkfYBeGVvW3oy+CIIuY8fgG0XXFx8b86BXS/Yswcn2TGbTyuSMzT2IwYWHJtgzpEvcLMvpTXT++4kq6q6Kz+dSJfNKiyEnsqvFiiF/rAkE0PllcyPBLjVIeuhddmfM/PZCAOSd/rOl5DDv1XrHTiFDUW3tbqFIbSnPSzRMxQznsU8mj1l6UXxOPkHCGe2s+BFS9XE0GOIVXuTdFiFodVtzXJ8HMA57AZKD1RhRPw0IZKlcV2PfdFYCBGRaquKhIq0MDpHATw//sSa7VCmSAlJy/suUHYsYy3g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=IPy/BUB+bHUSsvqpbZHNf7aq38yf6/dHegzOHRznqZs=; b=If+YPTCITlLdOqyDVnlVKze1aiukC1CkhW1FzlvpGzCqs1e350S3EK3c2wol7ZL7Lc1y1VEeJgKjhp7qabP+OI4H/CUKcEh/KlQwbT2Cy5OV+MLCPbAnrWTPJeUkBhciqLx9v8q7AE+/MxKeRd7XowsjTsPI1YiG6oeIGsVdHqG4crRJLckfaEJlZH0la3heUGerHyPzRW+XJfCxMtbFIpts1e9EqJlpLs+/AB14ls+gAVrjTbQG63k5Ms53kOJyoH3SNZU08zE4Bw2AQxsRS8g2fR/SfqlIS0AzCXccByfvKXcX9A3AbV5OY8seA5/2+0LqawlXA1StdpoDBPqDHA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none
Received: from CO1PR11MB5169.namprd11.prod.outlook.com (2603:10b6:303:95::19) by BL1PR11MB5511.namprd11.prod.outlook.com (2603:10b6:208:317::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5654.26; Mon, 26 Sep 2022 18:53:52 +0000
Received: from CO1PR11MB5169.namprd11.prod.outlook.com ([fe80::7056:c22:10bd:3da]) by CO1PR11MB5169.namprd11.prod.outlook.com ([fe80::7056:c22:10bd:3da%5]) with mapi id 15.20.5632.021; Mon, 26 Sep 2022 18:53:52 +0000
From: "Smith, Ned" <ned.smith@intel.com>
To: Laurence Lundblade <lgl@island-resort.com>
CC: Giridhar Mandyam <mandyam@qti.qualcomm.com>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, Michael Richardson <mcr+ietf@sandelman.ca>, "rats@ietf.org" <rats@ietf.org>
Thread-Topic: [Rats] Profile identifier (was Re: EAT Profiles)
Thread-Index: AQHYzaTCcYlnkCwomE+WobaQOUjYAa3p502AgAACjoCAAAFwAIAAAuKAgAABxYCAAAQ5AIAAFOyA//+VHgCAAI0/AIAHdoyA
Date: Mon, 26 Sep 2022 18:53:52 +0000
Message-ID: <BA09C543-4ECA-4758-A919-268E66DA766A@intel.com>
References: <71934.1663019954@dooku> <DBBPR08MB5915AC23726BF997EB9E44C4FA489@DBBPR08MB5915.eurprd08.prod.outlook.com> <19805.1663344806@dooku> <AS8PR08MB5911DB2FE9608541698983B0FA4D9@AS8PR08MB5911.eurprd08.prod.outlook.com> <ab4312d3-c35f-5e72-9658-ca88ba3523c2@sit.fraunhofer.de> <CAObGJnNjuTT+QqnSpp1abrX-1hHGzCkVkzrM8GArPs8sDu=W+g@mail.gmail.com> <f9f289ad-5f36-b781-7502-219778148491@sit.fraunhofer.de> <885ABB6E-FD98-45E2-84BE-5A3A3C37D3F8@island-resort.com> <ABB7105F-6B5F-47AA-886C-8490024C3D47@intel.com> <46605.1663756035@dooku> <SJ0PR02MB835323B33E4FFA04DB96FECB814F9@SJ0PR02MB8353.namprd02.prod.outlook.com> <2f371cdb-38b1-f042-27e7-86afb91a38a2@sit.fraunhofer.de> <SJ0PR02MB835310DBD2C9CE9B3EB7424B814F9@SJ0PR02MB8353.namprd02.prod.outlook.com> <e251b4bc-7757-a681-f408-4309942fad53@sit.fraunhofer.de> <SJ0PR02MB8353435EAD5F0D7727DBD840814F9@SJ0PR02MB8353.namprd02.prod.outlook.com> <9dc8f783-49f1-ef9b-14ba-c9f9b775e5cd@sit.fraunhofer.de> <SJ0PR02MB83534E072B04BF8DF4BAA284814F9@SJ0PR02MB8353.namprd02.prod.outlook.com> <4B5A2D51-7F18-43E6-8322-FE93CD4C30B5@intel.com> <16C27DE9-2187-471C-8028-76653026C86B@island-resort.com>
In-Reply-To: <16C27DE9-2187-471C-8028-76653026C86B@island-resort.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.65.22091101
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: CO1PR11MB5169:EE_|BL1PR11MB5511:EE_
x-ms-office365-filtering-correlation-id: 3b2acc93-128d-4f6d-2ced-08da9ff074c5
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: kpezohFzgMiRP8F/6cNBVLQm2d06A4uCRISzqRe1eLBRcyrRJ3hd8uESyxDZCbaKLdgEk/HcJkoyxcHGqoVebhIU98pQHi9eo2q8np5xTTn444+sAvzgvqlxsHStyc6E+1fiTO1QhUI/8W3Bf+df1471ruV4b98ljxgjR3T6e1r7lN1697aVYBJRXrdBaEDC17r95bja/HkpxiUl3f6ipXpe5Ss7M8rQ9Sa+R9sdV920+qN/ZtM+axx6f/l0wBWpH6BumKVtJIMMKiWgWduf+T0qvx+lbnuGZ9YMGly4QLclA5rEs+XNRUmK1khV2LeZL54h+UW5pi2QT/SlNYh9rswJQRUbfCEdww4HeN2y+AczaKZKvg4sjENteUR+beUMwHY0HqJhomU1q3M0l1BsP0TyRMq30cQlYSa8xQ3GLhv8FOo34Mky1R2RHLbtjuhrKjEb1CRjC5WgB0N9M/Em74DkAstcpM2Scup+keeAqM/Bx0RsgF/mmDLbrKAFreB7H2jhiesE1gT662i1Jj+ggY8IkABPaa3m9mkb62ON8bbH3Euey3U6jFqgvBOGiAbq1Y8xzt0/npiGKZt+C9Mm/eUGm4zNsaMl/RQ7jWn3hoKGT35XodVx9Bz878gCxrS1QIfWuR+BpKrdy/MjbtOebDejLmwfzwZkCRS5+nr3NOwPfSrBeKIEbl70NJgYpWczxiccYpC9ooagCixxFICECfy6OxDIPfwSMarq1pZn4LosmxRmuPHR7VWuufztgGBachXGz0kY4kiHAqDGgpHuB94+zs5JaOU8lJTttUf01nukXzUdGQ+DCGifG4WV/TkZL8YcrazRLeL0tGphe7fWkq+mg6MIIMySadHGSLJfWPQ=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR11MB5169.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230022)(136003)(376002)(39860400002)(396003)(366004)(346002)(451199015)(54906003)(6512007)(26005)(5660300002)(478600001)(316002)(6916009)(66946007)(76116006)(91956017)(71200400001)(6486002)(6506007)(8936002)(41300700001)(53546011)(30864003)(2906002)(83380400001)(38100700002)(186003)(33656002)(36756003)(86362001)(4326008)(64756008)(966005)(66446008)(66556008)(66476007)(8676002)(82960400001)(2616005)(122000001)(38070700005)(45980500001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: /kFIKQ+CFafx8GYz3SseuQfzg/GD7kAiqF9R0f52YhQDkWT1sO81E5TvJr1BpSh4zbcDKHGHQ4/q5+FVgLpZUaqJU7PT9yjgqYROQtylwZPjVZ8SUt0WZiPQyOMiTJhuq4uzgWYcDt0q95vJ73bBKNmcQEmQJz8l2IpCsPdK4qGIHWIFYkPJtdxDBW+X5TVuHkSiuI2L5VXSaxZmwAu4jxx+i/n7G9oYV8G9ANZ/ESd2D0obELsTe5ZHaVTooLE1GImSSiaeAOq3W2PxjVnXXhDxWYNOkRhYeE2pq2+ZoCsw1YOVepaIAxZvwGe9eKui5V3bQVF1uu/Dd2VD3A+Ydj6tvrS7ZflXrEYaY0KEp4lD2bySnRseyhyShpTIHyNaflKS6H5yKRVgiJh7GJFYhjhqbgNOYXi3cU0vxFjSVQ3wmgZdARNy+X3dK29Qf0Eur8trl+696hjoXb7QTrV0gkhiFzzaFgup4pxyjZGyGlVo1FMY/LakE43/m+00TaskKxwDOiFbNDnHvJnTI4RS0Y5/8aMxUkwPOmz237RVjByntEFYHkmVRlzeBbD2R74t7BRAop4X7LueMhbF2Sv+dgojr8VEhN0H72k1sqX9Hu6PSzCy+TRoR18eaXf9zfzksM15t+gnUiSvblxsUpmyDyc7pdbWAL2O+/MRDUXg5pkhdDoxekUY8N0iIYVNKwxZoq0rTzJ4diyXqC0W1ryorYLSIvbWzh8an9KnfY5lrzLgSrYeDE/f0lAGdRz6bCffcGHnUR/tpmFpiH78eA1YpXzrCElgf08KQeiK4DJuPmV2oR3OyeLWAEPplMwbVdcAZhCLh1tB9Xmw/lk1fFO/hVI7+x3lPafCalGX5fICvVq4JrJZpGcStNEGfRIc6e5DLFelesPs4x5ZuvC66nog+RbSplsLvHNaBrgUZpw5m5C/XTkNTwSjhd7oP5n//NhowKf/66lPiKF1t6czb0YWjhlGxURk845VaccA0rt1MTEzaaSgLyFTSCxFlMNjop7kDDgXt0P6iDdd8Nnhhl+eteaiR5iHlqQrYIwbpa9L/YdtnZ5DQS2bFz5rx3qZao2fScilLlMD15S74/qXqu3Z1ogPkWzJX0Jk1JPvmYovjgsMEHtOwYlL6EcfQCijHkK/JakW51+O3tX/tsy4dQFdCZo6O4DyC3dSeE07mcIKmdU+2mEbQJMANndxfTK2WyP9a1fMaz42wRvrCF7RqwOwAipdAimlZsHZKEGONRwHx5olPZe+2EgQAeC8P6Nq6ipRPPByF/aFZLwTGc8y1yNunFmWcwMc7ZZBYKOJMfDF0S+fLu8JFZQdXFcjiZ3HiMmbE/ILnq1uee4ekYAFoCz/v8K3EBbEhSR0lWXyhiZr6z3S8M0Rhuxj56HtcJeaOmuyIwEttoj6pzOSiTWNhNv83RDn4ran7AYkGzxUj3ivbPbCywa5IezMGxZONUTU7otTlMAGebd7FSZf+amBNUCd4dHkga7uyCM77DT2tcHfnsMSYnMJr+ZDrJMHuFjQrVQRDzF+PaUZFPnUzqr/McZZ0sZafs1dWRnevpbH/dl4+2r++NHCcz/ia6tMlTaR6Vxu
Content-Type: text/plain; charset="utf-8"
Content-ID: <5B9A2D94FF5C71409A19D60DE77FD5D8@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB5169.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3b2acc93-128d-4f6d-2ced-08da9ff074c5
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Sep 2022 18:53:52.6080 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: nVpSUC1pBTYUghRNTYOzqtYmOVeOjNiLeNTj2mqeVuT2c77x0fJtnYMhwLnbyWFLDKs7tlZhPHM1FQmrNjbphw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR11MB5511
X-OriginatorOrg: intel.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/Lw8eeIQdhGKl3Ec-5epRvZqRzEw>
Subject: Re: [Rats] Profile identifier (was Re: EAT Profiles)
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.39
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: Mon, 26 Sep 2022 18:54:04 -0000
See inline [nms] On 9/21/22, 10:56 AM, "RATS on behalf of Laurence Lundblade" <rats-bounces@ietf.org on behalf of lgl@island-resort.com> wrote: This is how I think the profile id works today and should work as an integer too. The profile definition can be anything — full IETF standard or no standard at all, top secret or public, proprietary or open standard, Chinese or Martian, written down or not written down, expert reviewed or not. It has to be like this to accommodate use cases. This is what it is for the current profile identifier. For example, it is OK for a Chinese military computer science genius to register profile X for a black box EAT implementation he created and tells no one about (if you don’t like non-standard, private, undocumented profiles, don’t use them). The only point of the profile identifier is to be globally unique so some one else doesn’t use the same identifier for something different. The OID and URI spaces are very large and are coordinated so they work great, except they are a bit large on the wire. Main option for me: - A new IANA registry - A first-come first-served number kept unique by increasing monotonically - The name of the entity registering the number - An optional URI for a document - An optional description - Some throttle to prevent mass registration of millions that consumes the whole space - Possibly ranges for standard action, private, proprietary use... - Little to no expert review (it’s just a number registration, not profile quality control) - Typically 3 bytes on the wire We can also keep the OID and URI forms adding integer as another option. We should say that all receivers of EAT MUST handle all three forms and that creators of EATs can use what ever form they want so there is no interop issue. [nms] The corim schema defines it as OID or URI. Another option is to just have the integer and remove OID and URI. That is simpler for the EAT receiver because they won’t be required to decode multiple forms. [nms] I don't think it's necessarily simpler for large organizations that rely on internal OID arcs for distributing responsibility for profile ID assignments. Something based on a PEN could be possible, but would be fourth form. PEN by itself is not enough because one org needs to be able to create multiple profiles. It doesn’t seem worthwhile to me. [nms] PEN could be a hybrid of OID + int No matter what, the EAT document has to change because the profile identifier is not extensible. We really don’t want it extensible either. It would also be really awkward for the reader for this to be elsewhere too. I think this is best handled in the EAT document if we’re going to do it. [nms] +1 that non-extensible helps minimize the need for profiles that define which profile-ID methods are permitted (circularity?). Philosophically though, if "The profile definition can be anything" then that points to profile IDs as something that should be extensible - doesn't it? Agreed that use of EAT profiles does not require using an EAT profile identifier. You might know a particular profile is in effect implicitly and/or through some other means. For example, when EAT is used in the FOO protocol, it is always the BAR profile. [nms] But to achieve interoperability based on profiles, the first step for a parser is to identify the profile. If the format of the profile ID is changing, then the parsers have to change. Use of a registry implies the profile ID format doesn't change since such a change would require a new or changed registry. I'd like to see the profile ID resolved by a small number of profile identifier formats that isn't extensible and consensus that we don't need another format later. I think that means there should be a registry-less option (e.g., OID, UEID etc) and if a registry option is desired, the details of the identifier format (preferably one) - e.g., int only or PEN + int. LL > On Sep 21, 2022, at 9:30 AM, Smith, Ned <ned.smith@intel.com> wrote: > > I agree that lack of clarity around profiles should not be a blocker for EAT draft moving forward. But capturing issues surrounding profiles is important IMO as these questions will come up again. > > Responding to Henk's original question below but restated here: > " >> are you talking about the values of the profile claim (I am assuming numbers for now) to be registered in an IANA registry or are you talking about new claims defined by a profile specification to be registered in the IANA CBOR Web Token (CWT) Claims registry? I am really not sure anymore." > > It wasn't (isn't) clear to me which IANA registry is most appropriate for registering profiles. It could be reasonable that a new IANA registry is created for that purpose. This thread also observes that there isn't necessarily a need to register a profile as there could be other ways to publish profile existence and allowing vendors flexibility to use a PEN and manage profiles locally. > > It is still ambiguous to me what value is realized by placing a profile ID on a registry (given the properties of profile lifecycle are adhered to). > > -Ned > > > On 9/21/22, 8:53 AM, "Giridhar Mandyam" <mandyam@qti.qualcomm.com> wrote: > >> While it is not necessary to register a profile in a registry to achieve the "rough consensus and running code" goal, that should not stop us establish and use an IANA "EAT Profile" registry, right? (specification required + expert review) > > In my opinion, the establishment of such a registry should not be a blocker to moving the EAT spec forward. If there are interested persons who feel a profile registry is an absolute necessity, then they could put out an I.-D. that establishes such a registry along with the mechanics for proposing profiles and administering the registry. > > I personally feel the value of profiles is not solely in the unique claim value, but the CBOR canonicalization that the profile defines. EAT in this regards inherits the application-specific COSE considerations (https://datatracker.ietf.org/doc/html/rfc8152#section-15). > > -Giri > > -----Original Message----- > From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de> > Sent: Wednesday, September 21, 2022 7:38 AM > To: Giridhar Mandyam <mandyam@qti.qualcomm.com>; Michael Richardson <mcr+ietf@sandelman.ca>; Smith, Ned <ned.smith@intel.com>; rats@ietf.org > Subject: Re: [Rats] Profile identifier (was Re: EAT Profiles) > > WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. > > Hi Giri, > > the ACE profile example is giving me a lot of more context! And the approach seems to be fine. An EAT analog could be: > > The claims defined in the EAT framework (including the profile claim), then could simply be registered in the IANA CBOR Web Token (CWT) Claims registry and profiles making use of the EAT framework would be registered in an IANA "EAT Profile" registry, analogous to https://www.rfc-editor.org/rfc/rfc9200.html#name-ace-profiles > > While it is not necessary to register a profile in a registry to achieve the "rough consensus and running code" goal, that should not stop us establish and use an IANA "EAT Profile" registry, right? (specification required + expert review) > > Viele Grüße, > > Henk > > On 21.09.22 16:22, Giridhar Mandyam wrote: >>> So "The EAT Framework" document could come with both a definition of the profile claim for the IANA CBOR Web Token (CWT) Claims registry, as well as... a profile '0' (the first set of Claims that will be included in the final EAT framework document) for an IANA EAT Profile registry? >> >> I did not say the above. >> >> Let me try again. It is not necessary to have an "IANA EAT Profile registry". The FIDO example demonstrates that this it is possible to deliver "running code" without it. The CWT claims registry is sufficient. >> >> BTW, RFC 9200 is the precedent in my opinion. https://www.rfc-editor.org/rfc/rfc9200.html#name-ace-profiles does not require the creation of a new IANA ACE-Profile registry either as far as I can tell. The reservation of the CWT claim appears to have been sufficient. >> >> -Giri >> >> -----Original Message----- >> From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de> >> Sent: Wednesday, September 21, 2022 7:16 AM >> To: Giridhar Mandyam <mandyam@qti.qualcomm.com>; Michael Richardson >> <mcr+ietf@sandelman.ca>; Smith, Ned <ned.smith@intel.com>; >> rats@ietf.org >> Subject: Re: [Rats] Profile identifier (was Re: EAT Profiles) >> >> WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. >> >> Hi Giri, >> >> thanks for clarifying. So "The EAT Framework" document could come with both a definition of the profile claim for the IANA CBOR Web Token (CWT) Claims registry, as well as... a profile '0' (the first set of Claims that will be included in the final EAT framework document) for an IANA EAT Profile registry? >> >> Viele Grüße, >> >> Henk >> >> On 21.09.22 16:06, Giridhar Mandyam wrote: >>> Both. >>> >>> In the case of FIDO, the profile claim value was not registered. That did not stop us from achieving the "rough consensus and running code" goal. >>> >>> -Giri >>> >>> -----Original Message----- >>> From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de> >>> Sent: Wednesday, September 21, 2022 7:01 AM >>> To: Giridhar Mandyam <mandyam@qti.qualcomm.com>; Michael Richardson >>> <mcr+ietf@sandelman.ca>; Smith, Ned <ned.smith@intel.com>; >>> rats@ietf.org >>> Subject: Re: [Rats] Profile identifier (was Re: EAT Profiles) >>> >>> WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. >>> >>> Hi Ned, Michael, Giri, >>> >>> are you talking about the values of the profile claim (I am assuming numbers for now) to be registered in an IANA registry or are you talking about new claims defined by a profile specification to be registered in the IANA CBOR Web Token (CWT) Claims registry? I am really not sure anymore. >>> >>> Viele Grüße, >>> >>> Henk >>> >>> On 21.09.22 15:51, Giridhar Mandyam wrote: >>>> This was not required for the FIDO implementation of EAT. As per https://www.iana.org/assignments/cwt/cwt.xhtml, the FIDO EAT claims have been registered and the profile has been verified in interop events. The profile itself was not registered. >>>> >>>>> The IANA registry would point to some RFC that described the semantics. >>>> >>>> Why only RFC's? Are other standards body documents not suitable? At least for FIDO, this didn't seem to be a requirement for IANA registry. >>>> >>>> -Giri >>>> >>>> -----Original Message----- >>>> From: RATS <rats-bounces@ietf.org> On Behalf Of Michael Richardson >>>> Sent: Wednesday, September 21, 2022 3:27 AM >>>> To: Smith, Ned <ned.smith@intel.com>; rats@ietf.org >>>> Subject: Re: [Rats] Profile identifier (was Re: EAT Profiles) >>>> >>>> WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros. >>>> >>>> Smith, Ned <ned.smith@intel.com> wrote: >>>>> @Laurence Lundblade<mailto:lgl@island-resort.com> What semantics are >>>>> associated with a profile that appears on an IANA registry? >>>> >>>> The IANA registry would point to some RFC that described the semantics. >>>> >>>> -- >>>> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works >>>> -= IPv6 IoT consulting =- >>>> >>>> >>>> >>>> _______________________________________________ >>>> RATS mailing list >>>> RATS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rats > > _______________________________________________ > RATS mailing list > RATS@ietf.org > https://www.ietf.org/mailman/listinfo/rats _______________________________________________ RATS mailing list RATS@ietf.org https://www.ietf.org/mailman/listinfo/rats
- [Rats] EAT Profiles Michael Richardson
- Re: [Rats] EAT Profiles Thomas Fossati
- Re: [Rats] EAT Profiles Laurence Lundblade
- Re: [Rats] EAT Profiles Laurence Lundblade
- Re: [Rats] EAT Profiles Smith, Ned
- Re: [Rats] EAT Profiles Michael Richardson
- Re: [Rats] EAT Profiles Michael Richardson
- Re: [Rats] EAT Profiles Michael Richardson
- Re: [Rats] EAT Profiles Hannes Tschofenig
- Re: [Rats] EAT Profiles Hannes Tschofenig
- Re: [Rats] EAT Profiles Thomas Fossati
- Re: [Rats] EAT Profiles Michael Richardson
- Re: [Rats] EAT Profiles Laurence Lundblade
- [Rats] EAT Claim Constraining (was Re: EAT Profil… Laurence Lundblade
- [Rats] Why variability is needed (Re: EAT Profile… Laurence Lundblade
- Re: [Rats] EAT Profiles Smith, Ned
- Re: [Rats] Why variability is needed (Re: EAT Pro… Michael Richardson
- Re: [Rats] EAT Profiles Michael Richardson
- Re: [Rats] EAT Profiles Hannes Tschofenig
- Re: [Rats] EAT Profiles Henk Birkholz
- Re: [Rats] EAT Profiles Michael Richardson
- Re: [Rats] EAT Profiles Hannes Tschofenig
- Re: [Rats] EAT Profiles Carl Wallace
- Re: [Rats] EAT Profiles Thomas Fossati
- Re: [Rats] EAT Profiles Thomas Fossati
- Re: [Rats] EAT Profiles Smith, Ned
- Re: [Rats] EAT Profiles Michael Richardson
- Re: [Rats] EAT Profiles Henk Birkholz
- Re: [Rats] EAT Profiles Carl Wallace
- Re: [Rats] Why variability is needed (Re: EAT Pro… Smith, Ned
- Re: [Rats] EAT Profiles Thomas Fossati
- [Rats] Profile identifier (was Re: EAT Profiles) Laurence Lundblade
- Re: [Rats] Profile identifier (was Re: EAT Profil… Smith, Ned
- Re: [Rats] Profile identifier (was Re: EAT Profil… Russ Housley
- Re: [Rats] Profile identifier (was Re: EAT Profil… Michael Richardson
- Re: [Rats] Profile identifier (was Re: EAT Profil… Michael Richardson
- Re: [Rats] Profile identifier (was Re: EAT Profil… Giridhar Mandyam
- Re: [Rats] Profile identifier (was Re: EAT Profil… Henk Birkholz
- Re: [Rats] Profile identifier (was Re: EAT Profil… Giridhar Mandyam
- Re: [Rats] Profile identifier (was Re: EAT Profil… Henk Birkholz
- Re: [Rats] Profile identifier (was Re: EAT Profil… Giridhar Mandyam
- Re: [Rats] Profile identifier (was Re: EAT Profil… Henk Birkholz
- Re: [Rats] Profile identifier (was Re: EAT Profil… Giridhar Mandyam
- Re: [Rats] Profile identifier (was Re: EAT Profil… Smith, Ned
- Re: [Rats] Profile identifier (was Re: EAT Profil… Laurence Lundblade
- Re: [Rats] Profile identifier (was Re: EAT Profil… Michael Richardson
- Re: [Rats] Profile identifier (was Re: EAT Profil… Michael Richardson
- Re: [Rats] Profile identifier (was Re: EAT Profil… Smith, Ned
- Re: [Rats] EAT Profiles Dave Thaler