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:24 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 1268F1AD377; Fri, 24 Apr 2015 05:24:07 -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 SSXR-u0CkOGx; Fri, 24 Apr 2015 05:24:05 -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 C0E871B29FC; Fri, 24 Apr 2015 05:24:04 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 91582BE54; Fri, 24 Apr 2015 13:24:03 +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 32GXEUPBbh8A; Fri, 24 Apr 2015 13:24:03 +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 6756ABE53; Fri, 24 Apr 2015 13:24:03 +0100 (IST)
Message-ID: <553A35E4.1000904@cs.tcd.ie>
Date: Fri, 24 Apr 2015 13:24:04 +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: Justin Richer <jricher@mit.edu>, The IESG <iesg@ietf.org>
References: <20150424115205.3265.73381.idtracker@ietfa.amsl.com> <553A3289.2000401@cs.tcd.ie> <553A34FE.8@mit.edu>
In-Reply-To: <553A34FE.8@mit.edu>
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/G_vJ6XSUllaant9w_N2Pzzo7rvw>
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: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.)

S.

> 
> 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 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 mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>