Re: [Ace] [EXTERNAL] Francesca Palombini's Discuss on draft-ietf-ace-oauth-authz-38: (with DISCUSS and COMMENT)

Francesca Palombini <francesca.palombini@ericsson.com> Mon, 05 July 2021 13:32 UTC

Return-Path: <francesca.palombini@ericsson.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E79A23A1803; Mon, 5 Jul 2021 06:32:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.999
X-Spam-Level:
X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.198, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 2UGFEFEhpj4L; Mon, 5 Jul 2021 06:32:14 -0700 (PDT)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60071.outbound.protection.outlook.com [40.107.6.71]) (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 79B283A1831; Mon, 5 Jul 2021 06:32:14 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ASHiXSuSwUycREG+7I4Crn8tkx8oBsqSwfeTmbSV/Mur0NG7l2oclOEEaDWmq8ogjPSyz1hweCTVkCgB6MdRlM1r2M2kUy9z5JHjZpgCj0+b3F7WQh0LpwkoaHwBCPVHcFFH1qjQ5aVWbRtvU0BRKss47ZIjMpVjn89G78VjYyCLbK8KqaYpGG3PrhJtnajGawU5cBWWWhTknPas83sLjvmd5M2xx7hyc1p8WFkBZ8893sm+grdAgdRTP48eAoYxfRsb2BiaflmuOPbu2HzsxjWzo/hoiV31cqDvi2W64IWpGOw/WGp6zjcl16u1DHALqyvHpHRmGnjZUHATZGvYBA==
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-SenderADCheck; bh=ba0q37D8kbQ1Y89ezP3gcPYN3deX1yC36tP01nsQYP8=; b=IbGLTApE7ewAGeKfBGUgYDSVMsAToGlNk3e77SnckYW7/Nnrv//GV2PAtd7VtGtTGOJz20naVAHPjIqnWL18mGIJCy/e/dFDU/T2MPF32hiuHBiQLcMPTMoXTyY2bTFmV56FJBG1VJOHJT65RAxz8dVpQPgdPA93eCnQfBZM2KWwJjH1PeJvz5t+2WF22/BTvUl+MtGE9gU0+t8AfIoVh9n3/836EiKrBPtNjSUqufxBgSYvepbPU0fvP5nJ5Frt/Hbe+Numxaog9GK055DdVVkOqOQWOw1bYgqzKchU9IgV4gyIXLYoqf2R3iQKZa5vQ8JNe+RB084mzSsyHiDOmw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ba0q37D8kbQ1Y89ezP3gcPYN3deX1yC36tP01nsQYP8=; b=IovZahrv04ZyUM0LYVZHbD4Ij1oXtotmmIt4jPPqMybSPs6ed8LnekKAqlAcaRgHuxDosWaTh235jXGv+4pgD3x7z3HXGxk74MHVBOt9p2if6oRolHTGttszYTmaDk8BiWmg80KuDXocXXR3eNVyyPcH+KMHurXxAsp0m7hhlU8=
Received: from HE1PR07MB4217.eurprd07.prod.outlook.com (2603:10a6:7:96::33) by HE1PR0701MB2155.eurprd07.prod.outlook.com (2603:10a6:3:24::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4308.18; Mon, 5 Jul 2021 13:32:11 +0000
Received: from HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::6ce5:7088:a9a8:15d9]) by HE1PR07MB4217.eurprd07.prod.outlook.com ([fe80::6ce5:7088:a9a8:15d9%7]) with mapi id 15.20.4308.019; Mon, 5 Jul 2021 13:32:11 +0000
From: Francesca Palombini <francesca.palombini@ericsson.com>
To: Ludwig Seitz <ludwig.seitz@combitech.com>, Carsten Bormann <cabo@tzi.org>, Daniel Migault <mglt.ietf@gmail.com>, Cigdem Sengul <cigdem.sengul@gmail.com>, =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= <goran.selander@ericsson.com>
CC: "ace-chairs@ietf.org" <ace-chairs@ietf.org>, "ace@ietf.org" <ace@ietf.org>
Thread-Topic: [Ace] [EXTERNAL] Francesca Palombini's Discuss on draft-ietf-ace-oauth-authz-38: (with DISCUSS and COMMENT)
Thread-Index: AQHXXP9PFhvEr4sObUqGUYCooE8rZ6sLf0QAgAsq0wCAFMBAgIAAPD4AgAjAu4CAAAkFAIAAO4SA
Date: Mon, 5 Jul 2021 13:32:11 +0000
Message-ID: <A15462D1-DD0F-4B3C-8C59-7652C6A5F471@ericsson.com>
References: <161659738410.3239.3955409176349739508@ietfa.amsl.com> <5634f824f7b14878b5d7d1fdd3b2ed33@combitech.se> <EE1CBB56-8951-473C-A006-875D49BEE350@ericsson.com> <AM0PR0302MB3363E4EB817969E6B34FBBCF9E369@AM0PR0302MB3363.eurprd03.prod.outlook.com> <F44C49D2-C08E-4C04-A751-05ECBBB1DBA9@tzi.org> <AM0PR0302MB3363C4C6DBD796E67986BD079E369@AM0PR0302MB3363.eurprd03.prod.outlook.com> <43222AD5-BA56-423F-98C7-65128A6C35B6@tzi.org> <CADZyTknQEYbv=3vo_MfjGeWmJOcU-QfkFua-ZGnFHfXhni=omQ@mail.gmail.com> <3AF922BD-D6D7-4D20-AA39-5E0D5BEC8A29@tzi.org> <a040239b-fc8c-b2a3-c055-481246f4397c@tzi.de> <AM0PR0302MB3363B7DBB026447BE536D61D9E1C9@AM0PR0302MB3363.eurprd03.prod.outlook.com>
In-Reply-To: <AM0PR0302MB3363B7DBB026447BE536D61D9E1C9@AM0PR0302MB3363.eurprd03.prod.outlook.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_71cffee6-aa30-4f5a-bbc3-434e7067f7b3_Enabled=true; MSIP_Label_71cffee6-aa30-4f5a-bbc3-434e7067f7b3_SetDate=2021-07-05T11:59:09Z; MSIP_Label_71cffee6-aa30-4f5a-bbc3-434e7067f7b3_Method=Standard; MSIP_Label_71cffee6-aa30-4f5a-bbc3-434e7067f7b3_Name=Company Confidential; MSIP_Label_71cffee6-aa30-4f5a-bbc3-434e7067f7b3_SiteId=0d11ac4a-ef5e-423a-803b-e51aacfa43d6; MSIP_Label_71cffee6-aa30-4f5a-bbc3-434e7067f7b3_ActionId=5674b063-b9ab-4a53-8b25-d3933bdbf990; MSIP_Label_71cffee6-aa30-4f5a-bbc3-434e7067f7b3_ContentBits=0
user-agent: Microsoft-MacOutlook/16.50.21061301
authentication-results: combitech.com; dkim=none (message not signed) header.d=none; combitech.com; dmarc=none action=none header.from=ericsson.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a6251567-44f0-4a7f-1a8b-08d93fb94b57
x-ms-traffictypediagnostic: HE1PR0701MB2155:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <HE1PR0701MB21555CE6D4FB6D6787D482AA981C9@HE1PR0701MB2155.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: v5nHLeIAFtl52L7Hii5tAfqNP0/PouRF5JKVHDp2agkdv75KbUSsc45xCUI8UIarz0rPgObligjWFuM2rsMHVuIt4nmWC+6ThAJ+EX/3/nOND07K329Dy0XkDE5M/n18F/FFdk/mnXC/gdiZtp0KncDZQHqv1TQmsn7i3MH5VQehryJpJ2aFgJO4rhvLjHfw4bBdN2iBgnh4ABG0+2EaDyxIsqpN6HcFHstrD/M4/4cZBvPL05ckYodbwW7I8AUbdkZZB4gnhfptzUJ9spIRKbQkH32X1pog8WD9dOS4u7s1yFU1WN5SR53dGR15r553jAyL9zHJxskaAHn1NgnOzI6YNcE/qLibWn9PxLmcNGpsbbwg8szp8kMBgVE5s4D7bb0tiQXjkKViEiN9A3TjoOlBpqgE74QoowTHNOp/rXJbNP8ex1QGbAQSqZIDqXT/Y2lCPnAs2TeGgr/R7p8ul8PNAv0JrlR+2Wb6HL9TGwlJLlI4ACjEROCs57JUKsSQMyj/eM0gsJJEIDREinW3IBmFbdLrSSVDX8eKOHifPbXJAv6S/fimKj5pgBQuJ4ZK/LhoChF+GgcXMght+kUQyGp4lNlS/PNeY9MfhCGFmoPLexGq9vYx7ZV3R+akXumzRlpZe1YpnkgGD6HVyyP6TqI1FmSj7OFhX0Ng6bXGwkokJS7lX2Ssm5NayuipsMqKePjz59JzmPRHuOfTrYXgXffvzfdIQ4qlsLjAjJOA1txeXPZPf/OHuHE+RO4s28TZ2Qf9SKf1L/5PDkGhgXorX5BpobLfMV6Ru7+f+Y7xGudwtcMhRCpY5/0lDyUED/ZCU92W+LCh7y5o2lYe2P7n0Q==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB4217.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(136003)(366004)(396003)(346002)(376002)(8936002)(66476007)(186003)(316002)(36756003)(66574015)(66946007)(33656002)(76116006)(64756008)(66446008)(66556008)(122000001)(44832011)(6486002)(86362001)(2616005)(71200400001)(966005)(6636002)(4326008)(6512007)(5660300002)(8676002)(6506007)(83380400001)(2906002)(53546011)(478600001)(54906003)(110136005)(38100700002)(45980500001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?utf-8?B?aWNWUzlYTHRJelRmZDlxQ0ZmV2ZadmgyUityamZLL0lwM2JDZ0NiNytYZWFz?= =?utf-8?B?eWx4WEpGcDhMdzNwUHRvdWt2S3RZci9WUlg5UTYyem1nNUN4ZVZ0R3p2Tloy?= =?utf-8?B?L1lxQkRESkl1RGhjdStMZ0xrU3NDb0xSd2dYL2ppWkRXUXBSRU05NnFGVmIr?= =?utf-8?B?RHA1cFI4eTJzdTdOZTdzZ1NZc0dCSC90Zlk2MGdUb2NSLzU3TG5KS3hVWkpt?= =?utf-8?B?cmJSZ001c0pmVzk2SFpUUXFvV0d3RDdra3ZBZnRobzVIS2l3MXRiYk5zVXAz?= =?utf-8?B?ZURHSTBwZ0g0elJTVFhWU3pOTDNiMzR2TDVEWnFvdmU1VnlpQkEybXg3N1hx?= =?utf-8?B?TGMzeFhIV01nZFB1djVZY0FsdnlwdmlqR2VqdFd2WXRpcURVMWNxRHJESUhy?= =?utf-8?B?UmdQR3BSVEpkc1dzTE5Ma1haQndSTDVZTjBPem9iV1FzTFB6LzdVbnZpVW94?= =?utf-8?B?b3VtOE9EUGRteks3VW90UGpPSitiSGdybnJrZ0ZNUUhDWlZkdXZEaG0vNzdw?= =?utf-8?B?a3NTQnB2OThlQVQ0UitIU1ZLSmdESmdkL3dWeTBCNlpQSUQ5VW5YZ240K29q?= =?utf-8?B?NkszOEp6SExuUmZJVktnSXZwMWU2eEc5a2I1Yk5PNHcrVkM5c1JyTkZVZG1h?= =?utf-8?B?VUM1SW45czFJbncxQjFRenZ5ZEpWMmNGbSs3M0U3SlZrQld4aHJZa2kxVHZH?= =?utf-8?B?dy9XdzI5WTFkckRqYlJ3UTlqbDFWdnUzZVZpU2s0VDF0TkZzalcyV0lEK0JW?= =?utf-8?B?MWMyVjI0L04rd1RHTGNReWhrbXpra1VwdjhES3VtVmZYMWtQOUQ4Z1RsRThh?= =?utf-8?B?NXJtakd3c2hzS2tyYjZMb3IxZlNTcmJaVFF3KzVZZHN1cGk5WEw0ME5heWVE?= =?utf-8?B?MUw0R0djNk5kSERvdHR6RENrOXFqRVVEbUtVcVBRZENScSs2RFVzeXgzemUr?= =?utf-8?B?R1VqTWxZaWMrSGZ1UU5TbUVnMUZGZ0p3Yy9FNDEvdC9BSFhuNWJ0VnI5TmVG?= =?utf-8?B?RGtQUGR2dkEyOGVRMDVMNGIzNEdLczNta20reVJXVmx1YTBLb3B5QkxaSEhL?= =?utf-8?B?R2p3VHdpU1NTaWsyS3VQU3F1TFNjaEZtR0dWcmE0cDBnazkydDZ1OHFIcm02?= =?utf-8?B?TEIyTjcxRzJTTHF4dlp3cjhlUWYxaUdHYWpnSlpHUGZlTlNnNFUvKzg3Mi90?= =?utf-8?B?Z3dpcGRmdFI0SEJlaldpTFNPUmlnZ2VLbXBTdjlDdFBDeDgzMnB2d3ZzWkxz?= =?utf-8?B?NFpDcVluekxCVHptb0c3RXhIcnVmZ3BlZUY0cWZyOGVpMm9NVnBzdHRkNjh0?= =?utf-8?B?NmpGZ0VycmRjbU82MnFVZHZCU1dLeUVDZkdJdHdkSzh4WXFESm8zUGpIbFNj?= =?utf-8?B?UXVHUzVWeGRPQmhlcFpzRThQb2VSTU5SVGQ1NFpxSUVXeVMzY29pVU1xdUg1?= =?utf-8?B?U2hBRVh5Zks3NCszWjRUTUdKc1ZzYkYyRGdYR3EwK1c5Zmx2enlmMVM2amNR?= =?utf-8?B?Q1duaGR1U1VEUnQveVpKVHNhd3ZURlI4NlVncHNhbEVnZlpqdnhFdTU4NHR0?= =?utf-8?B?N2lXUzBXZTRnV3FwbytlRHppbFJqNFBUejJhYWVmYU9pamlXOUcvSGR0K3VC?= =?utf-8?B?Z2FZTXBuOEFrT3BnTTE2bzdxWU1KNGR2cmN2UU9nWXYvMWJaNUF0azFSYUVa?= =?utf-8?B?VndjT2hldEZUcGlZOXBtMy9Nb1lZK3U4SGV4Q2lNYmRBZGRaMUQyaFVjTUND?= =?utf-8?B?TWQxanIzTUlpTmVVNVpRRzRTMTVMMzNuRzZ6TDNmTU14aTBLeWtrZDdCbThI?= =?utf-8?B?YXVGZmJIVk5SZU5EMjZSSU9zaVk0RVRzVE9YVFkzTjVsclM3bWRwa3NLeGRv?= =?utf-8?B?QzdKSExDK3AxNS9WV2hqVjNXd3VjdWk3NzdwT0R4dzZJZ1E9PQ==?=
Content-Type: text/plain; charset="utf-8"
Content-ID: <0F358C18BABEC54593A3C9D873862267@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB4217.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a6251567-44f0-4a7f-1a8b-08d93fb94b57
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2021 13:32:11.3645 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Aqam00F+kYhjgpeh9x2BJWgeejzwf6/zTHEFQP8P8wyABYTrqlUW4sLhbBOUE31GPUcEEXXH5sVPWkbOETV9zfI1aFGlXGQpyZtJ8RWZLvZ1dFTTCZHbXYVS5/bYh9d6
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2155
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/0LTjhq4reQ3laD0pNId6FgfMToQ>
Subject: Re: [Ace] [EXTERNAL] Francesca Palombini's Discuss on draft-ietf-ace-oauth-authz-38: (with DISCUSS and COMMENT)
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Jul 2021 13:32:20 -0000

Hi all,

This is my official "Ok" for that point. Thanks.

I still have the following point open from the mail exchange with Ludwig, to which I hadn't replied (all other points are good). CC Cigdem, Carsten and Göran as they participated in the discussion.

6.7.  Combining Profiles

   There may be use cases were different profiles of this framework are
   combined.  For example, an MQTT-TLS profile is used between the
   client and the RS in combination with a CoAP-DTLS profile for
   interactions between the client and the AS.  The security of a
   profile MUST NOT depend on the assumption that the profile is used
   for all the different types of interactions in this framework.

My original comment and Ludwig's replies:

>FP: This seems strange - maybe I just don't understand how this is 
>supposed to work, but each profile defines exactly at least C - RS 
>communication and security, if several are combined, it seems that at 
>least the C-RS would conflict.
>
>LS: You could use one profile for C-RS (e.g. MQTT) and another one for C-AS (e.g. DTLS) in the same interaction. So the writer of e.g. the DTLS profile MUST NOT make security assumptions that this profile is used on _every_ leg of the communication.
>

FP: Ok, I see, you mean that the C-RS interaction uses for example one profile, while the C-AS uses another? I am not convinced this text is enough - first of all you'd have to make sure that the profiles are "combinable" - the OSCORE profile for example requires the security context to be derived, and simply using another profile without tweaking it would not be enough. Additionally, I am confused about the implications for implementers to mix and match different profiles for different legs of communication, this sounds like interoperability could be an issue. Can we discuss this more?

LS: I don't really see the problem here. Say you have a client that uses DTLS to talk to the AS. The AS determines that the client should use the OSCORE profile to talk to the RS and prepares the token accordingly (including the OSCORE parameters in the cnf claim of the token and the cnf parameter of the response). The client is informed of the chosen profile with the 'profile' parameter and proceeds to derive the OSCORE context for client-RS communication.

We discussed this during the May interim: https://datatracker.ietf.org/doc/minutes-interim-2021-ace-08-202105111000/ However the minutes don't capture the whole discussion so I suggest you listen to the recording to catch up (and I am sorry I was indeed delayed and breaking up): https://youtu.be/Cp5P2q78iVY?t=823 . 13:43 I try to explain what problem I have with the section; 16:20 the discussion starts; 27:40 the conclusion starts; 31:40 we move on.

To summarize my understanding - we agreed that the Section 6.7 was unclear.
* The first sentence is confusing in the sense that it is not clear what "combining profiles" mean. The way MQTT interprets it: different transport and security protocols can be used in different legs. Profiles MUST specify how that works (as for example MQTT allows for CoAP and CBOR to be used, and defines how).
* The last sentence is problematic because a profile cannot guess all profiles that will be defined afterwards and make sure they could interoperate.

So my suggestion for this section is the following:

OLD:
   There may be use cases were different profiles of this framework are
   combined.  For example, an MQTT-TLS profile is used between the
   client and the RS in combination with a CoAP-DTLS profile for
   interactions between the client and the AS.  The security of a
   profile MUST NOT depend on the assumption that the profile is used
   for all the different types of interactions in this framework.

NEW:
   There may be use cases were different transport and security protocols
   are allowed for the different interactions, and that corresponds to combining profiles.
   For example, a new profile could define that a previously-defined MQTT-TLS profile is used between the
   client and the RS in combination with a previously-defined CoAP-DTLS profile for
   interactions between the client and the AS. It is REQUIRED of the new profile to specify the 
   combination and to make sure interoperability and security properties are achieved.
   

I hope this helps,
Francesca

On 05/07/2021, 13:59, "Ludwig Seitz" <ludwig.seitz@combitech.com> wrote:

    Hello,

    I am waiting for an "OK" from Francesca, since the change was originally related to her IESG DISCUSS.

    /Ludwig

    -----Original Message-----
    From: Stefanie Gerdes <gerdes@tzi.de> 
    Sent: den 5 juli 2021 13:27
    To: Carsten Bormann <cabo@tzi.org>rg>; Daniel Migault <mglt.ietf@gmail.com>
    Cc: ace-chairs@ietf.org; Ludwig Seitz <ludwig.seitz@combitech.com>om>; art-ads@ietf.org; draft-ietf-ace-oauth-authz@ietf.org; The IESG <iesg@ietf.org>rg>; Seitz Ludwig <ludwig.seitz@combitech.se>se>; ace@ietf.org; Francesca Palombini <francesca.palombini@ericsson.com>
    Subject: Re: [Ace] [EXTERNAL] Francesca Palombini's Discuss on draft-ietf-ace-oauth-authz-38: (with DISCUSS and COMMENT)

    Hi all,

    There is an unresolved issue that is holding up the process of finishing the ACE framework. As I understand it, the issue can be resolved by adding a sentence to section 3:

    OLD:

    CBOR is a binary encoding designed for small code and message size.  Self-contained tokens and protocol message payloads are encoded in CBOR when CoAP is used.

    NEW:

    CBOR is a binary encoding designed for small code and message size.  Self-contained tokens and protocol message payloads are encoded in CBOR when CoAP is used. When used outside CoAP, the use of CBOR remains RECOMMENDED.

    Can we add this and finally finish the framework and the DTLS profile?

    Thanks,
    Steffi


    On 6/29/21 11:47 PM, Carsten Bormann wrote:
    > On 29. Jun 2021, at 20:11, Daniel Migault <mglt.ietf@gmail.com> wrote:
    >>
    >> Hi,
    >>
    >> So here is the current text:
    >> """
    >>  CBOR is a binary encoding designed for small code and message size. Self-contained tokens and protocol message payloads are encoded in CBOR when CoAP is used.
    >> """
    >>
    >> I think Carsten is suggesting the text does not limit the use of CBOR to the use of CoAP but eventually when other protocols are used..The difference is that when CoAp is used there is a stronger insentive to use CBOR than when CoAP is not used. If that is correct, we could clarify that by adding. ""When used outside CoAP, the use of CBOR remains RECOMMENDED.""".
    >>
    >> Please provide some text that would address your concern.
    > 
    > That works very well for me.
    > 
    > (My main concern is that the current text sounds like CBOR is only 
    > used in CoAP, while in reality CBOR remains the encoding of choice 
    > unless there is a good reason to use something else; this concern is 
    > addressed in a very precise way by your suggested wording.)
    > 
    > Grüße, Carsten
    > 
    > 
    > 
    > _______________________________________________
    > Ace mailing list
    > Ace@ietf.org
    > https://www.ietf.org/mailman/listinfo/ace
    > 

    -- 
    Stefanie Gerdes			Tel: +49 421 218 63906
    TZI Universität Bremen		E-Mail: gerdes@tzi.de
    Bibliothekstr. 1, MZH 5150
    28359 Bremen, Germany