Fair points. I also think this is an area where good online documentation,
and books like *OAuth 2 in Action* can help, and possibly help a lot sooner.
On Thu, Apr 7, 2016 at 4:15 PM, Adam Lewis <***@motorolasolutions.com
> wrote:
> +1
>
> I will not comment on the timeline for this, but I will passionately
> endorse the need for an OAuth 2.1 spec.
>
> Speaking as somebody who now has spent years advocating for, and building
> out public safety / first responder architectures built on an OAuth 2.0
> architecture, I can say 2 things with conviction:
>
> The good: OAuth 2.0 has enabled incredible use cases for us, and it is a
> gift that keeps on giving, the new WG efforts around POP and token exchange
> are solving even more use cases for us. This is hands down one of the best
> WGs I've known, and the work done here is nothing short of awesome.
>
> The bad: I have yet to meet anybody outside of the WG that really
> understands OAuth 2.0. I mean "really" understands it. (to this day, I
> still think it is only because of the good graces of others in this WG like
> John and Justin that I understand it with the depth that I do). People
> talk about it at high levels, they talk about tokens, but still don't get
> what it is trying to solve nor how to securely deploy it. 99% of the people
> I meet still don't get the difference between authentication and delegated
> authorization. I have dedicated massive amounts of cycles trying to
> educate my own community (and anybody else I meet for that matter). I
> personally found the core RFC very hard to digest, and now I need to refer
> to N more, many of which should be folded into a new 2.1 core spec. All
> this given, It is no wonder there are so many insecure implementations of
> it.
>
> So here's to OAuth 2.1 :-)
>
> -adam
>
> On Thu, Apr 7, 2016 at 1:56 PM, Hardt, Dick <***@amazon.com> wrote:
>
>> I think there are already years of implementation and experience since 2.0
>>
>> If we wait until all the outstanding issues and new features have had
>> implementations and experience, we will never do a 2.1 as there continues
>> to be new things.
>>
>> I would suggest a 2.1 be a clean, simple document of the core spec in one
>> document that includes the security and implementation recommendations.
>>
>> Alternative title: OAuth, The Good Parts. :)
>>
>> — Dick
>>
>>
>>
>>
>> On 4/7/16, 3:25 PM, someone claiming to be "OAuth on behalf of Mike
>> Jones" <oauth-***@ietf.org on behalf of ***@microsoft.com>
>> wrote:
>>
>> Yes - an intentionally conservative, implementation- and
>> experience-driven path.
>>
>> Revising OAuth 2.0 is a *big deal*. We shouldn't even be talking about
>> it until we've completed steps 1-5 below - *including* the "iterate" step,
>> as necessary. If we get this wrong, we'll fragment OAuth, which is a
>> terrible and irresponsible outcome we should consciously avoid at all costs.
>>
>> In particular, we should not recharter for an OAuth 2.1 until we already
>> know what will be in it and know from deployment experience that it's the
>> right stuff.
>>
>> -- Mike
>>
>> -----Original Message-----
>> From: Torsten Lodderstedt [mailto:***@lodderstedt.net]
>> Sent: Thursday, April 7, 2016 3:16 PM
>> To: Mike Jones <***@microsoft.com>
>> Cc: Samuel Erdtman <***@erdtman.se>; Anthony Nadalin <
>> ***@microsoft.com>; ***@ietf.org
>> Subject: Re: [OAUTH-WG] OAuth 2.1
>>
>> Hi Mike,
>>
>> in my opinion, you described a possible path towards 2.1. Would you agree?
>>
>> best regards,
>> Torsten.
>>
>> > Am 07.04.2016 um 13:38 schrieb Mike Jones <***@microsoft.com
>> >:
>> >
>> > I am strongly against creating a 2.1 spec until we have at least a year
>> of deployment experience with the contents we're adding to 2.0, so as not
>> to fragment the OAuth marketplace.
>> >
>> > I think we should:
>> > 1. Continue working on new security mitigations in new drafts (such
>> > as mix-up-mitigation, etc.) that add features to use with 2.0 2.
>> > Continue working on PoP specs (such as pop-key-distribution, etc.)
>> > that add features to use with 2.0 3. Continue working on other new
>> > specs (such as discovery, resource-indicators, etc.) that add features
>> > to use with 2.0 4. Learn from deployment experience with all of them
>> > 5. Iterate if the deployment experience tells us that we need to
>> >
>> > Only after we believe we have all the features right and we know that
>> they work together well should we consider creating a 2.1. If we rush to a
>> 2.1 and get it wrong, we'll lose developers' trust and we'll never get it
>> back.
>> >
>> > -- Mike
>> >
>> > -----Original Message-----
>> > From: OAuth [mailto:oauth-***@ietf.org] On Behalf Of Samuel
>> > Erdtman
>> > Sent: Thursday, April 7, 2016 12:48 PM
>> > To: Anthony Nadalin <***@microsoft.com>
>> > Cc: ***@ietf.org
>> > Subject: Re: [OAUTH-WG] OAuth 2.1
>> >
>> > +1 on a 2.1 version
>> >
>> > -1 on defining scopes more precisely in 2.1
>> >
>> > Sent from my iPhone
>> >
>> >> On 7 apr. 2016, at 14:46, Anthony Nadalin <***@microsoft.com>
>> wrote:
>> >>
>> >> I don't belive that scopes should be defined more precisely as this
>> opaqueness was a design feature, I'm not seeing the reason why scopes need
>> to be defined, as these are application specific.
>> >>
>> >> -----Original Message-----
>> >> From: OAuth [mailto:oauth-***@ietf.org] On Behalf Of Torsten
>> >> Lodderstedt
>> >> Sent: Thursday, April 7, 2016 5:32 AM
>> >> To: George Fletcher <***@aol.com>
>> >> Cc: ***@ietf.org
>> >> Subject: Re: [OAUTH-WG] OAuth 2.1
>> >>
>> >> Hi all,
>> >>
>> >> as I already said in the meeting: I would very much prefer to have an
>> extension/update of RFC 6819 covering all "new" threats, including:
>> >> - mix up
>> >> - code injection aka copy and paste
>> >> - open redirector at AS and client
>> >> - potential other threats in the context of "dynamic" OAuth
>> >>
>> >> I also assume mitigations for (at least some of) the threats need to
>> go into an update of RFC 6749 as normative text. To give an example: if we
>> agree on using the state parameter at the token endpoint to mitigate code
>> injection, this MUST be part of the core spec (request description and
>> security consoderations). Otherwise, noone will even consider it.
>> >>
>> >> We should also use the opportunity to improve/enhance the text of the
>> spec. In the course of the last years, we have learned a lot about
>> ambiquities of the text and how different implementations utilize OAuth.
>> >>
>> >> I think time is right to define scopes more precisely. As the
>> discussions in the last days proved again (at least for me), scope is not
>> sufficiently defined to come up with interoperable implementations.
>> Additionally, there seems to be a need to represent resource server
>> locations (to not say identities :-)) in this context.
>> >>
>> >> To bundle all changes in a version 2.1 would also make communication
>> into the market much easier.
>> >>
>> >> best regards,
>> >> Torsten.
>> >>
>> >>> Am 06.04.2016 um 16:05 schrieb George Fletcher <***@aol.com>:
>> >>>
>> >>> I'd definitely prefer a single solution document to many little ones
>> that have to be combined to actually build a secure solution. It's already
>> getting complex with the additional specs that have been added.
>> >>>
>> >>> Additionally, I'm not against working on OAuth 2.1.
>> >>>
>> >>> Thanks,
>> >>> George
>> >>>
>> >>>> On 4/6/16 2:06 PM, Phil Hunt (IDM) wrote:
>> >>>>
>> >>>> Existing implementations are for the large part ok and do not need
>> these mitigations.
>> >>>>
>> >>>> Only the new use cases we have been discussing (configure on the fly
>> and multi-as, etc) really need mitigation.
>> >>>>
>> >>>> The updated by approach seems like a good way to address the new
>> cases.
>> >>>>
>> >>>> Phil
>> >>>>
>> >>>>> On Apr 6, 2016, at 14:35, Hannes Tschofenig <
>> ***@gmx.net> wrote:
>> >>>>>
>> >>>>> Hi all,
>> >>>>>
>> >>>>> today we discussed the OAuth Authorization Server Mixup draft. We
>> >>>>> were wondering what types of threats the document should find
>> solutions for.
>> >>>>>
>> >>>>> We discussed various document handling approaches including
>> >>>>> * OAuth Mix-Up and Cut-and-Paste attacks documented in separate
>> >>>>> solution documents
>> >>>>> * combined solution document covering the OAuth Mix-Up and the
>> >>>>> Cut-and-Paste attacks.
>> >>>>>
>> >>>>> Barry pointed out that these documents could update the OAuth base
>> >>>>> specification.
>> >>>>>
>> >>>>> As a more radical change it was also suggested to revise RFC 6749
>> >>>>> "OAuth
>> >>>>> 2.0 Authorization Framework" and RFC 6819 "OAuth 2.0 Threat Model
>> >>>>> and Security Considerations".
>> >>>>>
>> >>>>> Opening up the OAuth base specification obviously raises various
>> >>>>> other questions about cleaning up parts that go far beyond the AS
>> >>>>> mix-up and the cut-and-paste attacks. Other specifications, such
>> >>>>> as the Open Redirector, could be folded into such a new
>> specification.
>> >>>>>
>> >>>>> Derek and I would appreciate your input on this topic before we
>> >>>>> make a decision since it has significant impact on our work.
>> >>>>>
>> >>>>> Ciao
>> >>>>> Hannes & Derek
>> >>>>>
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> OAuth mailing list
>> >>>>> ***@ietf.org
>> >>>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fw
>> >>>>> w
>> >>>>> w
>> >>>>> .ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40mi
>> >>>>> c
>> >>>>> r
>> >>>>> osoft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91a
>> >>>>> b
>> >>>>> 2
>> >>>>> d7cd011db47%7c1&sdata=BqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%
>> >>>>> 3
>> >>>>> d
>> >>>> _______________________________________________
>> >>>> OAuth mailing list
>> >>>> ***@ietf.org
>> >>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww
>> .
>> >>>> ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40micr
>> >>>> o
>> >>>> s
>> >>>> oft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d
>> >>>> 7 c
>> >>>> d011db47%7c1&sdata=BqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d
>> >>>
>> >>> _______________________________________________
>> >>> OAuth mailing list
>> >>> ***@ietf.org
>> >>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.
>> >>> i
>> >>> etf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40micros
>> >>> o
>> >>> f
>> >>> t.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd
>> >>> 0
>> >>> 1 1db47%7c1&sdata=BqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d
>> >>
>> >> _______________________________________________
>> >> OAuth mailing list
>> >> ***@ietf.org
>> >> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.
>> >> i
>> >> etf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microso
>> >> f
>> >> t.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd0
>> >> 1 1db47%7c1&sdata=BqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d
>> >>
>> >> _______________________________________________
>> >> OAuth mailing list
>> >> ***@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/oauth
>> >
>> > _______________________________________________
>> > OAuth mailing list
>> > ***@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>> >
>> > _______________________________________________
>> > OAuth mailing list
>> > ***@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> ***@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> ***@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>