Subject: [OAUTH-WG] OAuth 2.1

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 6 Apr 2016 19:35:18 +0200

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

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Wed, 6 Apr 2016 15:06:30 -0300

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 <[email-masked]> wrote:
> 
> Hi all,
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: George Fletcher <[email-masked]>
Date: Wed, 6 Apr 2016 15:05:06 -0400

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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 7 Apr 2016 09:32:25 -0300

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 <[email-masked]>:
> 
> 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.
>

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 7 Apr 2016 12:46:37 +0000

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:[email-masked]] On Behalf Of Torsten Lodderstedt
Sent: Thursday, April 7, 2016 5:32 AM
To: George Fletcher <[email-masked]>
Cc: [email-masked]
Subject: Re: [OAUTH-WG] OAuth 2.1

Hi all,

best regards,
Torsten.

>>> today we discussed the OAuth Authorization Server Mixup draft. We 
>>> were wondering what types of threats the document should find solutions for.
>>> 
>>> 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
>>> 
>>> 
>>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww
>>> .ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40micr
>>> osoft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2
>>> d7cd011db47%7c1&sdata=BqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d
>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.
>> ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40micros
>> oft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7c
>> d011db47%7c1&sdata=BqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d
> 
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.i
> etf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsof
> t.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd01
> 1db47%7c1&sdata=BqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d

_______________________________________________
OAuth mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=BqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d

---

From: Samuel Erdtman <[email-masked]>
Date: Thu, 7 Apr 2016 17:47:51 +0200

+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 <[email-masked]> wrote:
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 7 Apr 2016 16:38:15 +0000

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:[email-masked]] On Behalf Of Samuel Erdtman
Sent: Thursday, April 7, 2016 12:48 PM
To: Anthony Nadalin <[email-masked]>
Cc: [email-masked]
Subject: Re: [OAUTH-WG] OAuth 2.1

+1 on a 2.1 version

Sent from my iPhone

>>>> 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
>>>> 
>>>> 
>>> oft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7
>>> c d011db47%7c1&sdata=BqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d
>> 
>> i 
>> t.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd0
>> 1 1db47%7c1&sdata=BqcE9eDhm8pgdoitrPFufouxS6qYndnkLgLa5SPk2HI%3d
>

---

From: Aaron Parecki <[email-masked]>
Date: Thu, 7 Apr 2016 09:41:05 -0700

The primary critique of OAuth 2.0 right now is that simply reading and
implementing the spec does not guarantee interoperable implementations. If
there is going to be a new OAuth 2.1 version, then it only makes sense to
go through that effort if it will actually lead to interoperable
implementations. Otherwise there is very little actually communicated to
the market that is useful.

I agree with Mike that we need more actual deployment experience before we
should consider creating a 2.1 version. The 2.1 version should be based on
the implementation experience learned, rather than making it up right now.

----
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>

On Thu, Apr 7, 2016 at 9:38 AM, Mike Jones <[email-masked]>
wrote:

> 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
> 3.  Continue working on other new specs (such as discovery,
> resource-indicators, etc.) that add features to use with 2.0
> 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
>
> > 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.
> >
> > 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
> > 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.
> >
> that have to be combined to actually build a secure solution. It's already
> getting complex with the additional specs that have been added.
> >>
> >>> Only the new use cases we have been discussing (configure on the fly
> and multi-as, etc) really need mitigation.
> >>>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 7 Apr 2016 15:13:02 -0300

Hi Tony,

I'm not saying we need to define scopes or scope values. These are certainly application/API specific.

Here are the issues I see:
- Namespaces: there is no guidance on how to prevent clashes among scopes for different applications. Say we had used the scope value "email" for our email service before we implemented OIDC. How should we have solved the naming conflict with the respective claim-related scope value "email"?
Resource servers: it's perfectly possible to represent resource server ids in scope values today. BUT: not in an interoperable way. That's why we have concepts like aud, audience, resource on the table in different recent specs. They all try to circumvent the same problem.
- Is the scope supposed to describe the grant of the code, the refresh or the access token? We had an interresting side discussion about that topic and it seems everyone has another _opinion_ about it and implementations differ.

