Re: [Ace] [EXTERNAL] oauth-authz: Introspection endpoint method

Seitz Ludwig <ludwig.seitz@combitech.se> Mon, 16 November 2020 12:34 UTC

Return-Path: <ludwig.seitz@combitech.se>
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 4C9D03A0E26; Mon, 16 Nov 2020 04:34:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 1aN_R5bujsZy; Mon, 16 Nov 2020 04:34:17 -0800 (PST)
Received: from weald2.air.saab.se (weald2.air.saab.se [136.163.212.4]) (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 45A4E3A0E25; Mon, 16 Nov 2020 04:34:14 -0800 (PST)
Received: from mailhub1.air.saab.se ([136.163.213.4]) by weald2.air.saab.se (8.14.4/8.14.4) with ESMTP id 0AGCY8dD023906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 16 Nov 2020 13:34:08 +0100
DKIM-Filter: OpenDKIM Filter v2.11.0 weald2.air.saab.se 0AGCY8dD023906
Received: from corpappl16349.corp.saab.se (corpappl16349.corp.saab.se [10.12.12.112]) by mailhub1.air.saab.se (8.13.8/8.13.8) with ESMTP id 0AGCXs0A015165 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 16 Nov 2020 13:33:54 +0100
Received: from corpappl16595.corp.saab.se (10.12.12.127) by corpappl16349.corp.saab.se (10.12.12.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Mon, 16 Nov 2020 13:33:54 +0100
Received: from corpappl16595.corp.saab.se ([fe80::3c3e:6470:4c56:a86f]) by corpappl16595.corp.saab.se ([fe80::eca7:e370:adcc:2c99%6]) with mapi id 15.01.2106.003; Mon, 16 Nov 2020 13:33:54 +0100
From: Seitz Ludwig <ludwig.seitz@combitech.se>
To: =?iso-8859-1?Q?Christian_Ams=FCss?= <christian@amsuess.com>, "draft-ietf-ace-oauth-authz@ietf.org" <draft-ietf-ace-oauth-authz@ietf.org>, "draft-tiloca-ace-revoked-token-notification@ietf.org" <draft-tiloca-ace-revoked-token-notification@ietf.org>, "ace@ietf.org" <ace@ietf.org>
Thread-Topic: [EXTERNAL] oauth-authz: Introspection endpoint method
Thread-Index: AQHWu+58cTmTbcxl8UCT9JNIgxeHCqnKsQyQ
Date: Mon, 16 Nov 2020 12:33:54 +0000
Message-ID: <a929564a7e854214b0c5d2af57c04185@combitech.se>
References: <20201116075915.GA2528811@hephaistos.amsuess.com>
In-Reply-To: <20201116075915.GA2528811@hephaistos.amsuess.com>
Accept-Language: en-SE, sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.12.13.211]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Saab-MailScanner-Information: Please contact the ISP for more information
X-Saab-MailScanner-ID: 0AGCXs0A015165
X-Saab-MailScanner: Found to be clean
X-Saab-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1, required 5, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_20 -0.00, URIBL_BLOCKED 0.00)
X-Saab-MailScanner-From: ludwig.seitz@combitech.se
X-Saab-MailScanner-Watermark: 1606134835.70297@7Rc9UugOQ1eWv8TpGqOWBw
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (weald2.air.saab.se [136.163.212.4]); Mon, 16 Nov 2020 13:34:08 +0100 (CET)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/QZOl9OtaQI8HLiRUWn0HltxGjaU>
Subject: Re: [Ace] [EXTERNAL] 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 12:34:20 -0000

Hi Christian,

The short answer is:

We aligned as close as possible with OAuth 2.0, and there Introspection uses POST.

/Ludwig

> -----Original Message-----
> From: Christian Amsüss <christian@amsuess.com>
> Sent: den 16 november 2020 08:59
> To: draft-ietf-ace-oauth-authz@ietf.org; draft-tiloca-ace-revoked-token-
> notification@ietf.org; ace@ietf.org
> Subject: [EXTERNAL] oauth-authz: Introspection endpoint method
> 
> 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