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

Jim Schaad <ietf@augustcellars.com> Thu, 25 October 2018 21:43 UTC

Return-Path: <ietf@augustcellars.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 89B23124BE5 for <ace@ietfa.amsl.com>; Thu, 25 Oct 2018 14:43:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 bdZvzuXrR_tn for <ace@ietfa.amsl.com>; Thu, 25 Oct 2018 14:43:50 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F5FD130E50 for <ace@ietf.org>; Thu, 25 Oct 2018 14:43:50 -0700 (PDT)
Received: from Jude (192.168.1.162) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 25 Oct 2018 14:38:43 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: 'Mike Jones' <Michael.Jones@microsoft.com>, <ace@ietf.org>
References: <065b01d45f4e$b8d372a0$2a7a57e0$@augustcellars.com> <SN6PR00MB0301580A2D802AB0F559A170F5F70@SN6PR00MB0301.namprd00.prod.outlook.com>
In-Reply-To: <SN6PR00MB0301580A2D802AB0F559A170F5F70@SN6PR00MB0301.namprd00.prod.outlook.com>
Date: Thu, 25 Oct 2018 14:43:22 -0700
Message-ID: <018d01d46cab$c23b9880$46b2c980$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJ+t/TOEyNDXiHpy0JlO2vTIlTnzAMjXR8Ho8LLuLA=
Content-Language: en-us
X-Originating-IP: [192.168.1.162]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/vcLgIvKJjQJ7CWD1Qydy_jkbas4>
Subject: Re: [Ace] WGLC for draft-ietf-ace-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, 25 Oct 2018 21:43:52 -0000


> -----Original Message-----
> From: Mike Jones <Michael.Jones@microsoft.com>;
> Sent: Wednesday, October 24, 2018 5:58 PM
> To: Jim Schaad <ietf@augustcellars.com>;; ace@ietf.org
> Subject: RE: [Ace] WGLC for draft-ietf-ace-authz
> 
> 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
> https://www.iana.org/assignments/cwt/cwt.xhtml.  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.

You are right it is not a coincidence.  You have been asking that they match
up for quite a while and at one time the authors tried to do this.  This
does not mean that it should be that way.

> 
> 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 https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-17.  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.

This is something that I think is incorrect - see my mail on 10/3.


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

If they are creating a new registry - which means not going in the CWT claim
registry then it makes sense for them to assign numbers.  I agree on the
content format registration unless they have gotten an early registry done.


> 
> req_aud: Several examples use the "req_aud" parameter without defining it.
> Doesn't this duplicate the "resource" parameter defined by
> https://tools.ietf.org/html/draft-ietf-oauth-resource-indicators-01?  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.

Yet another reason why we should not be combining these registries into a
single one in my opinion.

Jim


> 
> -----Original Message-----
> From: Ace <ace-bounces@ietf.org>; On Behalf Of Jim Schaad
> Sent: Monday, October 8, 2018 2:35 PM
> To: ace@ietf.org
> 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:
> 
> draft-ietf-ace-authz
> *  There are a couple of esoteric issues around listing AS servers
associated
> with resources in a Resource Directory
> 
> 
> Jim & Roman
> 
> 
> 
> 
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace