Re: [Ace] Review of draft-ietf-ace-oauth-params-00

Ludwig Seitz <> Wed, 24 October 2018 07:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E8D3112F1A2 for <>; Wed, 24 Oct 2018 00:39:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7bsPuagrgK9i for <>; Wed, 24 Oct 2018 00:39:40 -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 8BB581293FB for <>; Wed, 24 Oct 2018 00:39:40 -0700 (PDT)
Received: from 1gFDlS-000XxL-VD by with emc1-ok (Exim 4.90_1) (envelope-from <>) id 1gFDlS-000XyP-Vu for; Wed, 24 Oct 2018 00:39:38 -0700
Received: by emcmailer; Wed, 24 Oct 2018 00:39:38 -0700
Received: from [] ( by with esmtps (TLSv1.2:ECDHE-RSA-AES128-SHA256:128) (Exim 4.90_1) (envelope-from <>) id 1gFDlS-000XxL-VD for; Wed, 24 Oct 2018 00:39:38 -0700
Received: from [] ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Wed, 24 Oct 2018 09:39:38 +0200
To: <>
References: <>
From: Ludwig Seitz <>
Message-ID: <>
Date: Wed, 24 Oct 2018 09:39:38 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: []
X-ClientProxiedBy: ( To (
X-Proto: esmtps
X-TLS: TLSv1.2:ECDHE-RSA-AES128-SHA256:128
X-Virus-Status: Scanned by VirusSMART (c)
X-Virus-Status: Scanned by VirusSMART (s)
X-PolicySMART: 14510320
Archived-At: <>
Subject: Re: [Ace] Review of draft-ietf-ace-oauth-params-00
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: Wed, 24 Oct 2018 07:39:43 -0000

On 23/10/2018 21:09, Hannes Tschofenig wrote:
> Hi all,
> I read through draft-ietf-ace-oauth-params-00 and have a few comments.
> 1) I believe the document should explain in more detail about how it 
> fits into the rest of the OAuth PoP token work.

Ok I can update the introduction.

> The story essentially is that we have the HTTP-based transport in the 
> OAuth WG and we have the CoAP-based transport
> in ACE. draft-ietf-ace-oauth-params-00 is about registering the 
> necessary parameters for use with CoAP only.
> Neither the abstract nor the intro says this.

Actually at the moment it is about registering necessary parameters for 
both HTTP and CoAP and whatever other transport you can want, since when 
I wrote it draft-ietf-oauth-pop-key-distribution was dormant.

> 2) 'req_aud' parameter
> At the last IETF OAuth meeting in Montreal we agreed to adopt a new 
> document, called resource indicators, and it can be found here:

I'll have a look at that draft. How close is it to WGLC?

> 3) 'req_cnf' parameter
> Changing the name of the parameter name from the previous 'cnf' is good 
> and that was also requested at the last IETF due to the potential 
> confusion with the 'cnf' claim name. However, I believe the semantics is 
> different to the semantics defined in 
> draft-ietf-oauth-pop-key-distribution. Unless I misunderstand but the 
> relevant text regarding the req_cnf parameter content is this:
>     o  "req_cnf" in the token request C -> AS, OPTIONAL to indicate the
>        client's raw public key, or the key-identifier of a previously
>        established key between C and RS that the client wishes to use for
>        proof-of-possession of the access token.
> For example, in draft-ietf-oauth-pop-key-distribution there is no key 
> identifier passed from the client to the server when making the request 
> for a PoP token. Instead, the server just mints one (along with the 
> symmetric key) and sends it to the client.

Weird, because in the RFC7800 there is a cnf claim with just a key-id. I 
thought that you would want to be able to do something similar when 
requesting a specific, previously known key.

> PS: Why was a standalone document written instead of leaving the 
> parameters in the ACE-OAuth framework spec? I guess there are reasons 
> (which I may have missed).

The idea was that OAuth could obsolete that document when they sort the 
pop stuff out, without obsoleting the ACE framework. Thus a different 
standalone document.


Ludwig Seitz, PhD
Security Lab, RISE
Phone +46(0)70-349 92 51