Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-dyn-reg-28: (with DISCUSS and COMMENT)

Stephen Farrell <> Fri, 24 April 2015 12:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1268F1AD377; Fri, 24 Apr 2015 05:24:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.21
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SSXR-u0CkOGx; Fri, 24 Apr 2015 05:24:05 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C0E871B29FC; Fri, 24 Apr 2015 05:24:04 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 91582BE54; Fri, 24 Apr 2015 13:24:03 +0100 (IST)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 32GXEUPBbh8A; Fri, 24 Apr 2015 13:24:03 +0100 (IST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 6756ABE53; Fri, 24 Apr 2015 13:24:03 +0100 (IST)
Message-ID: <>
Date: Fri, 24 Apr 2015 13:24:04 +0100
From: Stephen Farrell <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Justin Richer <>, The IESG <>
References: <> <> <>
In-Reply-To: <>
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-dyn-reg-28: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 24 Apr 2015 12:24:07 -0000

On 24/04/15 13:20, Justin Richer wrote:
> Stephen, thanks for the comments.
> We discussed but decided to stop short of a full back-and-forth
> multi-trip information negotiation protocol in order to keep things as
> simple as possible for the simple case. The model here is that the
> client *requests* a certain set of information in the registration, and
> the server *dictates* to the client what actually occurred. This is to
> allow sensible defaults for blank fields, and other mechanisms like
> that. Instead of just saying "no", the server here has an opportunity to
> do something slightly reasonable. It's up to the client if it agrees
> with the reasonableness, and most clients (in my experience) are going
> to be super dumb and just do what they're told by the server if they're
> able to. If they're unable to, they'll just fail to use the OAuth
> protocol with that AS and users will complain (rightly) of an
> incompatibility bug. A smarter client can try to re-register and see if
> that works instead, but the vast majority of OAuth clients are really
> dumb (by design).
> However, there's a bit more to the story: As it turns out, when coupled
> with the management protocol and a discovery mechanism, you actually can
> do more of a negotiated registration with the existing mechanism: client
> says "I want foo", server says "you get bar", client sends an UPDATE
> that says "can I have baz instead?", and so forth. Without the update
> mechanism, you don't have a way to tie one registration request to a
> subsequent one. If you've got server capability discovery (such as is
> defined in OpenID Connect and still-ignored by this working group) then
> you've got the ability for a smart client to see which values might work
> ahead of time. This gets a little tricky with values that have
> relationships (such as grant_types and response_types), but it's still
> workable when they've got well-defined relationships (as is required in
> the Dyn Reg spec).
> So it really is out of scope for us to say what the client does when it
> gets information back it doesn't want: it can ignore it, fail on it, or
> use it. With management and discovery, it can try to re-negotiate, but
> that's a fairly sophisticated behavior.

So could we just point at the relevant specs for that behaviour?
(Not normatively, and I don't care if they're not RFCs.)


> Hope this helps,
>  -- Justin
> On 4/24/2015 8:09 AM, Stephen Farrell wrote:
>> 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
>> 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 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
>> 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
>> 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 mailing list