The yak needs to be sheered to make way for better hair. From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer Sent: Friday, August 16, 2013 7:07 AM To: Torsten Lodderstedt Cc: m...@gluu.org; oauth@ietf.org Subject: Re: [OAUTH-WG] OX needs Dynamic Registration: please don't remove!
+1 Let's not shave a yak quite yet. On 08/16/2013 01:32 AM, Torsten Lodderstedt wrote: +1 Dyn reg should fit into the OAuth system as it is now, which uses client ids and secrets. A (probably) improved OAuth is a completely different topic. Let's handle it separately. John Bradley <ve7...@ve7jtb.com><mailto:ve7...@ve7jtb.com> schrieb: Yes a bearer token that is signed and or encrypted by the AS reduces the amount of state required for the AS to maintain. In RFC 6749 there is information about the client that is tied to the client_id, and is required at the authorization endpoint. (eg redirect_uri) I understand the goal of reducing state in the IdP. Some of us have looked at storing information in a signed client_id that would work in the existing RFC 6749 flows. It seems that some people are dissatisfied with RFC 6749 and would like to see changes like removing implicit flows. The current Dynamic registration spec deals with the current state of OAuth. If the WG decides to do a OAuth 3 that fully supports assertions and ditches secrets I would be OK with that. However lets not cripple what we have as a standard now by crating dynamic registration that can only be fully implemented in a future version of OAuth. Some peopl e want/need a client registration API now. It is clearly a missing part of an entire OAuth system. Supporting existing OAuth while minimizing state at the AS is something I support, waiting for a OAuth redesign is not in my opinion a reasonable medium term goal. John B. On 2013-08-14, at 11:47 PM, Phil Hunt <phil.h...@oracle.com><mailto:phil.h...@oracle.com> wrote: I am saying a bearer token is better than a password for the service provider as Hannes explains. Phil On 2013-08-14, at 19:42, Nat Sakimura <sakim...@gmail.com><mailto:sakim...@gmail.com> wrote: Right. A Bearer Token does not have to be a shared secret. It may have some structure that allows the server to validate it statelessly, e.g. JWS-JWT. =nat via iPhone Aug 14, 2013 15:32、Hannes Tschofenig <hannes.tschofe...@gmx.net><mailto:hannes.tschofe...@gmx.net> のメッセージ: George is correct with his statements. There is, however, a difference between a shared secret and an assertion as Phil pointed out. For the assertion the server does not need to maintain state on a per-client basis. On the other hand since the client secret isn't really used in the classical sense of a password either but rather as a "cookie" (if used in the style of Section 2.3.1 of RFC6749) one could easy apply the concept of stateless tokens to them: http://tools.ietf.org/html/draft-rescorla-stateless-tokens-01 On 08/13/2013 07:21 PM, George Fletcher wrote: Hi Phil, I'm sorry for not following completely. Some questions inline... On 8/13/13 11:00 AM, Phil Hunt wrote: Dyn reg and the scim reg variant depend too much/biased towards passwords expressed as client secrets. I'm not sure what you mean in regards to "client secrets". There are OAuth2 bearer tokens that need to be protected because they are bearer tokens. That said, there is nothing in the spec that requires these to be opaque blobs vs signed tokens. So both the "Initial Access Token" and the "Registration Access Token" can be signed tokens. However, the client still has to protect them as if they were a "secret" because they are a bearer token and can be replayed. So it's the same amount of work on the client either way . A signed token approach has many advantages for service providers like not having to maintain a secure database of secrets/passwords. If the concern here is the amount of data the Authorization Server has to store to manage these clients, then the current spec doesn't preclude using a "signed token". Both OAuth2 bearer tokens identified in the current spec can be signed tokens. 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. Given that client_secrets are OPTIONAL in OAuth2 for some use cases, I'm not sure how you abstract the client developer from having to deal with them. The client developer is going to be dealing with multiple OAuth2 tokens to multiple endpoints regardless so I don't see another token as costly or complex. At a minimum there is the refresh_token and access_token. Where is the added client developer complexity? Thanks, George Phil On 2013-08-13, at 7:48, Justin Richer <jric...@mitre.org<mailto:jric...@mitre.org> <mailto:jric...@mitre.org><mailto:jric...@mitre.org>> 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 ta king 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:gffle...@aol.com] *Sent:* Tuesday, August 13, 2013 7:40 AM *To:* Anthony Nadalin *Cc:* m...@gluu.org<mailto:m...@gluu.org>; Justin Richer; oauth@ietf.org<mailto:oauth@ietf.org> *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 refe rring 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 [snip...] ________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth -- ________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth ________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth ________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth ________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth ________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
