Re: [OAUTH-WG] OX needs Dynamic Registration: please don't remove!

Tue, 13 Aug 2013 08:09:55 -0700

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] 
<mailto:[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]>  [mailto:[email protected]]

    Sent: Tuesday, August 13, 2013 7:22 AM

    To: Anthony Nadalin

    Cc: Justin Richer; George Fletcher;[email protected]  <mailto:[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]>  
[mailto:[email protected]] ON BEHALF

        OF Justin Richer

          SENT: Tuesday, August 13, 2013 6:59 AM

          TO: George Fletcher

          CC:[email protected]  <mailto:[email protected]>;[email protected]  
<mailto:[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]  <mailto:[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]  <mailto:[email protected]>


                      


                    https://www.ietf.org/mailman/listinfo/oauth  [3]


                  


                _______________________________________________


                  


                OAuth mailing list


                  


                [email protected]  <mailto:[email protected]>


                  


                https://www.ietf.org/mailman/listinfo/oauth  [3]


              


            --

            [4]


              


            _______________________________________________


              


            OAuth mailing list


              


            [email protected]  <mailto:[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> <http://connect.me/gffletch>



_______________________________________________
OAuth mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth



_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth






















					Reply via email to