Re: [Ace] WGLC for draft-ietf-ace-authz

Mike Jones <> Thu, 25 October 2018 00:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7079B1292AD for <>; Wed, 24 Oct 2018 17:58:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.47
X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ftixdDgKfOP8 for <>; Wed, 24 Oct 2018 17:58:13 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5DC67129BBF for <>; Wed, 24 Oct 2018 17:58:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1CDj8Fc62rJXX2L3bcL51izz6m7O4bC+1hMoG4PmwUo=; b=jTqrD2cpgC9HBQViV1/gZKc5PWm7t+/b3NgTbKYxgkNhEdnGWCo0uIBUerfxrMj3u5DKA7d16qKFxuzeLD6F5RHK/5ab0B7/3qDD0ASeERnS6jL7P9XtO72vaSW0pFqfXg8t7kfkZsfeOzoeXc7hcLDrBylLIT47cbI5EVPoSm4=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1312.0; Thu, 25 Oct 2018 00:58:11 +0000
Received: from ([fe80::e9dc:6f27:e9b3:a5b6]) by ([fe80::e9dc:6f27:e9b3:a5b6%3]) with mapi id 15.20.1313.000; Thu, 25 Oct 2018 00:58:11 +0000
From: Mike Jones <>
To: Jim Schaad <>, "" <>
Thread-Topic: [Ace] WGLC for draft-ietf-ace-authz
Thread-Index: AdRfTbZXRdy06+geSTKJtOzYofxg+gMqrfqQ
Date: Thu, 25 Oct 2018 00:58:10 +0000
Message-ID: <>
References: <065b01d45f4e$b8d372a0$2a7a57e0$>
In-Reply-To: <065b01d45f4e$b8d372a0$2a7a57e0$>
Accept-Language: en-US
Content-Language: en-US
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-10-25T00:58:09.0382471Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; SN6PR00MB0349; 6:DV9W9EElv2DNWdFLmToCAX7mwZGuktp5w0vUMDcLo/vbx/UE4w/gbQyj4wBgBBapLYqoRTr/1DUWnZfwyuQDhZ5bTnBh1+m/90ReMuk4uSncnHaAhXISDgGFIRk5HocGejijX1cCCihlyDxzg/N5S2rOQW+FinR5Ose71SmA8mQD5ZCET/GtCW/IxtktdXNMY6jIK/cmecw7hTC4/9dm24y/daJlYI4gUyXnr/pf3aN08d8677RJH4yelJ3uF5R7wEG9dJ7MVxAaUGaoC44XsMijZY5JEa7sDVw5eqczgRIi0VCfRSRdADALSeaHFvoUiFtrJsAF88BYBD766JRkdiODUHv9VppDJ7VSktBLLyMWnT3fo/dVrsVGccMkWyxutWmvMUqqmQY50V4XtQf8Lb/g0m/5ieYp+hVE8I80dA+lAGhqFzbgbfwkrBND0cHR4LWFq2BHAdvAzocLFM48sg==; 5:4VTeyEKTdHQtaubp545IFHkR7wMTZKnyihes6GgBVFfKIJBYUP+zlBAvC8ES2slYgMYnnhZmum0qjyjkW+zdQAwEFNt0QHwfle5Agiw8TJGPTPKEg6eEdg157dkPMpahchuhcdkk/D31bJreCTfgk9GmRVk3XcuJaKGWOStAa2s=; 7:mJi8e7gvzBpA4F69/kT2cHALIDWXdDQuHaGkAqLKxHAYF4bhtoySTOl29ji3QGMDXrobFpJAhcvajElooco0vFtZ+bOXcHTp9SVCW5LK7sui3/x2jlRnecJw+lJ10/P41rgjJ3rM+5+g2HduqU2odQ==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: a90cf635-9e69-4aec-9b4b-08d63a14ef89
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:SN6PR00MB0349;
x-ms-traffictypediagnostic: SN6PR00MB0349:
authentication-results: spf=none (sender IP is );
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(1591387915157);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(2017102700009)(2017102701064)(6040522)(8220027)(2401047)(8121501046)(5005006)(2017102702064)(20171027021009)(20171027022009)(20171027023009)(20171027024009)(20171027025009)(20171027026009)(2017102703076)(93006095)(93001095)(10201501046)(3231355)(944501410)(52105095)(2018427008)(3002001)(6055026)(148016)(149066)(150057)(6041310)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:SN6PR00MB0349; BCL:0; PCL:0; RULEID:; SRVR:SN6PR00MB0349;
x-forefront-prvs: 083691450C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(346002)(396003)(376002)(366004)(39860400002)(13464003)(199004)(189003)(5660300001)(10290500003)(33656002)(8990500004)(7736002)(74316002)(305945005)(478600001)(14454004)(966005)(72206003)(25786009)(106356001)(10090500001)(2501003)(8936002)(6246003)(8676002)(68736007)(81156014)(81166006)(2900100001)(97736004)(53936002)(9686003)(6436002)(55016002)(99286004)(14444005)(256004)(71200400001)(71190400001)(105586002)(5250100002)(86612001)(476003)(6306002)(11346002)(446003)(53546011)(186003)(26005)(6506007)(7696005)(110136005)(76176011)(6116002)(486006)(102836004)(86362001)(2906002)(22452003)(316002)(3846002)(66066001)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR00MB0349;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-microsoft-antispam-message-info: VZ6rt/9fuAG+TDihvG8VmqTsVzx1K7oKXq+iIW1b54AkID6uxT+DIOqMwNvggx7NZMTyKzi8DvtCjLjZdS4++O+ELbBYVs14CV8kcIdWy/eKTjvz3XOurtEQKcmW1OAAsdNMUwaarQRG26lS9ZbbHMCWU/DSFe5vVg4qfEv/moWJPgeCKQ8Wg6TF+58UEYv7ZhLaf2FMO6ZL7ZTaKShmCWvGFSgKfVBguMgVAR6cGwdZBt/9Pv7Clmww2MxdoyiYWHf55d9pDz+QnqfquXRmlIUh1+vG5GDWHE/6/sMv+vFf4NV+i8EYb/42ZR6WbOU1/ZqKg9hfdYKE+V8tMUTInJY0yWlyvoBH4q6YrAEHVQM=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: a90cf635-9e69-4aec-9b4b-08d63a14ef89
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Oct 2018 00:58:11.0202 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR00MB0349
Archived-At: <>
Subject: Re: [Ace] WGLC for draft-ietf-ace-authz
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 25 Oct 2018 00:58:19 -0000

