This is not new contention, look back in the mailing list, been going on for quite a while. So far I have only seen 2 replies for implementations. The idea is to get things right.
-----Original Message----- From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eve Maler Sent: Thursday, August 15, 2013 3:18 PM To: John Bradley Cc: m...@gluu.org; oauth@ietf.org Subject: Re: [OAUTH-WG] OX needs Dynamic Registration: please don't remove! Agree with John that RFC 6749 is to all intents and purposes final. Also, when we have a dyn reg spec whose earliest drafts are several years old, whose current draft is implemented by a variety of OAuth, OpenID Connect, and UMA developers, whose current design reflects a good deal of healthy consolidation of disparate starting points, and for which there's been concrete demand expressed on this list, I'm a little surprised that there's this much contention about it at this juncture. Eve On 15 Aug 2013, at 1:35 PM, John Bradley <ve7...@ve7jtb.com> wrote: > I believe it is rare for RFC to move beyond the stage RFC 6749 is currently > at so It is to most peoples minds finished. > > I am not against doing future things to improve the spec. I just suspect > that opening that can of worms again will take time. > > John B. > > On 2013-08-15, at 4:23 PM, Phil Hunt <phil.h...@oracle.com> wrote: > >> John, >> >> I agree a big part of the problem with Dyn Reg is it has to reflect the >> current state of 6749 (specifically that clients must have a client_id even >> though 6749 says nothing about its format or how to obtain one). >> >> Regarding timing (the need to approve dyn reg now): a draft doesn't have to >> be final for people to implement it into operational production. In fact, >> putting into production is a far better validation than mere implementation. >> The fact that 6749 changed substantially in draft stage did not prevent many >> from putting it into production. Why is approval a barrier in this case? >> My understanding is the IESG has the option force the draft to wait for >> operational use before it mores forward (see below). >> >> I'm not sure an OAuth 3 is required here since 6749 is not yet final, rather >> it is "PROPOSED STANDARD". In particular, section 4.1.1 of RFC2026 states: >> >>> A Proposed Standard specification is generally stable, has resolved >>> known design choices, is believed to be well-understood, has >>> received significant community review, and appears to enjoy enough >>> community interest to be considered valuable. However, further >>> experience might result in a change or even retraction of the >>> specification before it advances. >> >>> Usually, neither implementation nor operational experience is >>> required for the designation of a specification as a Proposed >>> Standard. However, such experience is highly desirable, and will >>> usually represent a strong argument in favor of a Proposed Standard >>> designation. >> >>> >>> The IESG may require implementation and/or operational experience >>> prior to granting Proposed Standard status to a specification that >>> materially affects the core Internet protocols or that specifies >>> behavior that may have significant operational impact on the >>> Internet. >> >> >> This would suggest to me, that some of OAuth issues that drove the design of >> Dyn-Reg can be more cleanly resolved by amending 6749. Such a change would >> be permissive, backward compatible, and greatly simplify registration if not >> eliminate it in many cases. >> >> The subject of improper use of OAuth as an authenticator is also an issue >> that should be discussed when it comes to moving the proposed standard >> (OAuth 2) forward. >> >> Phil >> >> @independentid >> www.independentid.com >> phil.h...@oracle.com >> >> >> >> >> >> >> >> On 2013-08-15, at 12:59 PM, John Bradley <ve7...@ve7jtb.com> wrote: >> >>> 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 Eve Maler http://www.xmlgrrl.com/blog +1 425 345 6756 http://www.twitter.com/xmlgrrl _______________________________________________ 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
