Re: [Gen-art] [Ace] Genart last call review of draft-ietf-ace-oauth-params-06

elwynd <> Sat, 21 December 2019 13:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E2F4F120A58; Sat, 21 Dec 2019 05:50:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.195
X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 28ArMM8xZZpz; Sat, 21 Dec 2019 05:50:06 -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 266F9120071; Sat, 21 Dec 2019 05:50:06 -0800 (PST)
Received: from ([2001:8b0:bf:1:f56b:b057:6571:a7c6]) by with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <>) id 1iif8u-0006en-AW; Sat, 21 Dec 2019 13:50:04 +0000
Date: Sat, 21 Dec 2019 13:50:00 +0000
In-Reply-To: <>
Importance: normal
From: elwynd <>
To: Ludwig Seitz <>,
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=""
Message-ID: <>
Archived-At: <>
Subject: Re: [Gen-art] [Ace] Genart last call review of draft-ietf-ace-oauth-params-06
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 21 Dec 2019 13:50:08 -0000

Hi, Ludwig.Yes, -08 addresses the two points noted below... unfortunately you didn't fix the various nits and the other minor issues as you indicated you were intending to in your initial response (EC => EC2, etc).Enjoy the holidays!Cheers,ElwynSent from Samsung tablet.
-------- Original message --------From: Ludwig Seitz <> Date: 21/12/2019  12:22  (GMT+00:00) To: elwynd <>uk>, Cc:,, Subject: Re: [Gen-art] [Ace] Genart last call review of
  draft-ietf-ace-oauth-params-06 On 2019-12-19 21:23, elwynd wrote:> Hi, Ludwig.>> Thanks for the prompt response.>> Regarding he major issue, I understand what the intention of the split> was, but as far as early implementations are concerned, there is no such> thing as a 'minimal breakage'; unless there is some cunning mechanism in> the basic ace-oauth-authz protocol, changes to the structure of the> items defined here will break the protocol.  One possibility that I> could see is the addition of extra keys in the COSE_Key dictionary> structure: In this case you could add some extra words (in the> ace-oauth-authz document) to indicate that unrecognized keys should be> ignored.  This is associated with the editorial comments I made about> s3.1 that would allow any other keys to be present in the COSE_Key> object structure.  Similarly, the obects defined here are effectively> JSON/CBOR dictionaries.  The changes could be accomodated by adding> comments in ace-oauth that extra keys in the items defined would be> ignored.>> In my opinion, it would be best to remove the comments about possible> changes and just state that they have been separated out because they> might be used in other contexts.  The possible 'changes to the> definitions' issue is just a matter of 'institutional memory'.  If there> is some mechanism, such as I mentioned above, to accommodate changes> without neeeding an update to the ace-oauth-authz (or other protocols> using these items), this should be explained.I have submitted an updated draft (-08) that removes the comments aboutpossible changes. Does this address your major issue?>> Regarding the h vs b64 representations, since they are only examples> (and the strings are essentially arbitrary as the actual keys aren't in> the document), I'd be inclined to put in h representations to avoid my> question arisng.In my newly submitted draft all the b64 representations have beenreplaced by equivalent h representations.Note that none of these strings are arbitrary, since they do parse toactual keys. The abbreviated b64 strings representing tokens obviouslydo not parse as such, but come from the actual binary representation oftokens.Happy holidays,Ludwig