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
