Re: [oauth-ext-review] [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params

Brian Campbell <> Fri, 10 January 2020 20:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DE0FE120100 for <>; Fri, 10 Jan 2020 12:16:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jfnEgiBMPc0X for <>; Fri, 10 Jan 2020 12:16:34 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ED35312008A for <>; Fri, 10 Jan 2020 12:16:33 -0800 (PST)
Received: by with SMTP id o13so3406894ljg.4 for <>; Fri, 10 Jan 2020 12:16:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cSkYyVX1FsV5mHagG2cEgfRLsc7a00l4yr6Es6a3yNI=; b=UpxNAhBB1pXqW/xUqY/r1ZDXRdvKndC0w1dX6Ihp9r9nIM3DqXp6Y8MOPVCJIUu62V b2UnJCoxrIjYdS3ukzpJkFFUMu1u3raTdisXOnpmynSTAV9zHU9HER1mfDPBcunJPODf 1lPJmw6SjT3nPHdGIdowMCHIaHL5lCwfmMc9sxH3VwUMDyRE3XDUqHlhlc8Y078BPfyD veWVzYzyPG15tPYEO7R42UkSb7P4iKrLCqYpfeXzyWa+uCc2nH7ZC9YmpJ8sTLvRAazZ 7/UufqW+zxLWAtASFdxn5b9RmVQ8pFIETcPMSr8o4Iu78ix144QXyFY6NhADu4IuVvoo Llwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cSkYyVX1FsV5mHagG2cEgfRLsc7a00l4yr6Es6a3yNI=; b=HDRYaEfaCLczukW26pWcPKYPU+jI4gQHCVpblfZMR6A6h3LaGMs2Zm0H+G08EoRYeI d/7AHDxeo7O1bekeaYuRxHXqqRJj92yy/NNkTqHeecFMcwf/U0qF168g1gCnOvETZzOM uqPC11bmAr71Gn2RduB37/qqT42WgFkKcvGcbaPLusqfioE+wa7lypMcByfstTc6CRcM zCjKTcik+fItOL6j9DtjRUdNyupjAROc8xdM2Xdb39yJ9pMkft20mzo6q3QKsxYGLTOh w5mEWI4NAM/luPPE8z83Q3V/ieyXvsWS1H+RnyEuXRqohVHiAJGZqYkcShvg0hxMuPLc u51Q==
X-Gm-Message-State: APjAAAXXBDG/b2fkHnQsxdWAidjgSG8lYAKbR3s44pJsJMbwqnCFDolo z4czHfiOG44C8+fpYA5HkGraxV0MsrVp38EdRumLd93kvxlpQnf+W2I/kX+GoHL1nsmKfuyQxYr 0KoDed+oqGKlO0OJziL5xRc1AKXRJ
X-Google-Smtp-Source: APXvYqxBCeG5dJMFLRuEOGIz/IL6IKZo6/ybyOGMOjBeLVkzZNdZjXQYhVQX1uLcsY9xdwRmQWnqlMcp6bAtW5rXbQc=
X-Received: by 2002:a2e:94c8:: with SMTP id r8mr3716097ljh.28.1578687391671; Fri, 10 Jan 2020 12:16:31 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Brian Campbell <>
Date: Fri, 10 Jan 2020 13:16:05 -0700
Message-ID: <>
To: Ludwig Seitz <>
Cc: Roman Danyliw <>,, Daniel Migault <>, Jim Schaad <>, Benjamin Kaduk <>, "" <>,
Content-Type: multipart/alternative; boundary="000000000000314267059bcecdb3"
Archived-At: <>
Subject: Re: [oauth-ext-review] [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Review of proposed IANA registrations for OAuth." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 10 Jan 2020 20:16:39 -0000

That certainly takes care of the registry conflict problem, thanks.

I'm a little confused, however, and uncertain if that changes the syntax in
a way that maybe wasn't intended?

-09 had:
     OPTIONAL.  This field contains information about the proof-of-
     possession key that binds the client to the access token.  Values
     of this parameter follow the syntax of the "cnf" claim from
     section 3.1 of [I-D.ietf-ace-cwt-proof-of-possession].  See
     Section 5 for additional discussion of the usage of this

while -10 has:
  Furthermore the AS can use the "cnf" parameter specified in section
  9.4 of [I-D.ietf-oauth-mtls] in an introspection response.  For CBOR-
  based interactions the AS MUST use the parameter mapping specified in
  Figure 5.

So in -09 the "cnf" Introspection Response Parameter was the following the
syntax of the "cnf" claim from PoP Key Semantics for CWTs
[ID.ietf-ace-cwt-proof-of-possession] and in -10 it's following the syntax
of PoP Key Semantics for JWTs [RFC7800] transitively via
[I-D.ietf-oauth-mtls] reference. I think I understand that the two PoP key
semantics documents are conceptually the same or similar. But I don't know
that the syntax is the same? Figure 5
<> is
pointed to for mapping between CBOR and JSON but it only has mappings for
the main top level parameters. Maybe I just don't get it or am missing

On Tue, Jan 7, 2020 at 12:46 PM Ludwig Seitz <> wrote:

> On 2019-12-23 22:32, Brian Campbell wrote:
> > The OAuth Token Introspection Response registry
> > <
> >
> > already has an entry for "cnf", which makes the first request in
> >
> > rather problematic.
> >
> OAuth beats us on the finish line again :-(
> I have updated the draft to remove the registration and refer to the
> MTLS draft.
> /Ludwig

_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._