[Ace] oauth-authz: Introspection endpoint method

Christian Amsüss <christian@amsuess.com> Mon, 16 November 2020 07:59 UTC

Return-Path: <christian@amsuess.com>
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 235A43A157F; Sun, 15 Nov 2020 23:59:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 txt1eDFZWDbq; Sun, 15 Nov 2020 23:59:25 -0800 (PST)
Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B74FA3A141F; Sun, 15 Nov 2020 23:59:19 -0800 (PST)
Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 5C5D64083C; Mon, 16 Nov 2020 08:59:17 +0100 (CET)
Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id ECE55AB; Mon, 16 Nov 2020 08:59:15 +0100 (CET)
Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:15f9:e3c5:c0de:cf69]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 8BB74180; Mon, 16 Nov 2020 08:59:15 +0100 (CET)
Received: (nullmailer pid 2659933 invoked by uid 1000); Mon, 16 Nov 2020 07:59:15 -0000
Date: Mon, 16 Nov 2020 08:59:15 +0100
From: Christian =?iso-8859-1?Q?Ams=FCss?= <christian@amsuess.com>
To: draft-ietf-ace-oauth-authz@ietf.org, draft-tiloca-ace-revoked-token-notification@ietf.org, ace@ietf.org
Message-ID: <20201116075915.GA2528811@hephaistos.amsuess.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rwEMma7ioTxnRzrJ"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/8M-35-Hnx8VhUx9kL1b6956oLoI>
Subject: [Ace] oauth-authz: Introspection endpoint method
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: Mon, 16 Nov 2020 07:59:35 -0000

Hello ACE-OAuth authors, authors of revoked-token-notifcation, and ACE
group in general,

while trying to understand the necessity for revoked-token-notification,
I was looking into the introspection parts of ACE
(draft-ietf-ace-oauth-authz-35 Section 5.7.1) and was confused at the
method used there:


Given the introspection endpoint is used for querying, why is it using
the POST method? This indicates that the request may not be safe (in
REST terminology), which seems not the case.


This would have the nice properties of indicating its safeness to the
rest of the stack (ie. the CoAP library can forego request
deduplication). Also, it'd keep the door open for caching (where
obviously `exi` would be inapplicable, but `Max-Age: ...` would be used
instead), and observing a particular introspection would be possible.
This sure wouldn't make revoked- obsolete, but I think it'd make the
path there smoother, and help sharpen what the TRL adds.

If there's no particular reason to keep POST and it's early enough for
such a change, the change to the document would be minimal, and unless
any implementation is built on a CoAP stack without support for RFC8132,
changes there should be trivial.

Best regards
Christian


Bycatch: The example in figure 13/14, the Uri-Path should probably be in
Figure 14 instead, along with the inner code (which is suggested to
change above). Given figure 15 is shown as the full protected message,
the same format may work well for a single figure 13/14 as well (with
just a note that this is an encrypted exchange).

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom