Re: [Ace] draft-ietf-ace-oauth-authz

Ludwig Seitz <ludwig.seitz@ri.se> Thu, 28 February 2019 13:50 UTC

Return-Path: <ludwig.seitz@ri.se>
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 131F0130E9C; Thu, 28 Feb 2019 05:50:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=risecloud.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 EuVePbb2aLFp; Thu, 28 Feb 2019 05:50:54 -0800 (PST)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80082.outbound.protection.outlook.com [40.107.8.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67036130E69; Thu, 28 Feb 2019 05:50:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=RISEcloud.onmicrosoft.com; s=selector1-ri-se; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1BjYlV6iJfkvWUW+OLq3f/FDuU9Mr711aroQ2BtUO1I=; b=XLw4FWcsE7v9odK6Xirk6TnOK3idUVUFktaUxpykUtk6R/QP6HjqTCpAuqJGya4QIO86oEe0TkQ5YJfAaB0Bx1uNbBFFzfXiRxaKH659/QAwh2NzrwhrgwRX2XGAb1OsaaMiGiYgZCwUcmoK8fdHGF7FhCeq4NzsoFXjGDc++TI=
Received: from VI1P189CA0015.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:2a::28) by HE1P189MB0476.EURP189.PROD.OUTLOOK.COM (2603:10a6:7:56::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.16; Thu, 28 Feb 2019 13:50:50 +0000
Received: from HE1EUR02FT022.eop-EUR02.prod.protection.outlook.com (2a01:111:f400:7e05::208) by VI1P189CA0015.outlook.office365.com (2603:10a6:802:2a::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.16 via Frontend Transport; Thu, 28 Feb 2019 13:50:50 +0000
Authentication-Results: spf=pass (sender IP is 194.218.146.197) smtp.mailfrom=ri.se; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=ri.se;
Received-SPF: Pass (protection.outlook.com: domain of ri.se designates 194.218.146.197 as permitted sender) receiver=protection.outlook.com; client-ip=194.218.146.197; helo=mail.ri.se;
Received: from mail.ri.se (194.218.146.197) by HE1EUR02FT022.mail.protection.outlook.com (10.152.10.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.20.1643.21 via Frontend Transport; Thu, 28 Feb 2019 13:50:49 +0000
Received: from [10.112.134.122] (10.100.0.158) by sp-mail-2.sp.se (10.100.0.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Thu, 28 Feb 2019 14:50:48 +0100
To: Jim Schaad <ietf@augustcellars.com>, <draft-ietf-ace-oauth-authz@ietf.org>
CC: 'ace' <ace@ietf.org>
References: <000201d4cbd5$d6837900$838a6b00$@augustcellars.com> <a4e42204-df48-f550-7e98-095bdbdd9ff3@ri.se> <00b001d4cd2c$c361f920$4a25eb60$@augustcellars.com> <c0868edf-7914-fb86-6853-3615b608527f@ri.se> <019901d4cdf3$f11aa7f0$d34ff7d0$@augustcellars.com>
From: Ludwig Seitz <ludwig.seitz@ri.se>
Message-ID: <3cd774b6-88f9-e3da-4326-c68be3f920d4@ri.se>
Date: Thu, 28 Feb 2019 14:50:48 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <019901d4cdf3$f11aa7f0$d34ff7d0$@augustcellars.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060604020204080801090008"
X-Originating-IP: [10.100.0.158]
X-ClientProxiedBy: sp-mail-1.sp.se (10.100.0.161) To sp-mail-2.sp.se (10.100.0.162)
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:194.218.146.197; IPV:NLI; CTRY:SE; EFV:NLI; SFV:NSPM; SFS:(10009020)(396003)(136003)(376002)(346002)(39860400002)(2980300002)(51444003)(189003)(199004)(478600001)(74482002)(65826007)(93886005)(6246003)(4326008)(33964004)(76176011)(53936002)(64126003)(106002)(58126008)(97736004)(316002)(16586007)(16576012)(110136005)(40036005)(22756006)(104016004)(126002)(2616005)(476003)(68736007)(11346002)(446003)(186003)(5024004)(14444005)(16526019)(44832011)(486006)(71190400001)(229853002)(336012)(65956001)(2906002)(65806001)(106466001)(36756003)(356004)(305945005)(8936002)(386003)(81156014)(81166006)(26005)(8676002)(568964002)(235185007)(22746008)(5660300002)(69596002)(77096007)(3846002)(6116002)(86362001)(84326002)(31686004)(53546011)(7736002)(31696002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1P189MB0476; H:mail.ri.se; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1;
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: a230c8eb-cb1e-4b7d-a42c-08d69d83bf84
X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4608103)(4709054)(2017052603328)(7153060)(7193020); SRVR:HE1P189MB0476;
X-MS-TrafficTypeDiagnostic: HE1P189MB0476:
X-Microsoft-Exchange-Diagnostics: 1; HE1P189MB0476; 20:exI9rDuJOnv7L4VxVrVTW/CZ5Bdjcc1QviokrRKFQajAfJ6Rkw7yZmFtHglU4IKmclpdZytqF7w3iEQNuQHhEjbArKCcptmi8h0RlWbLr2kXr21yioGhhXZsZrDxtWtLFff/rPGuwCZ7uTXR5mCVBqj+iwdGog3EsRpCy/+qctEWUNjbZRECOcF3r+HZHaCZuPHREUXCKNwICZTwmjR29jryQ6FCxsBS6dEYld5zLqpB3BRJc9A4HHnb6A/wah7w
X-Microsoft-Antispam-PRVS: <HE1P189MB04761CF6D893F6F1CDF4163082750@HE1P189MB0476.EURP189.PROD.OUTLOOK.COM>
X-Forefront-PRVS: 0962D394D2
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; HE1P189MB0476; 23:YFaxvYxHkT0MqXozQG1/J25deRiaAfCQK1KNLS/Jo?= =?us-ascii?Q?zJ9HsNaHtdPf5XDBZ1KksTl/NIUepU6AkERcphzMcTekcyz7GPq0S80H4kS6?= =?us-ascii?Q?7TIZmLpD7fiISm5s3FcNoOhicaYp289dL6C/Ykwpu7h1/YLYuFmoyOWMrukN?= =?us-ascii?Q?l0Op3PyZR6W9TpqOoQntLufjEJ5j9wudLiWSJJeDOLKKzVYQa8Bm7peDsWAw?= =?us-ascii?Q?K/+nMYiOLBxRFQ2h97onXooyGofXS0VYy+Jf7xMkP3ff/LbSiCyUzKeINdYx?= =?us-ascii?Q?BJmizwFIuOyJIuPPopO2mKhuAH2kJX8GakVbw6Sii3E4KYqceSo+oUBy0y8G?= =?us-ascii?Q?WEhRW3t+NkXRN8dNJvMuwnQhIAR5jDVUxpIWzgx4XqU0IbWUroaJhvTqmeAz?= =?us-ascii?Q?54ooENlbVbxhAaeAL9+oFz4n18eY3Tu0fH0VZc1vg6/m5BQpHaXsIKArApgU?= =?us-ascii?Q?Bhixwl9DsiNyIqg0VUbiQotZPxwlNvCweP/7Hle2kzpXynPvuNpXBoDC/Y8P?= =?us-ascii?Q?pSzGbCjBn3moi8VKy5YgzGBGYe64bp7l1jjQTrqPtz/TvDspL4QoKJCscYsT?= =?us-ascii?Q?TzRhKGg8uro2H8q36boaoyCbNsx0OFiLU03OMngbCUyBPmNCaaa4hvqJqvuK?= =?us-ascii?Q?5aK5aeXRbhnrLk+FUSN0i3Y81tV2olMh4hhn/zQkTWE/RHIT9gdpSqYJamdr?= =?us-ascii?Q?0aobVekPr+aOmxF3S3e+gZ7Y0MLP3wYoyEI3Vc3vEP87T0lLHJCnQ6TXdAkN?= =?us-ascii?Q?G/h9+yRZQ7TvciDnJiThCgr9z6kJyQWGnZd9xFFoVLKeW0BZuBrop6ELaNor?= =?us-ascii?Q?+by9j5vzxwpvk4IvXfVaZInxqp2OWU77F38QIY/YX59OzHU+F2zTJoYhwKj4?= =?us-ascii?Q?rYhbAQi4r97Lgt+PaJfK3L8GJn9LZZR78fnqmumIy3DlAjeTwMxpMX9DEq3z?= =?us-ascii?Q?f9LOb911IBsaM88i3NCaQykgo9fWKnzlSgqnFZmhIDOJiGCe7E95XuxDUlPN?= =?us-ascii?Q?mlihHY+ZTiH8cgT6te6qPj0M6zY43G72P0IB3aELlc8xXNRXKH8vDqUmasD3?= =?us-ascii?Q?k2EReoDHlCBQmP89UTmgcs5uy9kTXLuuZ0eDbqeh7G4oKBsCfUdCROTno+IF?= =?us-ascii?Q?uzUk38FxnAgYeibmI/7xWHTHMJMj0z+8h7vGJ2Tc9SyzgmwE+lpsXNTU7aI6?= =?us-ascii?Q?vhcmMeAHxnv4TRgUDqTtDi56g0xoBTGd0m8wDIErb5hGm6YuSEc4zIDxOEkM?= =?us-ascii?Q?Os7D2QHhzth4P17EB7IXCeiIM0H/IVe9e7pQWEK1aO9FfzgZ8kDtAh/lJJEM?= =?us-ascii?Q?DItg8D8TxApHAcq9YOe7qdUOdQEY+5drUTQJ+kQ4TPpGiTROghV/XWf5CDOc?= =?us-ascii?Q?I1C4d4lDdbEnvkb761BEwywWBYHP0v8OQctD1y49Mv4i18fVUQBJAu62vGwU?= =?us-ascii?Q?OKw7UKw+8OdR5ApeXs1VBJ26RYBOcFwPY4QPTNHFh1J1N3cwylI0gdmOLjaB?= =?us-ascii?Q?gKLFDv2K/jHKjZXTIdwl85xyjRMFbciphQyHA+70jKEaeUba7Ghd2ghRMQUu?= =?us-ascii?Q?cr+EmrHQtHNeSJ/YkJ0MAq1UJQuQfogDJVubVg=3D?=
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Message-Info: cX4Q0q6xmej3SilNSXFGIa9zJL7CeVhFPwfN5+8XQFK/YVse95n6aLBDseHIRV1AmfnxM+q+8nnK9rMtNoXdZqiAbMGtdwHYw0wDPYP8e8LmlbhPHySsP4+f0hktCEwr1AhOc1SB2hX2gxraNDIQTJ0PAIRfy/kS9rUghmfq7Gi+pjYSP2XFoFDOPBpHZGAstOWEG1HzgU/plQteELijoLOJCXa0s9p1Qp36M/Yc3KeDveTbpO13mauFzSZSu6oFQn3MGavDoLf8RlhdC3qTC3uGPHBFSXMZyjosmQqAureJfNIMify4cgBtFPp9jyS2e9yRvNQQsNnJNyij1o305yW1oI6QMTYEMcg4EcZHXYYrYvCj+FPgKU/o58taidLI18L5gl3EZy9pUx+Kt/f0yicneyprnSER1hEgafvAayM=
X-OriginatorOrg: ri.se
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Feb 2019 13:50:49.7260 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: a230c8eb-cb1e-4b7d-a42c-08d69d83bf84
X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5a9809cf-0bcb-413a-838a-09ecc40cc9e8; Ip=[194.218.146.197]; Helo=[mail.ri.se]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1P189MB0476
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/VWfrkdYnHFp5mUz796EbIy8wmIM>
Subject: Re: [Ace] draft-ietf-ace-oauth-authz
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: Thu, 28 Feb 2019 13:50:57 -0000

On 26/02/2019 17:54, Jim Schaad wrote:

>>
>>>>> 3. In section 8.3 - Is/Should there be a requirement that the
>>>>> error also be registered in an OAuth registry?  If so then this
>>>>> needs to be part of the expert reviewer instructions on this
>>>>> registry.
>>>>
>>>> The expert reviewer instructions already state this:
>>>>
>>>> "Since a high degree of overlap is expected between these
>>>> registries and the contents of the OAuth parameters registries,
>>>> experts should require new registrations to maintain a reasonable
>>>> level of alignment with parameters from OAuth that have comparable
>>>> functionality."
>>>>
>>>> This includes the error registry, do you think this is
>>>> sufficiently clear or should I elaborate?
>>>
>>> The question I had was the difference between SHOULD and MUST be
>>> registered.  The text there says - try and keep them in sync, but if
>>> they are not it is not a problem.   If that is what you want then
>>> this is not a problem, I was just validating this.
>>
>> The intention of the "should require ... a reasonable level of
>> alignment" was "try and keep them in sync, but if they are not you need
>> a good reason for this".
>>
>> Your alternate interpretation makes me think the text is not worded
>> strongly enough.
> 
> I think that this is basically the same thing.   The only thing that you might want to add is some guidance on what constitutes a good reason.

Ok how about this:

"... experts should require new registrations to maintain alignment with 
parameters from OAuth that have comparable functionality.  Deviation 
from this alignment should only be allowed if there are functional 
differences, that are motivated by the use case and that cannot be 
easily or efficiently addressed by comparable OAuth parameters."


>>>>
>>>>>
>>>>> 4. In section 8.4 - Is there a reason to require a specification
>>>>> for this registry?  Should it be sufficient to have somebody
>>>>> request that a mapping be registered and the DE approves it?  The
>>>>> previous comment would apply
>>>> to
>>>>> all of the mapping registries that are just mappings.
>>>>>
>>>> The idea is to prevent the squatting of low byte count
>>>> abbreviations by parameters that are not frequently used, thus
>>>> there is a range of different policies for different integer
>>>> abbreviation number ranges. (note: I'm following the example of the
>>>> CWT specification here)
>>>
>>> Not requiring a document to exists could still allow this.  IANA
>>> would still have the DE approve the assignment.
>>>
>>
>> Ok so you mean not having "specification required" for -65536 to -257
>> and 256 to 65535 and not having "standards action" for -256 to 255 would
>> be ok?
>>
>> Note that this would be different from the policy in RFC 8392 (CWT).
> 
> Yes I understand that this is different from CWT.  When looking at the registries you basically would write a specification which contains the following text:
> 
> If, for example , in section 8.4 it was already registered in the OAuth registry, then the document would boil down to:
> 
> Please assign a number in the "OAuth Grant Type CBOR Mappings" registry with the following properties:
> Name:  grant_type_name
> CBOR Value: TBD
> Reference: [This document]
> Original Specification: [The document for grant_type_name] in the "OAuth Grant Type" registry.
> 
> This seems like it is really overkill to have to produce a full specification with of one page when an email to IANA would seem to have the same info.   If you were defining a new grant type, then a full spec would be useful but it would also be expected to do the registration in the "OAuth Grant Type" registry as well as in this registry.
> 

Ok now I get what you were going for. Sorry for the slow uptake, and you 
are indeed right. I will go through the mapping IANA sections and redue 
the applicable policies to "expert review required" and "private use" 
based on the number ranges.

/Ludwig


-- 
Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51