The downgrade is at runtime not at registration. It is signalling the methods the RP doesn't want the AS to support for the client_id.
We are not getting anywhere on this. The parameter is required for dynamic registration of higher security clients at AS that support multiple token_endpoint authentication types. John On 2013-05-09, at 4:46 PM, Phil Hunt <phil.h...@oracle.com> wrote: > Maybe i am not being clear. I feel the parameter must not be in the dyn reg > request. The parameter should be in the response so that the client has no > choice and no ability to downgrade. > > Phil > > On 2013-05-09, at 16:37, Phil Hunt <phil.h...@oracle.com> wrote: > >> How does NOT allowing clients to choose authn type allow them to downgrade. >> I am saying there is NO value in allowing this and that the parameter needs >> to be removed. >> >> Phil >> >> On 2013-05-09, at 16:03, John Bradley <ve7...@ve7jtb.com> wrote: >> >>> The issue is not allowing fake clients to dynamically downgrade, where the >>> AS supports multiple methods. >>> >>> >>> On 2013-05-09, at 3:58 PM, Phil Hunt <phil.h...@oracle.com> wrote: >>> >>>> You seem to now be talking about SAML endpoints rather than OAuth >>>> endpoints. >>>> >>>> >>>> I think you are confusing what the client gets back from the AS in terms >>>> of the OAuth protocol vs. how the client authenticates to the AS. The >>>> parameter in question isn't about what assertions the AS returns to the >>>> client. The case is about what credential the client must use with the AS >>>> to satisfy a particular AS's requirements. >>>> >>>> I haven't heard a reason for clients to be able to downgrade. >>>> >>>> Phil >>>> >>>> @independentid >>>> www.independentid.com >>>> phil.h...@oracle.com >>>> >>>> >>>> >>>> >>>> >>>> On 2013-05-09, at 3:47 PM, John Bradley wrote: >>>> >>>>> Consider if you will a world where IdP support multiple LoA. >>>>> >>>>> This allows a RP to register the method required for there use case. >>>>> >>>>> If a Client requires the asymmetrically signed JWT assertions rather than >>>>> http basic, it doesn't want the Authorization server accepting >>>>> http_basic for it's client_id. >>>>> >>>>> The reason a client/RP would want to specify multiple LoA is the same >>>>> reason they may wan to in SAML or other protocols. >>>>> >>>>> The issue is more that different clients will have different security >>>>> requirements and this allows them to dynamic register those. >>>>> >>>>> If you allow 2 and 3 the one that need 3 will specify that. >>>>> >>>>> John >>>>> >>>>> On 2013-05-09, at 3:32 PM, Phil Hunt <phil.h...@oracle.com> wrote: >>>>> >>>>>> Giving the client the choice lets the client choose lower LoA and >>>>>> downgrade. Surely it is the server that is taking the risk so the >>>>>> server has the right to set the requirements. >>>>>> >>>>>> Why would a server tolerate multiple levels of LoA from the same client >>>>>> application? Why is that needed? >>>>>> >>>>>> If a server allows 2 and 3, then all clients will choose 2 -- or at the >>>>>> very least your overall security drops to 2. This is not good. >>>>>> >>>>>> Phil >>>>>> >>>>>> @independentid >>>>>> www.independentid.com >>>>>> phil.h...@oracle.com >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 2013-05-09, at 3:17 PM, John Bradley wrote: >>>>>> >>>>>>> The client needs to be able to say only use a particular auth method to >>>>>>> disallow the Authorization server from providing a weaker method to an >>>>>>> attacker. >>>>>>> >>>>>>> This is a required parameter to allow a Authorization server to support >>>>>>> high and low LoA clients dynamically. >>>>>>> >>>>>>> John B. >>>>>>> >>>>>>> >>>>>>> On 2013-05-09, at 2:44 PM, Phil Hunt <phil.h...@oracle.com> wrote: >>>>>>> >>>>>>>> Justin, >>>>>>>> >>>>>>>> Just to progress towards resolving this issue, what I would like to >>>>>>>> understand is how specifying authentication type makes things simpler >>>>>>>> or more inter-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. >>>>>>>> >>>>>>>> As an alternative, the negotiation for credential method/type could >>>>>>>> occur during the initial developer registration of the app. As in >>>>>>>> your "blue button" health case (did I remember that right), the >>>>>>>> initial registration JWT would be used in the dynamic registration and >>>>>>>> allow the registration server to observe any previously negotiated >>>>>>>> client preferences OOB of this spec. Or, are you saying that >>>>>>>> individual instances have some need to change authentication types on >>>>>>>> a per deployment basis independent of what the associated >>>>>>>> authorization server wants them to use? If so what is it? >>>>>>>> >>>>>>>> Phil >>>>>>>> >>>>>>>> @independentid >>>>>>>> www.independentid.com >>>>>>>> phil.h...@oracle.com >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 2013-05-06, at 11:56 AM, Phil Hunt wrote: >>>>>>>> >>>>>>>>> Justin, >>>>>>>>> >>>>>>>>> What you describe, though good intentioned, seems like a lot of >>>>>>>>> complexity without getting an actual benefit. I would rather not have >>>>>>>>> token_endpoint_auth_method at all. >>>>>>>>> >>>>>>>>> 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 and 6. So if each site is willing to negotiate authn, >>>>>>>>> how has this developer'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 select. In fact, they have to do all the >>>>>>>>> logic you describe below AND implement all methods. >>>>>>>>> >>>>>>>>> I have also thought through, does it matter since it is optional? I >>>>>>>>> think it does. If servers just ignore the param most of the time, >>>>>>>>> what value is there? >>>>>>>>> >>>>>>>>> Phil >>>>>>>>> >>>>>>>>> @independentid >>>>>>>>> www.independentid.com >>>>>>>>> phil.h...@oracle.com >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2013-05-06, at 8:39 AM, Richer, Justin P. wrote: >>>>>>>>> >>>>>>>>>> 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 reading a bunch of text >>>>>>>>>> (which is what happens with large OAuth providers today) -- it >>>>>>>>>> ultimately doesn't matter. >>>>>>>>>> >>>>>>>>>> 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 (through a discovery >>>>>>>>>> mechanism) or it doesn't. If it does, it will also know which >>>>>>>>>> methods it supports and it can pick one. If it doesn't, it will >>>>>>>>>> still know which methods it supports and will just pick one. The >>>>>>>>>> server will then take that information and do one of three things: >>>>>>>>>> >>>>>>>>>> 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 brought about more often by a good discovery process. >>>>>>>>>> 2) Reject what the client proposes with an error code >>>>>>>>>> (invalid_client_metadata would cover this). The client then has to >>>>>>>>>> re-register with a different 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 >>>>>>>>>> method. 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. >>>>>>>>>> >>>>>>>>>> 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-critical as the redirect_uri (which >>>>>>>>>> gets its own special error message). >>>>>>>>>> >>>>>>>>>> I think that the assumption of full automation for all clients to >>>>>>>>>> all servers 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 anyway. I agree fully that a well-specified >>>>>>>>>> service discovery is important and 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 some kind of >>>>>>>>>> negotiation system. I think we can do a good job of making it widely >>>>>>>>>> useful without that. >>>>>>>>>> >>>>>>>>>> -- Justin >>>>>>>>>> >>>>>>>>>> On May 5, 2013, at 1:05 PM, Phil Hunt <phil.h...@oracle.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Justin, >>>>>>>>>>> >>>>>>>>>>> Has the assumption of a discovery service defined by OIDC been >>>>>>>>>>> removed? >>>>>>>>>>> >>>>>>>>>>> Phil >>>>>>>>>>> >>>>>>>>>>> @independentid >>>>>>>>>>> www.independentid.com >>>>>>>>>>> phil.h...@oracle.com >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2013-05-05, at 12:52 PM, Richer, Justin P. wrote: >>>>>>>>>>> >>>>>>>>>>>> Handful of minor changes in this revision, including tightening >>>>>>>>>>>> the language around scopes and adding an absolute-URI based >>>>>>>>>>>> mechanism for extending token_endpoint_auth_method (no registry, >>>>>>>>>>>> still). No normative changes beyond removing an unreachable error >>>>>>>>>>>> state. (Thanks, Nov.) Please check the diffs, we welcome feedback. >>>>>>>>>>>> I personally think this is really getting close to final. >>>>>>>>>>>> >>>>>>>>>>>> -- Justin >>>>>>>>>>>> >>>>>>>>>>>> On May 5, 2013, at 3:45 PM, <internet-dra...@ietf.org> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> A New Internet-Draft is available from the on-line >>>>>>>>>>>>> Internet-Drafts directories. >>>>>>>>>>>>> This draft is a work item of the Web Authorization Protocol >>>>>>>>>>>>> Working Group of the IETF. >>>>>>>>>>>>> >>>>>>>>>>>>> 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 >>>>>>>>>>>>> >>>>>>>>>>>>> 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. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> The IETF datatracker status page for this draft is: >>>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg >>>>>>>>>>>>> >>>>>>>>>>>>> There's also a htmlized version available at: >>>>>>>>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-10 >>>>>>>>>>>>> >>>>>>>>>>>>> A diff from the previous version is available at: >>>>>>>>>>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-10 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>>>>>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>> OAuth@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
