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

Justin Richer <jricher@mit.edu> Fri, 24 April 2015 12:20 UTC

Return-Path: <jricher@mit.edu>
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 715B41ACE17; Fri, 24 Apr 2015 05:20:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.811
X-Spam-Level:
X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 SJcSP7A-MzeY; Fri, 24 Apr 2015 05:20:31 -0700 (PDT)
Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEB251ACE27; Fri, 24 Apr 2015 05:20:30 -0700 (PDT)
X-AuditID: 12074423-f79536d000000e74-ca-553a350c54be
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 79.AF.03700.D053A355; Fri, 24 Apr 2015 08:20:29 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id t3OCKSEx009790; Fri, 24 Apr 2015 08:20:28 -0400
Received: from [192.168.128.56] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t3OCKPlM010414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 24 Apr 2015 08:20:26 -0400
Message-ID: <553A34FE.8@mit.edu>
Date: Fri, 24 Apr 2015 08:20:14 -0400
From: Justin Richer <jricher@mit.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, The IESG <iesg@ietf.org>
References: <20150424115205.3265.73381.idtracker@ietfa.amsl.com> <553A3289.2000401@cs.tcd.ie>
In-Reply-To: <553A3289.2000401@cs.tcd.ie>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjleLIzCtJLcpLzFFi42IR4hTV1uU1tQo1aD/GbjHt52s2ixl/JjJb 3J67ks3i5NtXbBbT915jd2D1WNt9lc1jyZKfTAFMUVw2Kak5mWWpRfp2CVwZp27/YyzYoV3x tncecwPjPaUuRk4OCQETiZVn/jJD2GISF+6tZwOxhQQWM0nM+WbYxcgFZG9klHh85z0rhHOb SeLw+wVAHRwcvAIKEhMPRoA0sAioSvQe+wA2iA3Inr6mhQnEFhWIkpj49RALiM0rIChxcuYT MFtEwFPiYd8pMJtZwEeid9plsHphgTyJjkNdUEfESixesQbM5hTQlOj7s58Zot5W4s7c3VC2 vMT2t3OYJzAKzkKyYhaSsllIyhYwMq9ilE3JrdLNTczMKU5N1i1OTszLSy3SNdPLzSzRS00p 3cQICm52F+UdjH8OKh1iFOBgVOLhnTHHMlSINbGsuDL3EKMkB5OSKG+nlFWoEF9SfkplRmJx RnxRaU5q8SFGCQ5mJRHeZwZAOd6UxMqq1KJ8mJQ0B4uSOO+mH3whQgLpiSWp2ampBalFMFkZ Dg4lCV4xY6BGwaLU9NSKtMycEoQ0EwcnyHAeoOFhIDW8xQWJucWZ6RD5U4yKUuK8oSAJAZBE RmkeXC8s+bxiFAd6RZi3GaSKB5i44LpfAQ1mAho8c6kFyOCSRISUVANjy7nXJ86nFeXxVp29 G8V6L2zvfoX73JuuKZ6dmX9ebPOus5tsrzbo/+ZbeXbntt7tt+MfbZieI/YsRaVfMLstt4bx 5Ddx9qLo2OnzudYsSD4x4caFFXelE+533ZGMMunz+Vrlq7Kz2vWYgbH43evcL9796GR4sSEi pV/OqKWybavyyyalfRzLlViKMxINtZiLihMBhDb/oBkDAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/mMoJqtEYVfhZFMwsPMfrTjpSkVU>
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:20:33 -0000

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.

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