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.