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 >>>> >>> >> >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
