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 >
- [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