Re: [Ace] Progressing draft-ietf-ace-oauth-authz

Justin Richer <jricher@mit.edu> Tue, 26 October 2021 14:07 UTC

Return-Path: <jricher@mit.edu>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927723A119E for <ace@ietfa.amsl.com>; Tue, 26 Oct 2021 07:07:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.497
X-Spam-Level:
X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJ6UDVAIoWZ8 for <ace@ietfa.amsl.com>; Tue, 26 Oct 2021 07:06:56 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18C0A3A11BA for <ace@ietf.org>; Tue, 26 Oct 2021 07:06:47 -0700 (PDT)
Received: from smtpclient.apple (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 19QE6dhv026242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 26 Oct 2021 10:06:41 -0400
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Justin Richer <jricher@mit.edu>
In-Reply-To: <AM0PR0302MB3363701AF68B1BCD98EE81DF9E849@AM0PR0302MB3363.eurprd03.prod.outlook.com>
Date: Tue, 26 Oct 2021 10:06:39 -0400
Cc: "ace@ietf.org" <ace@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <9BD86625-6BC5-492F-954A-C702E2CA0A5E@mit.edu>
References: <AM0PR0302MB3363701AF68B1BCD98EE81DF9E849@AM0PR0302MB3363.eurprd03.prod.outlook.com>
To: Ludwig Seitz <ludwig.seitz@combitech.com>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/JuswLFWBJIftKaI6VsYiV2N9Kg0>
Subject: Re: [Ace] Progressing draft-ietf-ace-oauth-authz
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Oct 2021 14:07:01 -0000

That solution is fine with me. From RFC7662’s perspective, JSON is the canonical form, and any other representation should be able to be translated from that. While not mentioned in 7662, I see no problem with other representations having special optimizations for any given field, and so this approach makes sense.

Please be very specific with the string definition though: Base64 URLSafe encoding with no padding.

Thanks,
 — Justin


> On Oct 26, 2021, at 7:57 AM, Ludwig Seitz <ludwig.seitz@combitech.com> wrote:
> 
> Hello ACE (Cc to OAuth designated expert Justin),
> 
> The progress of draft-ietf-ace-oauth-authz is currently blocked due to an issue that has come to light in the IANA review process, and I'd like to solicit the feedback of the WG to determine how to go forward.
> 
> The issue is related to parameters used by the AS when responding to an Introspection query (see https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz-45#section-5.9.2). Our approach so far has been to map all OAuth parameters to ACE and map all parameters created for the ACE interaction back to OAuth. The issue is that some of the ACE parameters (cnonce and cti, see Figure 16) have the datatype "byte string". In OAuth the Introspection parameters are formatted as JSON payload, which precludes the use of raw byte strings, a fact we overlooked when we tried to register the new parameters in the OAuth registry ( see https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#token-introspection-response).
> 
> My proposed fix for this would be to amend the descriptions of these two parameters in 5.9.2, specifying that their JSON representation is a text string containing the Base64url encoding of the original byte string payload.
> 
> Does the working group or the OAuth designated expert have any objections (or suggestions) to this approach?
> 
> Regards,
> 
> Ludwig
> 
> --
> Ludwig Seitz
> Infrastructure Security Analyst
> Combitech AB
> Djäknegatan 31 . SE-211 35 Malmö . Sweden
> Phone: +46 102 160 846
> ludwig.seitz@combitech.com . combitech.com This e-mail is private and confidential between the sender and the addressee. In the event of misdirection, the recipient is prohibited from using, copying or disseminating it or any information in it. Please notify the above of any such misdirection Please consider the environment before printing this e-mail!
> 
>