I would also seriously look at the original motivation behind ROPC: I know it has been deployed and is used in quite a lot of places but I have never actually come across a use case where it is used for migration purposes and the migration is actually executed (I know that is statistically not a very strong argument but I challenge others to come up with one...) In reality it turned out just to be a one off that people used as an easy way out to stick to an anti-pattern and still claim to do OAuth 2.0. It is plain wrong, it is not OAuth and we need to get rid of it.
Hans. On Tue, Feb 18, 2020 at 10:44 PM Aaron Parecki <aa...@parecki.com> wrote: > Agreed. Plus, the Security BCP is already effectively acting as a grace > period since it currently says the password grant MUST NOT be used, so in > the OAuth 2.0 world that's already a pretty strong signal. > > Aaron > > > > On Tue, Feb 18, 2020 at 4:16 PM Justin Richer <jric...@mit.edu> wrote: > >> There is no need for a grace period. People using OAuth 2.0 can still do >> OAuth 2.0. People using OAuth 2.1 will do OAuth 2.1. >> >> — Justin >> >> On Feb 18, 2020, at 3:54 PM, Anthony Nadalin < >> tonynad=40microsoft....@dmarc.ietf.org> wrote: >> >> I would suggest a SHOULD NOT instead of MUST, there are still sites using >> this and a grace period should be provided before a MUST is pushed out as >> there are valid use cases out there still. >> >> *From:* OAuth <oauth-boun...@ietf.org> *On Behalf Of *Dick Hardt >> *Sent:* Tuesday, February 18, 2020 12:37 PM >> *To:* oauth@ietf.org >> *Subject:* [EXTERNAL] [OAUTH-WG] OAuth 2.1: dropping password grant >> >> Hey List >> >> (Once again using the OAuth 2.1 name as a placeholder for the doc that >> Aaron, Torsten, and I are working on) >> >> In the security topics doc >> >> >> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-14#section-2.4 >> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-security-topics-14%23section-2.4&data=02%7C01%7Ctonynad%40microsoft.com%7C47bb597eef584c95ba4108d7b4b274b2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637176550905333283&sdata=nA1S7TBfZg6cSwY2hI8hpRXhIA2joaaJFmNXrATgr2Y%3D&reserved=0> >> >> The password grant MUST not be used. >> >> Some background for those interested. I added this grant into OAuth 2.0 >> to allow applications that had been provided password to migrate. Even with >> the caveats in OAuth 2.0, implementors decide they want to prompt the user >> to enter their credentials, the anti-pattern OAuth was created to >> eliminate. >> >> >> Does anyone have concerns with dropping the password grant from the OAuth >> 2.1 document so that developers don't use it? >> >> /Dick >> _______________________________________________ >> 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 >> > -- > ---- > Aaron Parecki > aaronparecki.com > @aaronpk <http://twitter.com/aaronpk> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > -- hans.zandb...@zmartzone.eu ZmartZone IAM - www.zmartzone.eu
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
