Re: [Ace] Resume of discussion at IETF 103 meeting on draft-ietf-ace-oauth-authz

Benjamin Kaduk <> Tue, 13 November 2018 04:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1DD30126F72 for <>; Mon, 12 Nov 2018 20:07:25 -0800 (PST)
X-Quarantine-ID: <GtE2lq8nPGwb>
X-Virus-Scanned: amavisd-new at
X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by[...]
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GtE2lq8nPGwb for <>; Mon, 12 Nov 2018 20:07:22 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DEB50124408 for <>; Mon, 12 Nov 2018 20:07:21 -0800 (PST)
X-AuditID: 12074424-789ff70000000471-4e-5bea4df64911
Received: from ( []) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 2E.BC.01137.7FD4AEB5; Mon, 12 Nov 2018 23:07:19 -0500 (EST)
Received: from (OUTGOING-AUTH-1.MIT.EDU []) by (8.14.7/8.9.2) with ESMTP id wAD47HTG007983; Mon, 12 Nov 2018 23:07:18 -0500
Received: from ( []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) �by (8.14.7/8.12.4) with ESMTP id wAD47DAe008760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 12 Nov 2018 23:07:16 -0500
Date: Mon, 12 Nov 2018 22:07:13 -0600
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: <>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBIsWRmVeSWpSXmKPExsUixCmqrfvd91W0wbIWG4vv33qYLV59ns7q wOSxZMlPJo+lTZuZApiiuGxSUnMyy1KL9O0SuDIOTJnIXDBfveLNxA3sDYzd8l2MHBwSAiYS CycadTFycQgJrGGS2LavkRXC2cgosWLnGSYI5y6TxMp5d1i6GDk5WARUJX4sOcEGYrMJqEg0 dF9mBrFFgOInn35hBpnKLKAo8feSKkhYWCBa4tzWpWAlvEDL1i/5AjZGSMBCYtOfHkaIuKDE yZlPwOLMAloSN/69ZIIYIy2x/B8HiMkpYClx+3s6SIWogLLE3r5D7BMYBWYhaZ6FpHkWQvMC RuZVjLIpuVW6uYmZOcWpybrFyYl5ealFuuZ6uZkleqkppZsYQQHK7qKyg7G7x/sQowAHoxIP 74npL6OFWBPLiitzDzFKcjApifJmPgIK8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuHdafIqWog3 JbGyKrUoHyYlzcGiJM77R+RxtJBAemJJanZqakFqEUxWhoNDSYJXDhiJQoJFqempFWmZOSUI aSYOTpDhPEDDz/qADC8uSMwtzkyHyJ9iVJQS590GkhAASWSU5sH1ghKIRPb+mleM4kCvCPNe BqniASYfuO5XQIOZgAaXvHwOMrgkESEl1cC4efaca/tm55xqb/oVVPlp2zPjvKx1jF7i9QGC bLOSDonrLtfl9hdzDGeanfXIcGuLr/bUB6f2HOdpPlqk6vlys2qibe3eFSF2CiYN654r/zQ3 VPhT9S9LSWDh52kCXVdfsp6U7rksJZQq2rqfzV717VylTb8XRnSIzbw8/fnvJXKucxyEHzgq sRRnJBpqMRcVJwIAL1BIJPsCAAA=
Archived-At: <>
Subject: Re: [Ace] Resume of discussion at IETF 103 meeting on 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, 13 Nov 2018 04:07:25 -0000

[with no hats]

On Mon, Nov 12, 2018 at 04:21:55PM +0100, Ludwig Seitz wrote:
> Hello ACE,
> I wanted to post a resume of the in room discussions from the IETF 103 
> meeting, related to draft-ietf-ace-oauth-authz, for those who missed 
> them and those who want to further comment (sorry for the verbose 
> summary below):
> During my presentation I put up a 7 issues for discussion as follows:
> 1. Use of one-byte CBOR abbreviations for parameters and CWT claims.
> So far there is a consensus between me and Mike Jones on what we think 
> is reasonable.
> This would be summarized here: 
> I was wondering if anyone else wants to weight in on what they consider 
> important parameters & claims for constrained applications that need 
> compact (one-byte) abbreviations in CBOR?
> 2. Unified registry for CWT claims and token/introspection parameter 
> abbreviations
> Currently the draft(s) have aligned the CBOR abbreviations for both CWT 
> claims and token/introspection parameters under one singe number space.
> There were arguments for splitting this up so that we can re-use the 
> same compact one-byte abbreviations in those different "namespaces" i.e. 
> there would be a number range just for CWT claims, and a separate one 
> for introspection and token endpoint parameters.
> Even here I'm interested in additional input.

I have no real data (or argument) here, but my gut feeling is that
eventually there would be desire for them to diverge, which would indicate
cleanly separating them from the start.

> 3. CWT as format for signed protocol messages
> As OAuth is currently working on a number of drafts specifying JWT as a 
> format for encoding request (and response?) parameters wrt. the token 
> and the introspection endpoint, the question was raised whether this 
> should also be done for ACE and CWT.
> My stance here (and I got the impression that the room agreed or at 
> least had no strong opinion against) is that this is absolutely 
> possible, but would best be done in an additional draft in order to not 
> increase the already significant delay of draft-ietf-ace-oauth-authz.

I agree.

> 4. Alignment between "req_aud" and "resource" parameters
> draft-ietf-oauth-resource-indicators proposes a new parameter for the 
> token request called "resource" which specifies the location of the 
> resource or service for which the token is requested. This is supposed 
> to map to the audience claim in the token.
> draft-ietf-ace-oauth-params has in parallel defined the "req_aud" 
> parameter (for "requested audience") which has a somewhat broader 
> definition, roughly speaking "a value that the RS identifies with". This 
> could be a public key, a group identifier or something else, so the key 
> difference is that it is not specifically bound to the location of the RS.
> I would argue to keep the "req_aud" as it is currently (since it covers 
> a broader set of use cases than "resource"), but I would be curious to 
> hear additional arguments for or against.
> 5. Handling of multiple tokens for one pair of client-RS
> The question was whether an additional token issued for the same 
> client-RS pair would
> a.) Amend the permissions (i.e. scope) of the older token(s)
> b.) Replace all older tokens for that client-RS pair
> My implementation and my current understanding of the draft was a.) but 
> apparently OAuth mostly does b.).
> I would be strongly in favor of doing b.) (and clarifying the specs to 
> this end) since it greatly simplifies the code on the RS side. Unless 
> someone has a strong argument for approach a. I will implement that 
> change in the next document update.
> 6. Do we need the expiration mechanism based on sequence numbers?
> Section 5.8.3 of the draft currently proposes a sequence-number-based 
> mechanism for expiration of access tokens on devices that do not have an 
> internal clock. Since this mechanisms has pretty severe limitations and 
> thus very weak security properties, and since we haven't yet seen a use 
> case involving devices without at least an internal "wall-clock time" I 
> propose to remove that mechanism from the draft, which seemed to be the 
> in-room consensus as well.

Some idea of wall-clock time is common, yes, but it is frequently easy for
an attacker to cause it to be wrong.  See, e.g., and the
document reviewed therein.

> 7. Symmetric proof-of-possession keys and multi RS audiences
> Currently the draft does NOT RECOMMEND this, since it allows one RS to 
> impersonate the client towards other RSs that are part of the audience.
> The in-room consensus seemed to be that this should be a MUST NOT 
> instead and I agree.

No objection here :)