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

Jim Schaad <> Thu, 25 October 2018 21:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 89B23124BE5 for <>; Thu, 25 Oct 2018 14:43:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bdZvzuXrR_tn for <>; Thu, 25 Oct 2018 14:43:50 -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 4F5FD130E50 for <>; Thu, 25 Oct 2018 14:43:50 -0700 (PDT)
Received: from Jude ( by ( with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 25 Oct 2018 14:38:43 -0700
From: Jim Schaad <>
To: 'Mike Jones' <>, <>
References: <065b01d45f4e$b8d372a0$2a7a57e0$> <>
In-Reply-To: <>
Date: Thu, 25 Oct 2018 14:43:22 -0700
Message-ID: <018d01d46cab$c23b9880$46b2c980$>
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: []
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 21:43:52 -0000

> -----Original Message-----
> From: Mike Jones <>;
> Sent: Wednesday, October 24, 2018 5:58 PM
> To: Jim Schaad <>;;
> 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
> be augmented to make the nature and goals of this relationship explicit.
> 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
> 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
> to  The parameters
> need to be registered to avoid future claim number conflicts.  While
> have clearly been carefully avoided to date, they will inevitably occur in
> 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
> 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
> 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
>  If
> 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
> 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
> Expert for the CWT Claims registry, I believe that it's not appropriate to
> 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
> 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.


> -----Original Message-----
> From: Ace <>; On Behalf Of Jim Schaad
> Sent: Monday, October 8, 2018 2:35 PM
> To:
> 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
> 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
> with resources in a Resource Directory
> Jim & Roman
> _______________________________________________
> Ace mailing list