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

Benjamin Kaduk <> Tue, 17 August 2021 03:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A586A3A1963 for <>; Mon, 16 Aug 2021 20:49:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PL_L0kFtNt3C for <>; Mon, 16 Aug 2021 20:49:56 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EB4B83A1951 for <>; Mon, 16 Aug 2021 20:49:55 -0700 (PDT)
Received: from ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id 17H3nl9f012417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 16 Aug 2021 23:49:51 -0400
Date: Mon, 16 Aug 2021 20:49:46 -0700
From: Benjamin Kaduk <>
To: Ludwig Seitz <>
Cc: "" <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
Archived-At: <>
Subject: Re: [Ace] Nits in draft-ietf-ace-oauth-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: Tue, 17 Aug 2021 03:49:59 -0000

On Wed, Aug 11, 2021 at 06:42:47AM +0000, Ludwig Seitz wrote:
> Hello Ace,
> I'm currently dealing with some nits in draft-ietf-ace-oauth-authz that I have discovered during the final IANA check. For one of them I need group feedback: 
> The draft defines a CBOR abbreviation for the Introspection parameter 'cti' which is the CWT identifier defined in RFC 8392, however it turns out that parameter was never defined as Introspection response parameter, it only exists as CWT claim.
>  Can this draft just add 'cti' to the OAuth Token Introspection Response parameters without affecting the progress of the draft at this stage?

The relevant OAuth registry operates under the "specification required"
policy.  Since we don't currently talk about "cti" in Section 5.9.2 that
covers the other introspection response parameters (nor elsewhere that I
could find), I think this means we'd need to add a new paragraph or so of
text to describe the use of this introspection response parameter (i.e., by
analogoy to the existing "jti" introspection response parameter).  That's
enough new text that I'd want to see a specific all for comment on the WG
list to confirm consensus (probably two weeks, since we're already in the
RFC Editor queue and there is not much slack time later in the process).

I'll also float the topic with the IESG and get a better handle on whether
an IETF-wide call is needed as well (myself, I don't see a need, since the
work as a whole pretty clearly envisions that this is part of it).

Thanks for catching this, and sorry that it is not easier to resolve.