I'm mostly interested in support for multi-application deployments and my conclusion is: The current scope concept only works in multi-application deyployments if:
- there are ecosystem-specific rules of how to use scope values (good luck with standard applications and forget interop)
- there is one AS per application (terrible UX)

We can do better.

best regards,
Torsten.

> Am 07.04.2016 um 09:46 schrieb Anthony Nadalin <[email-masked]>:
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 7 Apr 2016 15:15:49 -0300

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 <[email-masked]>:
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 7 Apr 2016 18:25:34 +0000

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:[email-masked]] 
Sent: Thursday, April 7, 2016 3:16 PM
To: Mike Jones <[email-masked]>
Cc: Samuel Erdtman <[email-masked]>; Anthony Nadalin <[email-masked]>; [email-masked]
Subject: Re: [OAUTH-WG] OAuth 2.1

Hi Mike,

best regards,
Torsten.

> 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 
>>>>> mix-up and the cut-and-paste attacks. Other specifications, such 
>>>>> as the Open Redirector, could be folded into such a new specification.
>>>>> 
>>>>> 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
>>>> ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40micr
>>>> o
>>>> s
>>>> oft.com%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d
>>>> 7 c 
>>> etf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40micros
>>> o
>>> f

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Thu, 7 Apr 2016 15:38:00 -0300

I believe all we need is a new draft that deals with the new "dynamic/mix-up" cases as these were not considered in the original spec process. 

The updated by method works best for this. It also consolidates a lot of piecemeal specs into one consistent spec. 

Phil

> On Apr 7, 2016, at 15:25, Mike Jones <[email-masked]> wrote:
>

---

From: "Hardt, Dick" <[email-masked]>
Date: Thu, 7 Apr 2016 18:56:08 +0000

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" <[email-masked] on behalf of [email-masked]> wrote:

				-- Mike

-----Original Message-----
From: Torsten Lodderstedt [mailto:[email-masked]] 
Sent: Thursday, April 7, 2016 3:16 PM
To: Mike Jones <[email-masked]>
Cc: Samuel Erdtman <[email-masked]>; Anthony Nadalin <[email-masked]>; [email-masked]
Subject: Re: [OAUTH-WG] OAuth 2.1

Hi Mike,

best regards,
Torsten.

---

From: William Denniss <[email-masked]>
Date: Thu, 7 Apr 2016 15:56:11 -0300

On Thu, Apr 7, 2016 at 3:25 PM, Mike Jones <[email-masked]>
wrote:

> 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

I agree with Mike, it's too soon to consider a 2.1 rev until we've had a
chance to test and iterate on the current incremental additions.

At some point it would make sense to collect the ones that worked and were
widely deployed into a single doc.

> > 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:
> > 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
> >

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 07 Apr 2016 15:58:58 -0300

And what about code injection and open redirectors? I think we already have a lot of deployment experience that should be used to evolve the spec.

Sent by MailWise – See your emails as clean, short chats.

---

From: Adam Lewis <[email-masked]>
Date: Thu, 7 Apr 2016 14:15:27 -0500

+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 <[email-masked]> wrote:

> 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.
>
> On 4/7/16, 3:25 PM, someone claiming to be "OAuth on behalf of Mike Jones"
> <[email-masked] on behalf of [email-masked]> wrote:
>

---

From: William Denniss <[email-masked]>
Date: Thu, 7 Apr 2016 16:20:52 -0300

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 <[email-masked]

>> On 4/7/16, 3:25 PM, someone claiming to be "OAuth on behalf of Mike
>> Jones" <[email-masked] on behalf of [email-masked]>
>> wrote:
>>
>> 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.
>>
>> > Am 07.04.2016 um 13:38 schrieb Mike Jones <[email-masked]
>> >:
>> >
>> >> 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
>> .

---

From: "Hardt, Dick" <[email-masked]>
Date: Thu, 7 Apr 2016 19:26:11 +0000

