Yes but the two of us going back and forth seem not to be making progress. I am still at the IDESG meeting if you want to get together.
On 2013-05-09, at 5:19 PM, Phil Hunt <phil.h...@oracle.com> wrote: > 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 >>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
