IETF Logo Mail Archive

Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint

David Waite <david@alkaline-solutions.com> Mon, 04 February 2019 17:17 UTC

Return-Path: <david@alkaline-solutions.com>
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 8600D130EAB for <oauth@ietfa.amsl.com>; Mon, 4 Feb 2019 09:17:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.435
X-Spam-Level: *
X-Spam-Status: No, score=1.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-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 oLMPlQk0EjSV for <oauth@ietfa.amsl.com>; Mon, 4 Feb 2019 09:17:49 -0800 (PST)
Received: from alkaline-solutions.com (lithium5.alkaline-solutions.com [IPv6:2600:3c00::f03c:91ff:fe93:6974]) by ietfa.amsl.com (Postfix) with ESMTP id 28428130E86 for <oauth@ietf.org>; Mon, 4 Feb 2019 09:17:48 -0800 (PST)
Received: from [IPv6:2601:282:202:b210:b0d2:66e8:e5c0:c396] (unknown [IPv6:2601:282:202:b210:b0d2:66e8:e5c0:c396]) by alkaline-solutions.com (Postfix) with ESMTPSA id 62E043158E; Mon, 4 Feb 2019 17:17:47 +0000 (UTC)
From: David Waite <david@alkaline-solutions.com>
Message-Id: <CFEDC47D-4AC7-437C-AA63-EB374C6EB931@alkaline-solutions.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_FF2F75B7-B2DD-473F-AD41-C0CDFEC77E26"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.1\))
Date: Mon, 04 Feb 2019 10:17:46 -0700
In-Reply-To: <CA+k3eCQnpVG6D3-Q0dConTvM7oAKp6530U2_sRhJHQWKMMCMfQ@mail.gmail.com>
Cc: Neil Madden <neil.madden@forgerock.com>, oauth <oauth@ietf.org>
To: Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
References: <CA+k3eCTKSFiiTw8--qBS0R2YVQ0MY0eKrMBvBNE4pauSr1rHcA@mail.gmail.com> <6A614742-290D-47E2-B3E9-A4D49DB32DD7@forgerock.com> <CA+k3eCSoNRGrsxeLYd6DEqU+U6TB_aXV2aPUa07Um2X0ZH_ZEw@mail.gmail.com> <548FF68E-7775-4FE0-829F-1E9CC6EA8E3F@alkaline-solutions.com> <1119DDAE-8044-43C9-A6D4-6032B3BB62B8@forgerock.com> <9D007408-3BCC-4165-BCA4-083BD7602E7D@alkaline-solutions.com> <CA+k3eCQi1sz2bDOMEATpN9ZvXd+VJydQXG03WKuLczG5kz2z+Q@mail.gmail.com> <CAP-T6TTD-nLGoPHqJ042SzotLorb2mzoWgLxsausWHhRPZr8xA@mail.gmail.com> <CA+k3eCQtgku68usoCFsTeHVnNOLqWs6NweOgpQKsa7_9=wK7Vw@mail.gmail.com> <99d38517-0e25-789f-83ae-9f33e5620475@aol.com> <CA+k3eCQVL4DeRqHWYu6=xXjBK2RnukQ5RxFzRjGZYr4au8bBkQ@mail.gmail.com> <F5841CEA-BA74-4F17-977A-A78922CDC68C@amazon.com> <CA+k3eCT+mPu0=9TDKtuVqXy=zStEWTS5aVOsc2TuJcYQ2cvE6A@mail.gmail.com> <CC05C965-3308-4449-A1E2-EDA0119BE5D2@amazon.com> <5C615068-4D43-4697-B5B1-612F01166828@forgerock.com> <CA+k3eCQnpVG6D3-Q0dConTvM7oAKp6530U2_sRhJHQWKMMCMfQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/rPWmsR2Lokvv_HwBqrHb7P5YKSU>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser clients using the token endpoint
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: Mon, 04 Feb 2019 17:17:50 -0000

My understanding is that a permanent redirect would be telling the client (and any other clients getting cached results from an intermediary) to now stop using the original endpoint in perpetuity for all cases. I don’t think that is appropriate (in the general case) for an endpoint with request processing business logic behind it, since that logic may change over time.

-DW

> On Feb 4, 2019, at 6:28 AM, Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org> wrote:
> 
> Yeah, probably. 
> 
> On Sat, Feb 2, 2019 at 12:39 AM Neil Madden <neil.madden@forgerock.com <mailto:neil.madden@forgerock.com>> wrote:
> If we go down the 307 route, shouldn’t it rather be a 308 (permanent) redirect? It seems unnecessary for the client to keep trying the original endpoint or have to remember cache-control/expires timeouts. 
> 
> — Neil

v2.23.0 | Report a Bug | By Email