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 <[email protected]> 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 > [email protected] > > > > > > > > On 2013-08-15, at 12:59 PM, John Bradley <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> のメッセージ: >>>> >>>>> 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 <[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 >>>>>>>>> >>>>>>>>> [snip...] >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OAuth mailing list >>>>>>> [email protected] >>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> >>>>>> -- >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> [email protected] >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> _______________________________________________ >>>> OAuth mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/oauth >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/oauth >> >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