When do we decide there are no more incremental improvements?

There has been a ton of work and experience since I was last involved that is not readily available to your average developer.

I suspect the active participants in the WG take all of these items for granted and don't appreciate the delta since the 2.0 spec.

-- Dick

On Apr 7, 2016, at 3:58 PM, William Denniss <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Apr 7, 2016 at 3:25 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
Yes - an intentionally conservative, implementation- and experience-driven path.

                                -- Mike

I agree with Mike, it's too soon to consider a 2.1 rev until we've had a chance to test and iterate on the current incremental additions.

At some point it would make sense to collect the ones that worked and were widely deployed into a single doc.

-----Original Message-----
From: Torsten Lodderstedt [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, April 7, 2016 3:16 PM
To: Mike Jones <[email-masked]<mailto:[email-masked]>>
Cc: Samuel Erdtman <[email-masked]<mailto:[email-masked]>>; Anthony Nadalin <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] OAuth 2.1

Hi Mike,

best regards,
Torsten.

> Am 07.04.2016 um 13:38 schrieb Mike Jones <[email-masked]<mailto:[email-masked]>>:
>
> From: OAuth [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Samuel
> Erdtman
> To: Anthony Nadalin <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>
>> On 7 apr. 2016, at 14:46, Anthony Nadalin <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> From: OAuth [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Torsten
>> Lodderstedt
>> To: George Fletcher <[email-masked]<mailto:[email-masked]>>
>> Cc: [email-masked]<mailto:[email-masked]>
>>> Am 06.04.2016 um 16:05 schrieb George Fletcher <[email-masked]<mailto:[email-masked]>>:
>>>
>>>>> On Apr 6, 2016, at 14:35, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> [email-masked]<mailto:[email-masked]>
>>>>> .ietf.org<http://ietf.org>%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40mi
>>>>> c
>>>>> r
>>>>> osoft.com<http://osoft.com>%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91a
>>>>> b
>>>>> 2
>>>> [email-masked]<mailto:[email-masked]>
>>>> ietf.org<http://ietf.org>%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40micr
>>>> o
>>>> s
>>>> oft.com<http://oft.com>%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d
>>>> 7 c
>>> [email-masked]<mailto:[email-masked]>
>>> etf.org<http://etf.org>%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40micros
>>> o
>>> f
>>> t.com<http://t.com>%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd
>>> 0
>> [email-masked]<mailto:[email-masked]>
>> etf.org<http://etf.org>%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microso
>> f
>> t.com<http://t.com>%7cce8c942bed81437aca0408d35ee0be21%7c72f988bf86f141af91ab2d7cd0
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: "Hardt, Dick" <[email-masked]>
Date: Thu, 7 Apr 2016 20:08:28 +0000

My personal interest is to get a chance to simplify the document and add non-normative text to clarify many of the areas that have caused confusion.

I’m clearly biased, but I think my original draft was much easier to read https://tools.ietf.org/html/draft-hardt-oauth-01

It could be 2.1 or 2.0.x or 2.0A

On 4/7/16, 4:20 PM, someone claiming to be "William Denniss" <[email-masked]<mailto:[email-masked]>> wrote:

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 <[email-masked]<mailto:[email-masked]>> 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.

-adam

On Thu, Apr 7, 2016 at 1:56 PM, Hardt, Dick <[email-masked]<mailto:[email-masked]>> wrote:
I think there are already years of implementation and experience since 2.0

— Dick

On 4/7/16, 3:25 PM, someone claiming to be "OAuth on behalf of Mike Jones" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

                                -- Mike

-----Original Message-----
From: Torsten Lodderstedt [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, April 7, 2016 3:16 PM
To: Mike Jones <[email-masked]<mailto:[email-masked]>>
Cc: Samuel Erdtman <[email-masked]<mailto:[email-masked]>>; Anthony Nadalin <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] OAuth 2.1

Hi Mike,

best regards,
Torsten.

---

From: Brian Campbell <[email-masked]>
Date: Mon, 11 Apr 2016 13:44:45 -0600

+1