Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token endoint & discovery

Brian Campbell <bcampbell@pingidentity.com> Tue, 19 February 2019 21:00 UTC

Return-Path: <bcampbell@pingidentity.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 D2F1B128701 for <oauth@ietfa.amsl.com>; Tue, 19 Feb 2019 13:00:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
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 J5_SFglx7naO for <oauth@ietfa.amsl.com>; Tue, 19 Feb 2019 13:00:29 -0800 (PST)
Received: from mail-it1-x136.google.com (mail-it1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CA1D12426E for <oauth@ietf.org>; Tue, 19 Feb 2019 13:00:29 -0800 (PST)
Received: by mail-it1-x136.google.com with SMTP id l15so9787188iti.4 for <oauth@ietf.org>; Tue, 19 Feb 2019 13:00:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OzgqgPiTO6qaT28Xtquf/M/IXhDI/F4HsQ9Tgw9eoGg=; b=J4dR0n0j26hePDE0+DVYDtUgFtNa84eznI7h7qYzoNsiYHvsRaou6akyK2A4Zvl1ik dk0TweFZLIgXThU3iF56kRpIGctkZJAJWmBdeGCgrSIoJ6tWC/Q9UT/C/iVsaoZ06YNN xVawjXlxGFWW06G6OjU+8fGTjggbWwv2LAmEQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OzgqgPiTO6qaT28Xtquf/M/IXhDI/F4HsQ9Tgw9eoGg=; b=F6ac1MNM2kyUGzHR/TxqZp8HjVFzGunjsLCoE9FBNHAMLKEQKHDgm/QQnaDzLMPDcq RxNDPSXNl1oSSV+JTKAppQKDf1g9YEoFSp7bvRY2qizA6r2uRZEGnpQNZG3hO7ve2DGY eKLavKHu3C8LPP0qCsw9uAlfpt7U+cTeuWmokiqqmstb8XwegPLOxvNa3Avw9Lk1wCeC OWmvAXcoBvxSMiKn8kOhbrGfvY3YlmmDbLnidZHnucOTtgYjO1iw7PASlcg7mvq1d31P XK1vXDNyMe3y8i6FQOjQwWH72koQkqWSrfikidZYWq/fIKxSfAPjPOV8Casl+wPUWNyk PAOg==
X-Gm-Message-State: AHQUAub2Z+okwgJhqbBRN/D3OnqY+rb23+1TnPTcMx5+DGQhWoepe+Af etrOoE6qAlqfLjSGu+kWxWzYASF8ViQCfw57qDwXgygQ+CxHIsRkriA/rQX4MkYF8SDmICct3t0 6JDM/QFGz2oZ+fA==
X-Google-Smtp-Source: AHgI3IaSHfo7S3GEwQoDz414gg45bPukXy3vwYMNFMW5gosHcR3UP9XJSBM+bT1NLK+TnMKEmd5V4lwX7X381xIWW0o=
X-Received: by 2002:a6b:b408:: with SMTP id d8mr15600467iof.138.1550610028293; Tue, 19 Feb 2019 13:00:28 -0800 (PST)
MIME-Version: 1.0
References: <CA+k3eCTKSFiiTw8--qBS0R2YVQ0MY0eKrMBvBNE4pauSr1rHcA@mail.gmail.com> <CAO7Ng+tGnf1fvWjsewexUidiJo06ZdQZbFthTrJZRqSYVB+t0g@mail.gmail.com> <CA+k3eCQy7G9AVMAsKUwGdVUGtGDNdV1A39571jNXoctPE+fEHA@mail.gmail.com> <DDDC7C84-60FF-43CD-BC1F-E13CD6937655@amazon.com> <CALAqi_8jCf6W-6hw8zrEvCvfOwc82NnXC=beQhOkKUPyig+ZMA@mail.gmail.com> <4390FC23-3FC0-4F4E-B308-8E266391E1DD@amazon.com> <CALAqi_9c6HKDbv4FzgydCoLJ=Ax0be=aL7Wv2K1icbRtSTKozA@mail.gmail.com> <CAO7Ng+t7cVtHb++YUZ4EKij62=LB5=jL5S-FgFNCbMEaEbJyvQ@mail.gmail.com> <141CD215-A86A-4926-9FD6-F58DD966F40F@amazon.com> <CAO7Ng+vJTgLdapswf-E4yy7UOrcDRV-pfh2otbcuFBGVxhh2tw@mail.gmail.com> <ACDEF883-9832-47A6-82CA-7DFD0EDE342F@oracle.com> <CA+k3eCSr4z_g=_MHpMkwAwveQeeHrCooC2c-xkKVb+YQ02WGPA@mail.gmail.com> <CALAqi__LKJ4r1dt2H74MOifXeRwP78uw=ksYsrQCs=3BeHtWRQ@mail.gmail.com> <BF86C4DA-F104-4436-A41B-B3FD4924CAFC@oracle.com> <a22b7524-801b-85d5-83d1-7373eaf1bc25@aol.com> <1AB3C397-F1E5-4FEA-8A3B-7B810D0E7309@forgerock.com>
In-Reply-To: <1AB3C397-F1E5-4FEA-8A3B-7B810D0E7309@forgerock.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Tue, 19 Feb 2019 14:00:02 -0700
Message-ID: <CA+k3eCRCaZaihg8A0ez5RYq_C6muvjqm5p5n8XjS6SA24W+h_A@mail.gmail.com>
To: Neil Madden <neil.madden@forgerock.com>
Cc: George Fletcher <gffletch=40aol.com@dmarc.ietf.org>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ec27bf0582458729"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/aVePG-ufflOCjuEU9kp9CsHGb0U>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS token endoint & discovery
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, 19 Feb 2019 21:00:32 -0000

In the upcoming revision of the draft I've reworked and moved that section
[1] so that it is more focused on public clients and certificate bound
tokens (see [a]). But yes, I think it comes down to saying that a client
that is expecting to use MTLS (for whatever reason: bound tokens or client
auth or both) for something would use the mtls-specific endpoint when
making the request (or the regular endpoint, if no mtls-specific endpoint
is present).  And yeah the AS would accept other client auth methods
(including none for public clients) at the mtls token endpoint. Maybe a
hundred messages back in this whole thread, at one point anyway, I used the
word alias for the endpoint to try and capture the idea that it would most
likely be the same application logic and the mtls endpoint would just be on
a different host/port to allow the TLS layer to be set up differently for
the different context. Maybe that name and/or idea should resurface?

[a]
https://github.com/ietf-oauth-mtls/i-d/commit/d1c1db18e62db2cf7665f69d3162a391ba1aa03c

On Fri, Feb 15, 2019 at 1:33 PM Neil Madden <neil.madden@forgerock.com>
wrote:

> As another case - if the client wants certificate-bound access tokens but
> still authenticates with client_secret_basic or is a public client (as per
> [1]), presumably it can use the mtls-specific endpoints and assume they
> support all the other authentication methods as the normal endpoints?
>
> But so long as we can define some half-sensible behaviour for these cases,
> I’m happy with this proposal.
>
> [1] https://tools.ietf.org/html/draft-ietf-oauth-mtls-12#section-4.3
>
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._