Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-dyn-reg-28: (with DISCUSS and COMMENT)
Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 24 April 2015 12:09 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F9EA1ACD27; Fri, 24 Apr 2015 05:09:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 3VTfcvtoSUXp; Fri, 24 Apr 2015 05:09:48 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C83B1ACD0C; Fri, 24 Apr 2015 05:09:46 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3EEC7BE54; Fri, 24 Apr 2015 13:09:44 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g18rmxCQTdUU; Fri, 24 Apr 2015 13:09:44 +0100 (IST)
Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 16DDEBE53; Fri, 24 Apr 2015 13:09:44 +0100 (IST)
Message-ID: <553A3289.2000401@cs.tcd.ie>
Date: Fri, 24 Apr 2015 13:09:45 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: The IESG <iesg@ietf.org>
References: <20150424115205.3265.73381.idtracker@ietfa.amsl.com>
In-Reply-To: <20150424115205.3265.73381.idtracker@ietfa.amsl.com>
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/mAf2ykEN0THzEZbasVxbyjuqbvQ>
Cc: draft-ietf-oauth-dyn-reg@ietf.org, oauth-chairs@ietf.org, oauth@ietf.org
Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-dyn-reg-28: (with DISCUSS and COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Fri, 24 Apr 2015 12:09:50 -0000
So this is to follow up on my discuss point#2, which said: (2) If the response (defined in 3.2.1) includes metadata that the server has altered, but that the client doesn't like, then what does the client do? (It may be that that's ok, but I'm not following why that is the case.) I'm also not sure the "https" requirement (1st bullet in section 5) is useful there. In -28 you added a bit of text to 3.2.1. saying: "The client or developer can check the values in the response to determine if the registration is sufficient for use (e.g., the registered "token_endpoint_auth_method" is supported by the client software) and determine a course of action appropriate for the client software. The response to such a situation is out of scope for this specification but could include filing a report with the application developer or authorization server provider." That new text may be fine, but I'd like to check that I understand it correctly and that it addresses the issue sensibly. Say I'm a developer who writes and distributes a client that uses this and I test it with the BIGreg.example.com registration endpoint and it works, but for my application to work I need a specific token_endpoint_auth_method, say client_secret_basic. Say time passes, and we discover that client_secret_basic is bad for some reason and client_secret_supergood is invented and gets used a lot. At that point BIGreg.example.com would like to turn off the (now-crappy) client_secret_basic and only allow use of client_secret_supergood. If it does that, then new installs of our application will fail at registration time with an (opaque) error to the human user and we need the application developer to do an update to add client_secret_supergood. Or, what seems more likely is that BIGreg.example.com will have to keep offering the now insecure client_secret_basic until essentially no interesting applications remain that don't support the new, better thing. And that's the bit I don't like so much. This spec could (maybe, I'm not 100% sure) have been written to allow for the client and registration endpoint to first try to use the new better things and, if that doesn't work, to try fallback to the old not so good things, but that is not supported here afaics - once the client sees response metadata it doesn't like, there's no way for the client to say "bummer, I'd have been fine if only you'd said foo and not bar, can we try register again and use foo?" And I also don't see how the client who is really stuck can tell the registration endpoint "actually, I'm not successfully registered because your said bar and I don't like that bit of metadata" - won't that lead to our BIGreg.example.com ending up with a misleading picture of what clients were successfully registered? So my question is: is all that really ok, or am I confused in the above? (And confused is quite possible - this is OAuth after all:-) Cheers, S.
- [OAUTH-WG] Stephen Farrell's Discuss on draft-iet… Stephen Farrell
- Re: [OAUTH-WG] Stephen Farrell's Discuss on draft… Stephen Farrell
- Re: [OAUTH-WG] Stephen Farrell's Discuss on draft… Justin Richer
- Re: [OAUTH-WG] Stephen Farrell's Discuss on draft… Stephen Farrell
- Re: [OAUTH-WG] Stephen Farrell's Discuss on draft… Justin Richer
- Re: [OAUTH-WG] Stephen Farrell's Discuss on draft… Justin Richer
- Re: [OAUTH-WG] Stephen Farrell's Discuss on draft… Stephen Farrell
- Re: [OAUTH-WG] Stephen Farrell's Discuss on draft… Stephen Farrell
- Re: [OAUTH-WG] Stephen Farrell's Discuss on draft… Justin Richer
- Re: [OAUTH-WG] Stephen Farrell's Discuss on draft… Stephen Farrell
- Re: [OAUTH-WG] Stephen Farrell's Discuss on draft… Kathleen Moriarty
- Re: [OAUTH-WG] Stephen Farrell's Discuss on draft… Mike Jones
- Re: [OAUTH-WG] Stephen Farrell's Discuss on draft… Justin Richer
- Re: [OAUTH-WG] Stephen Farrell's Discuss on draft… Justin Richer
- Re: [OAUTH-WG] Stephen Farrell's Discuss on draft… Stephen Farrell
- Re: [OAUTH-WG] Stephen Farrell's Discuss on draft… Kathleen Moriarty