Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14BB921F9239 for ; Thu, 9 May 2013 14:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqR70YgW+TxC for ; Thu, 9 May 2013 14:57:06 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8E95321F85CC for ; Thu, 9 May 2013 14:57:06 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0A1D72260089; Thu, 9 May 2013 17:57:06 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id EE3EA2260087; Thu, 9 May 2013 17:57:05 -0400 (EDT) Received: from IMCMBX01.MITRE.ORG ([169.254.1.137]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0342.003; Thu, 9 May 2013 17:57:05 -0400 From: "Richer, Justin P." To: Phil Hunt Thread-Topic: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-10.txt Thread-Index: AQHOScki5Sf7tCtsl0WcxmZ0zKLbDJj3Q5YAgAADzoCAAUf0AIAE2dlWgABGDIA= Date: Thu, 9 May 2013 21:57:05 +0000 Message-ID: References: <20130505194505.24986.11173.idtracker@ietfa.amsl.com> <6214B696-54F2-4D26-BB0B-AD045F6A96BB@mitre.org> <6A775D1B-47DE-48BD-849B-D964BAE5B4E9@mitre.org> <9B5D63B5-A923-415C-8593-7EC228256992@oracle.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.36.117] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-10.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 21:57:11 -0000 Part of my argument for leaving this parameter in is exactly the use case t= hat you're saying: the client doesn't tell the server anything but the serv= er tells the client what it must use to authenticate. That's already possib= le using what's there. But I'm loathe to pull out this particular piece of = metadata as non-parallel and separate from the rest of the parameters.=20 The whole negotiation for this or any other parameter can happen at least p= artially out of band, for instance as part of the discovery process. In Blu= e Button+ (reference for others, here: http://blue-button.github.io/blue-bu= tton-plus-pull/), you could either pre-register it or you could do it per-i= nstance. You'd probably pre-register this parameter in most cases though be= cause the nature of the app's capabilities won't really change.=20 What I think this parameter gives you is a *chance* for things to go right = or stop early before they go horribly wrong later in the process where the = stakes are higher. All of the if-then steps I listed out below still exist = if the client can't tell its preferred auth method to the server in-band du= ring registration, the decisions just happen at a different times where it'= s harder to recover programmatically. And since it's an optional parameter = on both sides, people who don't want to deal with the logic to process it d= on't have to do anything with it. -- Justin On May 9, 2013, at 2:44 PM, Phil Hunt wrote: > Justin, >=20 > Just to progress towards resolving this issue, what I would like to under= stand is how specifying authentication type makes things simpler or more in= ter-operable. I'm concerned that the logic you proposed early in the thread= is a lot more complexity. I would prefer just having the server tell the = client what authentication it MUST use. >=20 > As an alternative, the negotiation for credential method/type could occur= during the initial developer registration of the app. As in your "blue bu= tton" health case (did I remember that right), the initial registration JWT= would be used in the dynamic registration and allow the registration serve= r to observe any previously negotiated client preferences OOB of this spec.= Or, are you saying that individual instances have some need to change aut= hentication types on a per deployment basis independent of what the associa= ted authorization server wants them to use? If so what is it? >=20 > Phil >=20 > @independentid > www.independentid.com > phil.hunt@oracle.com >=20 >=20 >=20 >=20 >=20 > On 2013-05-06, at 11:56 AM, Phil Hunt wrote: >=20 >> Justin, >>=20 >> What you describe, though good intentioned, seems like a lot of complexi= ty without getting an actual benefit. I would rather not have token_endpoin= t_auth_method at all. >>=20 >> Think about someone writing a general purpose SCIM client or OIDC client= . Site as uses method 1 and 2, site b supports 2,3 and 4. Site c only 5 a= nd 6. So if each site is willing to negotiate authn, how has this develope= r's coding been reduced? The developer will end up having to implement all = popular methods regardless of discovery or the ability of the client to sel= ect. In fact, they have to do all the logic you describe below AND implemen= t all methods. >>=20 >> I have also thought through, does it matter since it is optional? I thi= nk it does. If servers just ignore the param most of the time, what value i= s there? >>=20 >> Phil >>=20 >> @independentid >> www.independentid.com >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >>=20 >> On 2013-05-06, at 8:39 AM, Richer, Justin P. wrote: >>=20 >>> In spite of what John seems to think, that dependency was never there. = The whole discovery process is related, but separate, from registration. It= could happen using OIDC, it could happen with Bill Mills's LRDD link types= , it could happen with Nat's proposed HAL-based system, it could happen by = the developer going to the service provider's documentation page and readin= g a bunch of text (which is what happens with large OAuth providers today) = -- it ultimately doesn't matter.=20 >>>=20 >>> And I think that the Dynamic Registration protocol that we have here is= robust against that kind of diversity. Let's take the token_endpoint_auth_= method parameter as an example. Let's say a client shows up to a service it= 's just discovered -- through whatever means, we don't actually care. This = client either has some idea of what auth methods the server supports (throu= gh a discovery mechanism) or it doesn't. If it does, it will also know whic= h methods it supports and it can pick one. If it doesn't, it will still kno= w which methods it supports and will just pick one. The server will then ta= ke that information and do one of three things: >>>=20 >>> 1) Accept what the client proposes and use that. This is of course the = ideal situation where everybody gets what they want, and this can be brough= t about more often by a good discovery process. >>> 2) Reject what the client proposes with an error code (invalid_client_m= etadata would cover this). The client then has to re-register with a differ= ent value or just give up because the two systems are using different auth = methods that can't be reconciled. >>> 3) Ignore what the client proposes and return the server's preferred me= thod. The client can then, in turn: >>> a) Accept what the server returns and use that, if it supports it. This= is also ideal because everybody is happy again. >>> b) Reject what the server returns and either try the registration again= with another value or give up. >>> c) Ignore what the server returns and fail when doing a token request. = This would be a dumb thing for a dumb client to do.=20 >>>=20 >>> Alternatively, the client could just not mention it and have the server= dictate what method it will use, and the client will either accept, reject= , or ignore it. This process applies to every parameter in the system, from= something innocuous as the client's TOS uri to something as security-criti= cal as the redirect_uri (which gets its own special error message).=20 >>>=20 >>> I think that the assumption of full automation for all clients to all s= ervers is a red herring in the OAuth world for the simple fact that the API= that's being accessed/protected isn't going to be universally compatible a= nyway. I agree fully that a well-specified service discovery is important a= nd we should, as a working group, help figure out what that looks like. As = mentioned above, several of us already are. But I don't think it's helpful = to conflate the registration and discovery processes and turn them into som= e kind of negotiation system. I think we can do a good job of making it wid= ely useful without that. >>>=20 >>> -- Justin >>>=20 >>> On May 5, 2013, at 1:05 PM, Phil Hunt >>> wrote: >>>=20 >>>> Justin, >>>>=20 >>>> Has the assumption of a discovery service defined by OIDC been removed= ? >>>>=20 >>>> Phil >>>>=20 >>>> @independentid >>>> www.independentid.com >>>> phil.hunt@oracle.com >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On 2013-05-05, at 12:52 PM, Richer, Justin P. wrote: >>>>=20 >>>>> Handful of minor changes in this revision, including tightening the l= anguage around scopes and adding an absolute-URI based mechanism for extend= ing token_endpoint_auth_method (no registry, still). No normative changes b= eyond removing an unreachable error state. (Thanks, Nov.) Please check the = diffs, we welcome feedback. I personally think this is really getting close= to final. >>>>>=20 >>>>> -- Justin >>>>>=20 >>>>> On May 5, 2013, at 3:45 PM, >>>>> wrote: >>>>>=20 >>>>>>=20 >>>>>> A New Internet-Draft is available from the on-line Internet-Drafts d= irectories. >>>>>> This draft is a work item of the Web Authorization Protocol Working = Group of the IETF. >>>>>>=20 >>>>>> Title : OAuth 2.0 Dynamic Client Registration Protocol >>>>>> Author(s) : Justin Richer >>>>>> John Bradley >>>>>> Michael B. Jones >>>>>> Maciej Machulak >>>>>> Filename : draft-ietf-oauth-dyn-reg-10.txt >>>>>> Pages : 25 >>>>>> Date : 2013-05-05 >>>>>>=20 >>>>>> Abstract: >>>>>> This specification defines an endpoint and protocol for dynamic >>>>>> registration of OAuth 2.0 Clients at an Authorization Server and >>>>>> methods for the dynamically registered client to manage its >>>>>> registration. >>>>>>=20 >>>>>>=20 >>>>>> The IETF datatracker status page for this draft is: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg >>>>>>=20 >>>>>> There's also a htmlized version available at: >>>>>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-10 >>>>>>=20 >>>>>> A diff from the previous version is available at: >>>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-10 >>>>>>=20 >>>>>>=20 >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20