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

Ludwig Seitz <ludwig.seitz@combitech.com> Wed, 09 June 2021 06:43 UTC

Return-Path: <ludwig.seitz@combitech.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 7ED733A127C; Tue, 8 Jun 2021 23:43:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=combitechcloud.onmicrosoft.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 LycG4n3q8cnv; Tue, 8 Jun 2021 23:42:56 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130053.outbound.protection.outlook.com [40.107.13.53]) (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 E9E6C3A1278; Tue, 8 Jun 2021 23:42:54 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XEvEG9M3OuW/iquthhrPKpG4dGef8m5+sE3Zm7Ml0gaUAj4FNOrOQ0+jGcZ0hteMHaKqDACPH1g8SuLaXywXA2xZZQGq6QRICo25S0Wyd1U9G29KWiZLtPD12Au8GTP2DslsFYcnn7uolyAhqAusmxP/lBt87s0m5cRF2St8Yiq5mL2fqUNTRv0X0uNNR/ohZhtqmD+sLYKovkxWIm4wCu7MnMnyrhDPbw0B/PAtScAH63F08upWrnv9S8caRUxLv/fhSs7wYjsdqLlIoSmpxRPgUmKUEKfEGYXmyN0t99w7tiwu3Tnnm74QMoGtrRhuCUA8mXaglas0GK/gocVubg==
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=395Ij5soO94PV7nYdb6rgmHQNFGiUflpJ2T8zHHYtOs=; b=N8deuFuWU7Ey+1In/aEsPVsb0KiE4y0zDm3706o+xwR3wz6T89uRJGkSGv3gXxgWacO43CH8OmhgPp/4R++WM3qh/HjXuxIg3Hc12RLlQpE8UnHs4G394u17WIRU7ikaSNsadgGzNvT4yu5nC4mt67BQhjAcYhzQrCCLDKNJPFd9CUUNYbXKEm0ZTHF3qWCuEmRyd5nlwJOmVr1y6VfIeQLSaBbL4ibUidvGE2JOX9TPulsNr+wRYZoxAsXAWZTRiCiWfhWWouB3YyCBrQmXi0BMiIePPYE6qdYMD3GEos3wRzZNqbULD8X5OoMU9XOaSIu9MylH3hDbBkOja+SMCQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=combitech.com; dmarc=pass action=none header.from=combitech.com; dkim=pass header.d=combitech.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=combitechcloud.onmicrosoft.com; s=selector1-combitechcloud-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=395Ij5soO94PV7nYdb6rgmHQNFGiUflpJ2T8zHHYtOs=; b=JJWIxVr0pyjVZRKI2jshxy50qTNtZDEcPejb/hK33XBMK1qFqQEBiT61qvtvR8wkRMX+q8JCZou4B85oE5klo2vlzBRQNIiXO2SlCMcJ8UAu4N0xByJXT71mwBNRBtAYC9aHFJqyyleyjLX0GCADlzc05ZeMYyqbVBlhXYR5i5Q=
Received: from AM0PR0302MB3363.eurprd03.prod.outlook.com (2603:10a6:208:c::21) by AM0PR03MB5987.eurprd03.prod.outlook.com (2603:10a6:208:155::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4195.23; Wed, 9 Jun 2021 06:42:52 +0000
Received: from AM0PR0302MB3363.eurprd03.prod.outlook.com ([fe80::50c3:52c1:d1a8:ea87]) by AM0PR0302MB3363.eurprd03.prod.outlook.com ([fe80::50c3:52c1:d1a8:ea87%3]) with mapi id 15.20.4219.021; Wed, 9 Jun 2021 06:42:52 +0000
From: Ludwig Seitz <ludwig.seitz@combitech.com>
To: Francesca Palombini <francesca.palombini@ericsson.com>, Seitz Ludwig <ludwig.seitz@combitech.se>, The IESG <iesg@ietf.org>
CC: "art-ads@ietf.org" <art-ads@ietf.org>, "ace-chairs@ietf.org" <ace-chairs@ietf.org>, "draft-ietf-ace-oauth-authz@ietf.org" <draft-ietf-ace-oauth-authz@ietf.org>, "ace@ietf.org" <ace@ietf.org>
Thread-Topic: [EXTERNAL] [Ace] Francesca Palombini's Discuss on draft-ietf-ace-oauth-authz-38: (with DISCUSS and COMMENT)
Thread-Index: AQHXILzzVZOkJ2C2XkOPQBkiqfeG0Kq21d+AgCaiYICALjCYMA==
Date: Wed, 9 Jun 2021 06:42:51 +0000
Message-ID: <AM0PR0302MB3363E4EB817969E6B34FBBCF9E369@AM0PR0302MB3363.eurprd03.prod.outlook.com>
References: <161659738410.3239.3955409176349739508@ietfa.amsl.com> <5634f824f7b14878b5d7d1fdd3b2ed33@combitech.se> <EE1CBB56-8951-473C-A006-875D49BEE350@ericsson.com>
In-Reply-To: <EE1CBB56-8951-473C-A006-875D49BEE350@ericsson.com>
Accept-Language: en-US, sv-SE
Content-Language: en-US
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-06-09T06:42:49Z; 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=4410e309-dc53-4f4e-ad31-d778bef11a25; MSIP_Label_71cffee6-aa30-4f5a-bbc3-434e7067f7b3_ContentBits=0
authentication-results: ericsson.com; dkim=none (message not signed) header.d=none; ericsson.com; dmarc=none action=none header.from=combitech.com;
x-originating-ip: [84.217.44.37]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c3cfce04-209b-42cf-1f2a-08d92b11ce0e
x-ms-traffictypediagnostic: AM0PR03MB5987:
x-microsoft-antispam-prvs: <AM0PR03MB59875C539673CA24EE2C8E279E369@AM0PR03MB5987.eurprd03.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: +EKbMVoUdX41J9fGgU4zjrJCM83zHYwvDo9Ii0f03mkYwKefL5kmmCZgsvfipu5QWAD5Hg5fl4xmqDmbflMdxqQCRzvy5RnBvjc97W64Q3FuF6750T6w4jJ/4iuI+BbbM4Y7uXS0TTYicUoJWNdtmS4jrIwI4h1CRvS4VCnH1Zr/oxWRuulHDv8ymFjX0i3pFDNhtUYCOg34SRefoZ8ValvoywMWYjVkcHg9fkvjv8qiF/g5DM2IprxMLYgpAWgjvURFBsLxPkqVLskm6aanq4QeHflktgrHDYc3HRXZG/Te6OyvC4brlLgYGhJlZmg6wJaoPODsQSxa4R61J5InsuKpGeBe2YONxsZvFvwZdlzEwsoxaMH9Koef4kbp+sVsVeR481BxkbldFv0guA5rIYiJjU+ON79EOJojgyX8paRNw4Mr0VZ4GsW60f0YEHgb74mUzHZTtH69DPyd8jvBZEu1DEDrtcTPFpBKAdOuNMAdQ6ZGdzVi+1gXNETktfVnlV2xXlbF0UKidk4nBHriblwa9Q4JrWfVwdDvVk4ZkSbDtgg5G7sZ3gh8ysKqWZ+r5afOAVBAw4y3Lv0dEUPeJdPk9Ws6o/KngU4/XxNr+sKdkyg5Oz+zKfu9u+xI+0nPbT4R4e4jkKY7w0YX9Vgxnp57G/jyoRmbnJ0TT5OkHqs/m+JK2jUd/rC4Fl2IEPEFqhDEPi+bpbZ8f46zOu8rOg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR0302MB3363.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(346002)(39850400004)(396003)(376002)(136003)(66946007)(26005)(8936002)(8676002)(83380400001)(64756008)(76116006)(66476007)(53546011)(6506007)(44832011)(7696005)(66446008)(52536014)(316002)(38100700002)(5660300002)(2906002)(66556008)(71200400001)(9686003)(110136005)(54906003)(55016002)(86362001)(33656002)(478600001)(122000001)(186003)(4326008); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?U2hJZWlpaHRBdnkxNlYzL3hlTkJaY1gzeGFoV0ZHQ1FFSkZHOVd2Nlp2OHNh?= =?utf-8?B?NEIrSk56YUNzaUtBaThGQnJmSm95RkovOGRzZlpXMSttYjdHYVpNRXI2bDMz?= =?utf-8?B?Zm9kc0NjMFljYjRMakFJMURDL0xGMzlyS3hjcXovektnRjJNdFpxOXU0b3Bj?= =?utf-8?B?ZmhqOVJoQms4NCtqTjBwSkFqTm1SSTRzWHdZRU05d3p6VUJBZFJ3MjNIRU8z?= =?utf-8?B?QjN5OUx0U0VIMUZlc21GZkxhQkJJWDhjemZMamlNaEZuWlVzK3ZGYXNXcGJU?= =?utf-8?B?cnZxRW5VbVhtL2NXck9uN2E0M0pmYldtUXFoZC8wNDd3L20zZG4wa0dmR1Bz?= =?utf-8?B?RVZPQ2hyZHlibThxTldjSERWT1JmaXNNZUxQOC92YXdlRlIxZ1k4QjlFSzhP?= =?utf-8?B?MmpiYW1haFc5dW11V1BsZjBoTVAzREhMTWRvcWxKZThJNDhxcndTb1NaeFY2?= =?utf-8?B?SHVYNWkycGF0ZGtpT2FRVWFsM2pBNUJEcENjSHV2Y0ZtcEovaXBWc2U4VWdL?= =?utf-8?B?dEYrRWR6UWRrbWE5cWpwM05RZUJUMjF1ODRnVHZnZm1DUmNQNnhEd1JKOWpE?= =?utf-8?B?NDJIaWpvcE8yUUNsdnFYWHBiL0o3TS9INUJ5em5venkwRFdzS2dKUXJvdEtI?= =?utf-8?B?MmpvQ3Bld3lBNWg4ajN0Vi9Db2pDeHRrdS9MUXFpTk9Ec0xFRU9GdXZwbE9O?= =?utf-8?B?QVZWbmFUSUNVZVY1Tzg1V2NLT0VWR2I2TWNEN2hxNTNVUEQ0d1dObWJZdHlr?= =?utf-8?B?aUxKaFpoV0RIVDVEU2VZajRLWDBsbVFodm9rUHgyYUFFMU9NUmdVQTRDUVRx?= =?utf-8?B?SXpSRnVDYXMyOEpQR0VWOGVBR0pMUjQzV1N4c0xPNkhvNkN2WEw3TElRUnF3?= =?utf-8?B?VjBZTzdCNGJ0VmoxTWsvUHdMckY3K0VOL0V5QVI3V2kzY0xyZGNzWXVtVG13?= =?utf-8?B?dnZNYlR1d2RBUC9mcXFmVGZWQTMycFJaQUplU2kvTEZBOTV1Yk1LV0JDZGtl?= =?utf-8?B?cmk2TERKVWVWYXpJQ0RTTlBWR1puOWJrcFRJbFhhYmg2cDBRWFBiMjlXSTVL?= =?utf-8?B?NXhiWVViQnVVYWE2emkxTDVqcFZSTDA4QlJOaGM1TEU1TVNEcjh6Zmc5M1FP?= =?utf-8?B?RW9qMUtWVllyR3BZSjBTMGEzcmhCRnF1SVVjWDl3UTVnSWpFcGhmT0ZmMVRI?= =?utf-8?B?b2JFb0p1SUxoNWVoNk16VFJKNVBpZ3V3Zk5jYTV4RG12ZmRUQllpaUVacHcx?= =?utf-8?B?YlRxU0tvZTVEVDF5NDBIZGlMNThOMzlUVzkweTZWRkhpZ2hHbHRxNmNadDBx?= =?utf-8?B?UmdzVlNEL1ZQZDJzU1NGaXlsOVdKUk9Cdk1PZ25DaFZKdFhScVdaSHgxUUlp?= =?utf-8?B?RDFXdnlrWlkyTU5tRFZFMzBycyt2S05HdXRac0xDVWoxUU0wamRxQlRLNzF5?= =?utf-8?B?ajF5S0FPZnlQL3lPZnhPSllYSHc2VHM2d01kYllIOWM3MERKQm5lZzA0TEZE?= =?utf-8?B?MjM0TWJZV0tuVUJSNGZWN1ZuUGc3ZkMwMWpZRWwxcGVyTnpwZ0pnSGM1ck1E?= =?utf-8?B?dFU2MEhNbElaV3BsSStpbWovUkhrUFpwK0FTVjV5eFY3TFF0MHR4R2piTm03?= =?utf-8?B?MFUxRDhKMWF1dm5kNmZnQ3QrdWp3RW9mNGtZeTBtUGw5S1h0dTN4RjhGTXVm?= =?utf-8?B?STFYNGF5SS8yK1ppRGVsSnVVZ3Q5Nks0VS9QMEpRZWVDOTg2KzViMkgyWUM2?= =?utf-8?Q?FxkQZ12ht1x1uxtoI0=3D?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: combitech.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM0PR0302MB3363.eurprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c3cfce04-209b-42cf-1f2a-08d92b11ce0e
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2021 06:42:52.0476 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0d11ac4a-ef5e-423a-803b-e51aacfa43d6
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: VFIJO8FAtkVH6tDMWDR7QpMMCBRoo0pz6qFnOcQxjLQfRAg53dN3ikmDwzWpMfxe80m9J4qbrb05KerUX1vBxqrgB9GOz1xNGvjrLdwptkY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR03MB5987
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/ivdnWfOZADfcsUrS6I-6HSUEK1s>
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: Wed, 09 Jun 2021 06:43:02 -0000

Hello Francesca,

Comments inline. Update will be posted shortly.

/Ludwig

-----Original Message-----
From: Francesca Palombini <francesca.palombini@ericsson.com> 
Sent: den 10 maj 2021 20:42
To: Seitz Ludwig <ludwig.seitz@combitech.se>se>; The IESG <iesg@ietf.org>
Cc: art-ads@ietf.org; ace-chairs@ietf.org; draft-ietf-ace-oauth-authz@ietf.org; ace@ietf.org
Subject: Re: [EXTERNAL] [Ace] Francesca Palombini's Discuss on draft-ietf-ace-oauth-authz-38: (with DISCUSS and COMMENT)


Hi Ludwig, authors,

Thank you for all the work on the document.

I have checked all my comments (including those that you have addressed in v-39 and not reported below), and I am good with almost all of them.

Considering the clarifications added as a response to my comments regarding CoAP using CBOR encoding, and HTTP using the encoding from OAuth 2.0, I believe the document is now in good shape and not confusing anymore. I understand that when CoAP is used, CBOR MUST be used; when HTTP is used, semantics and encodings of OAuth 2.0 MUST be used. Any other encodings/transport protocol would have to be defined by a different specification.

Regarding my request for clarification on mixing different protocols (HTTP/CoAP) on different legs of the exchange, I understand that it is not in scope of this document, and it would rather be up to the profile defining such a mix to motivate and explain the use case, so I am fine with it.

Your clarifications on the use of HTTP also addresses my last DISCUSS point - a new media type is not required, as the framework now effectively reuses OAuth 2.0 encodings. Any other specification (such as MQTT) which aims to use the JSON equivalent of what defined here for CBOR instead of the OAuth encoding will define and register their own media type.

I hope we can discuss the leftover comments (especially the last point about using several profiles together) at the interim tomorrow. However, these are non-blocking points, so I will go ahead and remove my DISCUSS now.

Thanks again,
Francesca

>Hello Francesca,
>
>Thank you for your review, sorry for the long response time.
>
>Version -39 addresses some of your comments
>https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz-39
>
>I have replies on the remaining comment as follows below (prefixed with 
>'LS:')
>
>Regards,
>
>Ludwig
>
>1. -----
>
>   sufficiently compact.  CBOR is a binary encoding designed for small
>   code and message size, which may be used for encoding of self
>   contained tokens, and also for encoding payloads transferred in
>   protocol messages.
>
>FP: "may be used" make it seem as if CBOR is always optional (even when 
>CoAP is used). See points 11. and 13. for examples of text that seem to 
>imply that CBOR is mandatory in some cases.
>
>LS: This is a lower-case "may", so it does not have a normative meaning.
>There are indeed cases where CBOR is mandatory (e.g. when CoAP is used).
>

FP: Lower case "may" only makes it so that the corresponding text is not "required for interoperation or to limit behavior which has potential for causing harm" (to quote BCP 14). Even without its BCP 14 normative meaning, the text hinted that CBOR is optional IMO, which is misleading. I would suggest the following:

OLD:
   sufficiently compact.  CBOR is a binary encoding designed for small
   code and message size, which may be used for encoding of self
   contained tokens, and also for encoding payloads transferred in
   protocol messages.

NEW:
   sufficiently compact.  CBOR is a binary encoding designed for small
   code and message size. CBOR is used when CoAP is used for encoding of self
   contained tokens, and also for encoding payloads transferred in
   protocol messages.

This should go with the direction you point out below for CoAP implies CBOR, HTTP implies whatever OAuth 2.0 defined.

[LS] I don't like the "is used ... is used" in your suggestion. I'll rephrase it to 
" ... size.  Self-contained tokens and protocol message payloads are encoded in CBOR when CoAP is used."


>9. -----
>
>   parameters.  When profiles of this framework use CoAP instead, it is
>   REQUIRED to use of the following alternative instead of Uri-query
>   parameters: The sender (client or RS) encodes the parameters of its
>   request as a CBOR map and submits that map as the payload of the POST
>   request.
>
>FP: I think it should be better defined (or at least hinted in this 
>paragraph) the mapping between the CBOR encoded parameters and the Uri-query parameters:
>are they all encoded as CBOR text strings?
>
>LS: The encoding depends on the type of the parameter and is described 
>for each parameter individually

FP: I think it makes sense here to state that this document describes the CBOR encoding for the existing parameters, and that if a document needs any other parameters (defined in OAuth by a future document) then the encoding for Ace needs to be specified by that document as well. This is just to clarify that you can't just use OAuth parameters with CoAP.

LS: Ok I'll add more text to clarify

>
>18. -----
>
>         "x" : b64'usWxHK2PmfnHKwXPS54m0kTcGJ90UiglWiGahtagnv8'
>
>FP: noted here since this is the first time it appears, but same 
>comment for the rest of the document. I think it would make more sense 
>to show examples where CBOR byte strings are used instead of Base64.
>
>LS: CBOR diagnostic notation allows the use of Base64 encoding, what other encoding are you suggesting?

FP: Just sending hexadecimals CBOR byte strings instead of Base64 encoded strings. So for example in this case, replace the above with:

         "x" : h'BAC5B11CAD8F99F9C72B05CF4B9E26D244DC189F745228255A219A86D6A09EFF'

LS: Using hex notation makes the representation longer and adds clutter to the document. The B64 notation is just for the CBOR diagnostic notation, 
it still translates to exactly the same CBOR byte string as the hex notation in raw CBOR.

>
>19. -----
>
>   Figure 8 summarizes the parameters that can currently be part of the
>   Access Information.  Future extensions may define additional
>   parameters.
>
>FP: This is useful! Why not having the same type of figure listing all 
>acceptable parameters for the request (section 5.8.1)?
>
>LS: Because those paramters depend on the grant type, and with all the 
>existing OAuth 2.0 grant types this list would become very long and 
>include a lot of parameters that are not very useful for ACE-OAuth. 
>Note that IANA has a very nice listing here: 
>https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtm
>l#parameters

FP: And the fact that there are a lot of parameters that would not be very useful for Ace is exactly why I think such a list (containing only the parameters that *are* expected to be used with Ace) would be helpful. But ok to skip if you don't think so.

LS: I will not object if someone else contributes this, but I don't believe it is necessary and will skip it myself.

>
>32. -----
>
>   The POST method SHOULD NOT be allowed on children of the authz-info
>   endpoint.
>
>FP: What children? They do not seem to be defined, so I do not 
>understand this sentence.
>
>LS: RESTful resources may have child resources, so there could be /authz-info/token1345 and so on. These should not be POST-able.

FP: Ok, my point is that such child resources or their meaning and functionalities is not defined in this document, hence it seems strange to add a requirement on them.

LS: Ok I'll remove that sentence.

>37. -----
>
>   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.
>
>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.