Before everyone gets excited, all John and was referring to was providing further definition on client_id that allows scenarios where the id isn't issued by the AS but rather a federated entity.
This in no way changes how 6749 works. In particular for javascript clients it would avoid the incredible cost of registration for EVERY execution of a script. Dyn Reg currently has to assume a client_id must be issued by the as the controls access to the resource endpoint. The change here is on the level of errata. Never-the-less we are permitted to change as the standard is technically not final. (Yet as pointed out in practice it is) Phil On 2013-08-15, at 22:32, Torsten Lodderstedt <tors...@lodderstedt.net> 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> 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 peop! >> le >> 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 wa! >>>>>> y. >>>>>> >>>>>> >>>>>>> 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 t! >>>>>>>> aking >>>>>>>> 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 ref! >>>>>>>>> erring >>>>>>>>> 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
