Dyn reg and the scim reg variant depend too much/biased towards passwords expressed as client secrets.
A signed token approach has many advantages for service providers like not having to maintain a secure database of secrets/passwords. Finally issuing both a client secret and registration token is costly and confusing to client developers. I relented somewhat when I realized kerberos does this--but i still feel it is a bad design at cloud scale. Phil On 2013-08-13, at 7:48, Justin Richer <[email protected]> wrote: > The spec doesn't care where you deploy at -- if URL space is at a premium for > you, then switch based on input parameters and other things. And you're still > not clear on which "secrets" you're taking issue with. > > -- Justin > > On 08/13/2013 10:46 AM, Anthony Nadalin wrote: >> #1, its yet another endpoint to have to manage secrets at, yes this is an >> OAuth item but it’s growing out of control, we are trying to move away from >> secrets and management of these endpoints as this would be just another one >> we have to support, monitor and report on >> #2 yes, 1 physical endpoint acting as multiple authorization servers >> >> From: George Fletcher [mailto:[email protected]] >> Sent: Tuesday, August 13, 2013 7:40 AM >> To: Anthony Nadalin >> Cc: [email protected]; Justin Richer; [email protected] >> Subject: Re: [OAUTH-WG] OX needs Dynamic Registration: please don't remove! >> >> Hi Tony, >> >> Could you please explain a little more? >> >> For issue 1: >> * Which "secret" are you referring to? OAuth2 by default allows for an >> optional client_secret. I'm not sure why this would cause management issues? >> Or are you referring to the "Registration Access Token"? >> * Why is a separate endpoint an issue? Any client is going to be talking to >> more than just the /authorize and /token endpoints anyway so I'm confused >> regarding the extra complexity? >> >> For issue 2: >> * What specifically do you mean by "multi-tenant"? Is this one server acting >> on behalf of multiple tenants and so appearing as multiple Authorization >> Servers? >> >> Thanks, >> George >> >> On 8/13/13 10:34 AM, Anthony Nadalin wrote: >> So, (1) Management of the secret causes us management issues, yet another >> endpoint to manage, there may be ways around this issue with assertions. (2) >> The schema/data model are not useable as defined. Internationalization is an >> issue. Multi-tenant issues, this also goes back to schema/data model. >> >> >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] >> Sent: Tuesday, August 13, 2013 7:22 AM >> To: Anthony Nadalin >> Cc: Justin Richer; George Fletcher; [email protected] >> Subject: RE: [OAUTH-WG] OX needs Dynamic Registration: please don't remove! >> >> Anthony, >> >> As I mentioned, we are using it as part of the OX UMA implementation. >> Can you be more specific? >> 1) What parts of it would cause add'l management? >> 2) What parts do not meet your requirements that could not be satisfied >> with a >> supplemental profile? >> >> - Mike >> >> >> >> On 2013-08-13 09:15, Anthony Nadalin wrote: >> Who has implemented draft-ietf-oauth-dyn-reg-14 [5] and is in >> production (of some sort) ? We have no plans to implement as it does >> not meet our requirements/use cases and causes additional management >> and thus I believe would not serve as a valid core document to expand >> upon. >> >> FROM: [email protected] [mailto:[email protected]] ON BEHALF >> OF Justin Richer >> SENT: Tuesday, August 13, 2013 6:59 AM >> TO: George Fletcher >> CC: [email protected]; [email protected] >> SUBJECT: Re: [OAUTH-WG] OX needs Dynamic Registration: please don't >> remove! >> >> +1 >> >> On 08/13/2013 09:34 AM, George Fletcher wrote: >> >> I know I wasn't at the IETF meeting but I'm confused regarding all >> this talk of "lack of consensus". It seems to me there is a lot of >> consensus regarding the existing spec (given all the current >> implementations). Couple that with the fact that the current spec >> doesn't exclude the additional use cases that you've raised, I don't >> see why we don't establish the current spec as the core document and >> then develop profiles for the additional use cases. It is unlikely >> that there is going to be a true single solution because to cover all >> the use cases it will have to be so flexible that profiles will arise >> regardless. In that case, let's build off the solid core that we have >> and add these additional profiles providing a win-win for >> implementers. >> >> My 2 cents:) >> >> Thanks, >> George >> >> On 8/12/13 7:55 PM, Phil Hunt wrote: >> >> I don't think there is a call to stop work. However there is a lack >> of consensus on the current draft moving forward. >> >> I too want a single, simple solution. >> >> Phil >> >> On 2013-08-08, at 13:22, [email protected] wrote: >> >> OAuth WG, >> >> As some of you may know, the OX open source project provides an >> implementation of Enterprise UMA, which enables organizations to >> control which people and clients can access web resources. >> >> I rarely weigh in, because you all are doing such great job. >> However, I was quite distressed to learn about the suggestion to >> stop work on the dynamic client registration spec. This proposed >> change would have a negative impact on OX, and the varied adopters >> of our software from around the world. >> >> No standard for dynamic client registration would make OX less >> "standard" by creating a bigger delta between UMA and other OAuth2 >> implementations. As OX also implements the OpenID Connect OP >> endpoints, and dropping this effort would also makes a convergence >> path for client registration less likely. >> >> Please leave dynamic client registration! >> >> Thanks for all your great work! >> >> - Mike Schwartz >> >> Founder / CEO >> >> Gluu >> >> http://gluu.org [1] >> >> PS: Help us crowd fund open source OAuth2 plugins for Apache HTTPD >> : http://www.gluu.co/uma-apache [2] >> >> _______________________________________________ >> >> OAuth mailing list >> >> [email protected] >> >> https://www.ietf.org/mailman/listinfo/oauth [3] >> >> _______________________________________________ >> >> OAuth mailing list >> >> [email protected] >> >> https://www.ietf.org/mailman/listinfo/oauth [3] >> >> -- >> [4] >> >> _______________________________________________ >> >> OAuth mailing list >> >> [email protected] >> >> https://www.ietf.org/mailman/listinfo/oauth [3] >> >> >> >> Links: >> ------ >> [1] http://gluu.org >> [2] http://www.gluu.co/uma-apache >> [3] https://www.ietf.org/mailman/listinfo/oauth >> [4] http://connect.me/gffletch >> [5] http://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/ >> >> >> -- >> <mime-attachment.png> > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
