You missed both my points entirely. Phil
On 2013-08-13, at 8:05, Justin Richer <[email protected]> wrote: > You can definitely issue or use other kinds of secrets with both dyn reg and > the scim variant -- this was the reason we made a registry for the > token_endpoint_auth_method at your (Phil's) request. Thing is, there weren't > documents that described the authentication mechanisms that we could directly > point to. OIDC has a method of using a client's own public key (which gets > registered with jwks_uri), but that wasn't general enough to include here so > we left it in the OIDC extension document, where it belongs. In that case, > the client wouldn't get a client_secret. The same is true if you issue a > client_assertion as part of the registration process. > > It would get a registration_access_token, though, so that it can manage its > own registration if needed. But that's just a very basic OAuth2 Bearer token, > and if your OAuth server can't handle issuing and validating OAuth tokens, > you probably shouldn't be letting clients register themselves anyway. ;) > > -- Justin > > > On 08/13/2013 11:00 AM, Phil Hunt wrote: >> 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
