Well this is a last call discussion. So we have to get somewhere don't we? Phil
On 2013-05-09, at 16:55, John Bradley <ve7...@ve7jtb.com> wrote: > 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 > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
