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
- [Ace] WGLC for draft-ietf-ace-authz Jim Schaad
- Re: [Ace] WGLC for draft-ietf-ace-authz Jim Schaad
- Re: [Ace] WGLC for draft-ietf-ace-authz Ludwig Seitz
- Re: [Ace] WGLC for draft-ietf-ace-authz Jim Schaad
- Re: [Ace] WGLC for draft-ietf-ace-authz Benjamin Kaduk
- Re: [Ace] WGLC for draft-ietf-ace-authz Ludwig Seitz
- Re: [Ace] WGLC for draft-ietf-ace-authz Ludwig Seitz
- Re: [Ace] WGLC for draft-ietf-ace-authz Jim Schaad
- Re: [Ace] WGLC for draft-ietf-ace-authz Mike Jones
- Re: [Ace] WGLC for draft-ietf-ace-authz Carsten Bormann
- Re: [Ace] WGLC for draft-ietf-ace-authz Olaf Bergmann
- Re: [Ace] WGLC for draft-ietf-ace-authz Carsten Bormann
- Re: [Ace] WGLC for draft-ietf-ace-authz Michael Richardson
- Re: [Ace] WGLC for draft-ietf-ace-authz Carsten Bormann
- Re: [Ace] WGLC for draft-ietf-ace-authz Jim Schaad
- Re: [Ace] WGLC for draft-ietf-ace-authz Jim Schaad
- Re: [Ace] WGLC for draft-ietf-ace-authz Michael Richardson
- Re: [Ace] WGLC for draft-ietf-ace-authz Ludwig Seitz
- Re: [Ace] WGLC for draft-ietf-ace-authz Ludwig Seitz
- Re: [Ace] WGLC for draft-ietf-ace-authz Ludwig Seitz
- Re: [Ace] WGLC for draft-ietf-ace-authz Ludwig Seitz
- Re: [Ace] WGLC for draft-ietf-ace-authz Mike Jones
- Re: [Ace] WGLC for draft-ietf-ace-authz Ludwig Seitz
- Re: [Ace] WGLC for draft-ietf-ace-authz Jim Schaad
- Re: [Ace] WGLC for draft-ietf-ace-authz Jim Schaad
- Re: [Ace] WGLC for draft-ietf-ace-authz Jim Schaad
- Re: [Ace] WGLC for draft-ietf-ace-authz Mike Jones