Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt

Justin Richer <jricher@mit.edu> Tue, 01 October 2019 22:43 UTC

Return-Path: <jricher@mit.edu>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC33C12012C for <oauth@ietfa.amsl.com>; Tue, 1 Oct 2019 15:43:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 bd1E5xS-GP8y for <oauth@ietfa.amsl.com>; Tue, 1 Oct 2019 15:43:46 -0700 (PDT)
Received: from outgoing-exchange-5.mit.edu (outgoing-exchange-5.mit.edu [18.9.28.59]) (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 A0808120100 for <oauth@ietf.org>; Tue, 1 Oct 2019 15:43:46 -0700 (PDT)
Received: from w92exedge3.exchange.mit.edu (W92EXEDGE3.EXCHANGE.MIT.EDU [18.7.73.15]) by outgoing-exchange-5.mit.edu (8.14.7/8.12.4) with ESMTP id x91MiKBm023362; Tue, 1 Oct 2019 18:44:21 -0400
Received: from w92expo8.exchange.mit.edu (18.7.74.62) by w92exedge3.exchange.mit.edu (18.7.73.15) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Tue, 1 Oct 2019 18:42:48 -0400
Received: from oc11expo18.exchange.mit.edu (18.9.4.49) by w92expo8.exchange.mit.edu (18.7.74.62) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 1 Oct 2019 18:43:44 -0400
Received: from oc11expo18.exchange.mit.edu ([18.9.4.49]) by oc11expo18.exchange.mit.edu ([18.9.4.49]) with mapi id 15.00.1365.000; Tue, 1 Oct 2019 18:43:44 -0400
From: Justin Richer <jricher@mit.edu>
To: Benjamin J Kaduk <kaduk@mit.edu>
CC: Travis Spencer <travis.spencer@curity.io>, oauth <oauth@ietf.org>
Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt
Thread-Index: AQHVb67qwr2PBijQ2k+ejJTM3X6l2qc9/KaAgAJzIQCABkdDgA==
Date: Tue, 1 Oct 2019 22:43:44 +0000
Message-ID: <E19B32EE-DE86-4EBA-8CDE-1BB78F400C4A@mit.edu>
References: <156898250596.30287.14524104153595179086@ietfa.amsl.com> <CAEKOcs3mE0C0s_B+12J-+anxSLbVk_pDx_urJawpmCnw9dSVtA@mail.gmail.com> <20190927225106.GE6424@kduck.mit.edu>
In-Reply-To: <20190927225106.GE6424@kduck.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [67.207.105.98]
Content-Type: multipart/alternative; boundary="_000_E19B32EEDE864EBA8CDE1BB78F400C4Amitedu_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/4OGEdQsQDqmtkay26r55gBuoePk>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Oct 2019 22:43:49 -0000

I stand with Ben’s contention that introspection should be about getting information :about: a token, and not about getting a new token. In fact, this was one of the core issues that I had with the draft as originally proposed.

If there are problems with token exchange, they should be fixed with token exchange and not piggybacked as an after-thought on this work.

— Justin

On Sep 27, 2019, at 3:51 PM, Benjamin Kaduk <kaduk@mit.edu<mailto:kaduk@mit.edu>> wrote:

On Thu, Sep 26, 2019 at 11:26:31AM +0200, Travis Spencer wrote:
* Last but certainly not least is the restriction that the current
version places on disallowing of the introspection JWT response as an
access token. This is done in numerous places (the note in section 5,
8.1, etc.). I understand that there are some objection to this usage,
but we have had this protocol deployed for years, and it's running in
dozens of customer's facilities. This will break real applications of
this specification without a clear alternative. As we discussed in
London last year at the IETF meeting, token exchange isn't a viable
alternative (even still in its current draft form to the best of my
knowledge). Without a workable alternative to move to, I emphatically
but humbly request that this specification remove this restriction.

I don't think I was in the London session, so would you mind saying a bit
more about why token exchange isn't viable for your scenario?
As an AD, I support the efforts to be explicit about what token flow/usage
is being defined, which in effect means keeping introspection just
introspection and not "producing new tokens".

Thanks,

Ben

_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth