+1 > On Jan 25, 2016, at 1:39 PM, George Fletcher <gffle...@aol.com> wrote: > > So now, in addition to the dynamic client registration spec, the client would > need to support OAuth2 Discovery. > > I guess my concern is that it feels like we are adding a lot of little things > to try and mitigate these attacks in OAuth2 and it's confusing when they are > needed and when they aren't. > > For me it would be simpler to say that OAuth2 with a single pre-configured AS > is fine. If a client wants to support multiple Authorization Servers (a la > dynamic client registration or some other method) then here are all the > things that need to be done. Maybe this would be simpler as a profile of > OAuth2 (in the vein of OpenID Connect) that adds the necessary requirements > to mitigate these attacks. > > This way an OAuth2 developer knows which spec to follow based on their > requirements and all the necessary steps would be in "one" place. > > Thanks, > George > > On 1/25/16 1:22 PM, John Bradley wrote: >> The presumption is that registration would need to add a issuer, as an >> identifier of the AS, and that would be optionally be used in discovery. >> >> OAuth as is supports the single AS model. >> >> To support multiple AS for a single client something needs to change. >> Adding issuer and client_id to the response with optional discovery was seen >> as the least disruptive at the Germany meeting. >> >> The other way to do it is to return discovery info from the the >> authorization and token endpoints, however the request probably also need to >> be modified so that the AS knows what the resource is, otherwise >> other things will break. >> >> It is possible now to have one authorization endpoint provide code for per >> Tennent token endpoints.(No I don’t know of any one doing it). >> >> Anything we add to tighten up the trust model will have impacts on what can >> be done with OAuth. >> >> John B. >>> On Jan 25, 2016, at 3:10 PM, George Fletcher <gffle...@aol.com >>> <mailto:gffle...@aol.com>> wrote: >>> >>> Comments inline >>> >>> On 1/25/16 12:32 PM, John Bradley wrote: >>>> No, client id_are scoped by issuer. >>> This makes sense, but I'm not sure it's a current assumption by OAuth2 >>> implementations :) >>>> >>>> There is no need for AS to make the client_id globally unique. >>>> >>>> The client needs to not allow two AS to provide it with the same issuer >>>> client_id pair. >>>> >>>> That would probably be imposable for many clients anyway. >>> I would rather say that the results of two client_ids being the same from >>> two different issuers is undefined. >>>> >>>> For Connect clients typically manage configurations using issuer as the >>>> primary key. I doubt may would support even two client_id from the same >>>> issuer. >>> If scoped by issuer this makes sense, though the concept of "issuer" as a >>> comparable entity wasn't really talked about with OAuth2. >>>> >>>> For OAuth what clients do is slightly less clear. In general they don’t >>>> have more than one AS per API do might try and organize things by RS or AS. >>> I agree that not many clients support dynamic client registration. However, >>> I would say there a number that support multiple AS that are "fixed" within >>> the code (including fixed endpoint URIs). So I would say that the >>> associations would be fixed in code. There wouldn't necessarily be an >>> association outside of the code which maps button A to AS1 and button B to >>> AS2. >>>> >>>> In principal a OAuth client might have two different AS each with a >>>> different client ID and that will be OK as long as the client_id in the >>>> request is the same as the one in the response. >>>> >>>> So going to a new AS and getting back the same iss and client_id that you >>>> registered someplace else would be an error for the client. >>>> >>>> I don’t think that is unreasonable. >>> I agree that this is reasonable with the assumption that client_id's are >>> scoped by "issuer". It's just likely that most clients in the field do not >>> have this sort of explicit association. The OAuth2 Dynamic Client >>> Registration spec does not define an "issuer" in the response. For the >>> OAuth2 use cases, what is the proposed "issuer" equivalent URI that is >>> being used to scope the client_id? >>>> >>>> John B. >>>> >>>> >>>>> On Jan 25, 2016, at 12:30 PM, George Fletcher <gffle...@aol.com >>>>> <mailto:gffle...@aol.com>> wrote: >>>>> >>>>> I'm still catching up... but to this point specifically... >>>>> >>>>> Doesn't this require that the same client_id NOT be used simultaneously >>>>> at two (or more) Authorization Servers? If so, I don't believe that is a >>>>> viable option. It's a little late in the game to be putting requirements >>>>> on the AS as to how it generates it's client_id. >>>>> >>>>> Thanks, >>>>> George >>>>> >>>>> On 1/25/16 9:11 AM, John Bradley wrote: >>>>>> >>>>>> Returning the iss and client_id from the authorization endpoint per >>>>>> Mike’s draft allows the client to reject the authorization response and >>>>>> not leak the code. >>>>> >>>> >>> >>> -- >>> Chief Architect >>> Identity Services Engineering Work: george.fletc...@teamaol.com >>> <mailto:george.fletc...@teamaol.com> >>> AOL Inc. AIM: gffletch >>> Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch >>> <http://twitter.com/gffletch> >>> Office: +1-703-265-2544 Photos: http://georgefletcher.photography >>> <http://georgefletcher.photography/> >> > > -- > Chief Architect > Identity Services Engineering Work: george.fletc...@teamaol.com > <mailto:george.fletc...@teamaol.com> > AOL Inc. AIM: gffletch > Mobile: +1-703-462-3494 Twitter: http://twitter.com/gffletch > <http://twitter.com/gffletch> > Office: +1-703-265-2544 Photos: http://georgefletcher.photography > <http://georgefletcher.photography/> > _______________________________________________ > 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
