+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> 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 people 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> 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> 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> >のメッセージ: >>> >>>> 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>> 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:gffle...@aol.com] >>>>>>>> *Sent:* Tuesday, August 13, 2013 7:40 AM >>>>>>>> *To:* Anthony Nadalin >>>>>>>> *Cc:* m...@gluu.org; Justin Richer; 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 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 >>>>>>>> >>>>>>>> [snip...] >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>> >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> 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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
