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

Jim Schaad <> Sun, 19 January 2020 23:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 53F0112004D; Sun, 19 Jan 2020 15:35:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TD3CytTO6EoK; Sun, 19 Jan 2020 15:35:21 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EC04D12001E; Sun, 19 Jan 2020 15:35:20 -0800 (PST)
Received: from Jude ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 19 Jan 2020 15:35:12 -0800
From: Jim Schaad <>
To: 'Brian Campbell' <>, 'Seitz Ludwig' <>
CC: 'Ludwig Seitz' <>, 'Roman Danyliw' <>, <>, 'Daniel Migault' <>, 'Benjamin Kaduk' <>, <>, <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Date: Sun, 19 Jan 2020 15:35:10 -0800
Message-ID: <018601d5cf21$19cec7b0$4d6c5710$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0187_01D5CEDE.0BAC4B00"
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AQEhd6Yle2bwoestBETa2w8Xfe67igHXMmInAunJ6fMCAFODFgH28139AnlL6EWpAbvhkA==
X-Originating-IP: []
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: Sun, 19 Jan 2020 23:35:24 -0000

I have managed to merge most of my code that deals with the confirmation claim and I have ended up with a single problem when dealing with confirmations.  If this is going to get fixed, it needs to get fixed in draft-ietf-ace-cwt-proof-of-possession prior to this document finishing processing the EDIT process in the RFC editor.


All of the items that can appear in a confirmation claim are unique except for the ‘kid’ claim method.  This field is defined as being a text field for JWT (RFC 7800), but it is defined as being a binary field for CWT.  It is a text field when defined in RFC 7800.  I do not anticipate any issues for the definition of a thumbprint as COSE is using a very different format for the definition of thumbprints which will led to a different naming convention.






From: Brian Campbell <> 
Sent: Monday, January 13, 2020 10:01 AM
To: Seitz Ludwig <>
Cc: Ludwig Seitz <>de>; Roman Danyliw <>rg>;; Daniel Migault <>om>; Jim Schaad <>om>; Benjamin Kaduk <>du>;;
Subject: Re: [Ace] Requested review for IANA registration in draft-ietf-ace-oauth-params


Thanks Ludwig,


On Sat, Jan 11, 2020 at 8:20 AM Seitz Ludwig < <> > wrote:



From: Ace < <> > On Behalf Of Brian Campbell




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


[LS] No you are not missing something, I just got sloppy trying to do a quickfix.


Background: The reason for defining both JSON and CBOR-based interactions is that you might have a powerful client communicating with a constrained RS. The client does vanilla OAuth interactions with the AS via the token endpoint, but is served a CWT and associated ACE parameters (cnf, ace-profile, …) for interaction with the RS. 

The pop-key should decode to the same binary representation regardless of whether it came in a JSON or CBOR wrapper.


Okay, so noting that there is cnf content that doesn't decode to a key, I suppose I'll just take it on faith that all the relevant or expected usages involve a key that can be represented in both CBOR and JSON. 

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.