Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

Brian Campbell <bcampbell@pingidentity.com> Sun, 13 November 2016 21:21 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 D11CF129651 for <oauth@ietfa.amsl.com>; Sun, 13 Nov 2016 13:21:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-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 rI1fPCGzUc55 for <oauth@ietfa.amsl.com>; Sun, 13 Nov 2016 13:21:35 -0800 (PST)
Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 0E28C1295A0 for <oauth@ietf.org>; Sun, 13 Nov 2016 13:21:35 -0800 (PST)
Received: by mail-it0-x232.google.com with SMTP id c20so44210240itb.0 for <oauth@ietf.org>; Sun, 13 Nov 2016 13:21:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PHp4KAR4xq/3f0q96MKsvDzZrdup0VO7ucp/IkwGq+M=; b=cpG1/SdqbLIJa5SgGdCcrwkJK7rzatmeRd8SfVB9Q7w7Ipt6HwIJvmSitkLhetVg/w 6wxFoCQGF9T0OcGHOu6AQ4aqWZQgSCkK4RLch8DPw0W7Ae2LJcgbyLsUCrilEoFAUmJi 99U5ZTMWvwFeOlVqzPRdXSmksb1HmuUA7iJ5w=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PHp4KAR4xq/3f0q96MKsvDzZrdup0VO7ucp/IkwGq+M=; b=mF2y6eWffWVT3isN4IMexpjwjTDvQi1wT1g5uAlYAU8pnZDiT+Gw9Ck9w+4Yjy34pH eVkbKoV5CuUPt9wfiaJbW5Lt61eft7+fueMaIudLKYeou+OSydJBpjTQlA2ju7O4ggeR ADBg51QDQGdQX1JABFUY6O0SbGhnu2xFl3pYwYgSIKkqUBrEAXnnsnwzzkhDTvbGs+Mo ycmZRjIX8TkD9dkV/TWHlxGtMbjAUzLnxST8TIY5VktbFlct7i2h8Qhrm0XlmAg/O+SV uckAf/FneEqw2rBQpnJWx/WshxADQ8QWpcWgepnQ1Y5x8eVaK/9acT6tBl5kislFNo9c YmIA==
X-Gm-Message-State: ABUngvci2qEt+jjXQ7+cGO0y0ikHFIClHa48DQZTRdc3DWJO/0Qql/aEjNoH1Rgv9Nzc56GjHlZhdGW5P6eU66Eg
X-Received: by 10.36.31.82 with SMTP id d79mr4016864itd.79.1479072094268; Sun, 13 Nov 2016 13:21:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.79.156.74 with HTTP; Sun, 13 Nov 2016 13:21:03 -0800 (PST)
In-Reply-To: <58280139.2040505@lodderstedt.net>
References: <147613227959.31428.2920748721017165266.idtracker@ietfa.amsl.com> <9CDE07EB-E5B4-43B2-B3C1-F12569CAB458@ve7jtb.com> <5827DE8A.4010807@lodderstedt.net> <4372F560-F98E-491B-BEDD-B02A2671D96C@mit.edu> <5827F848.3060803@lodderstedt.net> <2164E521-236F-46FC-AAF1-D2EE80F29BA9@mit.edu> <58280139.2040505@lodderstedt.net>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Sun, 13 Nov 2016 14:21:03 -0700
Message-ID: <CA+k3eCS-S8G-jxRMnvczaysdNZSRWwiPnGTMnGVnh8dWgh0k-A@mail.gmail.com>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Content-Type: multipart/alternative; boundary="001a1145e852c6be0e0541354e36"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/t-zXDiWdSLA6K5FtVU0oX7JtKk8>
Cc: Nat Sakimura via Openid-specs-fapi <openid-specs-fapi@lists.openid.net>, "<oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
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: Sun, 13 Nov 2016 21:21:37 -0000

Yes, the intend is that the authentication method is determined by client
policy regardless of whether the client was dynamically registered or
statically configured or whatever. I can make that point more explicit in
future revisions of the draft.

On Sat, Nov 12, 2016 at 10:59 PM, Torsten Lodderstedt <
torsten@lodderstedt.net> wrote:

> I understand. My point is different: the text seems to assume everybody is
> using client registration, but that's not the case. I would like to point
> out it makes sense to explicitely state the assumption that it is
> determined by client policy (indepedent of the way this policy is
> established).
>
>
> Am 13.11.2016 um 14:24 schrieb Justin Richer:
>
> As part of the client’s registered data model. At least, based on how our
> own implementation works (where we support client_secret_basic,
> private_key_jwt, etc), that’s where we’d check to see if the client was
> supposed to be using TLS auth or not.
>
> We don’t let clients switch away from their registered auth mechanism.
>
>  — Justin
>
> On Nov 13, 2016, at 2:21 PM, Torsten Lodderstedt <torsten@lodderstedt.net>
> wrote:
>
> Justin,
>
> Am 13.11.2016 um 13:39 schrieb Justin Richer:
>
> Torsten, I believe this is intended to be triggered by the tls_client_auth
> value specified in §3.
>
>
> in the token request?
>
>
> Nit on that section, the field name for the client metadata in RFC7591 is
> token_endpoint_auth_method, the _supported version is from the
> corresponding discovery document.
>
>  — Justin
>
> Torsten.
>
> On Nov 13, 2016, at 12:31 PM, Torsten Lodderstedt <
> <torsten@lodderstedt.net>torsten@lodderstedt.net> wrote:
>
> Hi John and Brian,
>
> thanks for writting this draft.
>
> One question: how does the AS determine the authentication method is TLS
> authentication? I think you assume this is defined by the client-specific
> policy, independent of whether the client is registered automatically or
> manually. Would you mind to explicitely state this in the draft?
>
> best regards,
> Torsten.
>
> Am 11.10.2016 um 05:59 schrieb John Bradley:
>
> At the request of the OpenID Foundation Financial Services API Working
> group, Brian Campbell and I have documented
> mutual TLS client authentication.   This is something that lots of people
> do in practice though we have never had a spec for it.
>
> The Banks want to use it for some server to server API use cases being
> driven by new open banking regulation.
>
> The largest thing in the draft is the IANA registration of
> “tls_client_auth” Token Endpoint authentication method for use in
> Registration and discovery.
>
> The trust model is intentionally left open so that you could use a “common
> name” and a restricted list of CA or a direct lookup of the subject public
> key against a reregistered value,  or something in between.
>
> I hope that this is non controversial and the WG can adopt it quickly.
>
> Regards
> John B.
>
>
>
>
> Begin forwarded message:
>
> *From: * <internet-drafts@ietf.org>internet-drafts@ietf.org
> *Subject: **New Version Notification for
> draft-campbell-oauth-tls-client-auth-00.txt*
> *Date: *October 10, 2016 at 5:44:39 PM GMT-3
> *To: *"Brian Campbell" < <brian.d.campbell@gmail.com>
> brian.d.campbell@gmail.com>, "John Bradley" < <ve7jtb@ve7jtb.com>
> ve7jtb@ve7jtb.com>
>
>
> A new version of I-D, draft-campbell-oauth-tls-client-auth-00.txt
> has been successfully submitted by John Bradley and posted to the
> IETF repository.
>
> Name: draft-campbell-oauth-tls-client-auth
> Revision: 00
> Title: Mutual X.509 Transport Layer Security (TLS) Authentication for
> OAuth Clients
> Document date: 2016-10-10
> Group: Individual Submission
> Pages: 5
> URL:
> <https://www.ietf.org/internet-drafts/draft-campbell-oauth-tls-client-auth-00.txt>
> https://www.ietf.org/internet-drafts/draft-campbell-oauth-tls-client-
> auth-00.txt
> Status:
> <https://datatracker.ietf.org/doc/draft-campbell-oauth-tls-client-auth/>
> https://datatracker.ietf.org/doc/draft-campbell-oauth-tls-client-auth/
> Htmlized:
> <https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00>
> https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00
>
>
> Abstract:
>   This document describes X.509 certificates as OAuth client
>   credentials using Transport Layer Security (TLS) mutual
>   authentication as a mechanism for client authentication to the
>   authorization server's token endpoint.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>
>