IT CAN'T BE A COINCIDENCE:  There's clearly a relationship between many of the CBOR numeric values used in this this specification and corresponding CBOR Web Token (CWT) claim identifiers, but oddly, the relationship is currently unspecified and the goals behind it are undefined.  The spec should be augmented to make the nature and goals of this relationship explicit.  I infer that there's such a relationship because the Mapping Parameters to CBOR in Section 5.6.5 apparently carefully do not overlap with the values registered in the IANA CWT Claims registry at  The Introspection mappings in Section 5.7.4 apparently carefully use the same values as CWT for the same things, but then adds additional values.  And some of these values are the same as values proposed for the CWT Claims registry in 8.13.  This has to be more than a coincidence but the spec doesn't currently say why.

Per my earlier reviews of the ace-authz spec, I believe that the ACE OAuth parameters should all be registered in the CWT Claims registry because of the possibility of them being used in signed requests in a manner analogous to  The parameters need to be registered to avoid future claim number conflicts.  While conflicts have clearly been carefully avoided to date, they will inevitably occur in the future unless the values are actually registered.  Please do so.

DON'T SQUAT ON NUMERIC REGISTRY VALUES:  Please change all instances of numbers to be assigned by designated experts in existing registries from specific values to "TBD".  For instance, all the values for the CWT Claims Registry in Section 8.13 (currently 12, 16, and 17) should be changed to TBD.  Our chair, Jim Schaad has been a vigorous advocate of not squatting in my past interactions with him as a Designated Expert and I believe would support this request.  Likewise, the "19" in the CoAP Content-Format Registration in Section 8.15 should become TBD.

req_aud: Several examples use the "req_aud" parameter without defining it.  Doesn't this duplicate the "resource" parameter defined by  If so, please delete this parameter and use "resource".  If not, say how it is different and why the differences are necessary.

rs_cnf:  There isn't a clear normative definition of this parameter.  It's mentioned obliquely but its purpose, syntax, and semantics should be plainly stated (as with each other newly defined parameter).

The proposed numbers in Figures 12 and 16 contain mismatches.  For instance, token_type is "14" in Figure 12 in Section 5.6.5 and "13" in Figure 16 in Section 5.7.4.  There's too much alignment for it to be a coincidence but if you intend alignment, please say so explicitly and fix the alignment.  The proposed ongoing alignment should also be described in the registration instructions for the Designated Experts.

				-- Mike

P.S.  Per my earlier reviews of this specification, in my view as a Designated Expert for the CWT Claims registry, I believe that it's not appropriate to use up rare single-byte identifiers for most of the OAuth parameter encodings specified in 5.6.5.  I could be persuaded that "scope" merits one of these rare numbers, but "profile", "error", "grant_type", "access_token", and "token_type" probably do not, as they are application-specific and not of general applicability.  I also believe that some of the other Designated Experts for this registry agree with me.

-----Original Message-----
From: Ace <>; On Behalf Of Jim Schaad
Sent: Monday, October 8, 2018 2:35 PM
Subject: [Ace] WGLC for draft-ietf-ace-authz

The chairs believe that the set of documents dealing with the OAuth framework for constrained environments is nearing the point that we should
be able to advance it to the IESG for publication.   We therefore want to
have a full list of issues that need to be dealt with at the Bangkok meeting.

This starts a 2 week WGLC for draft-ietf-ace-authz

We know that the following issues are outstanding:

*  There are a couple of esoteric issues around listing AS servers associated with resources in a Resource Directory

Jim & Roman

Ace mailing list