Hi Joseph, > Am 09.11.2018 um 18:27 schrieb Joseph Heenan <jos...@authlete.com>: > > Hi Torsten, > > A few comments having just read this afresh: > > 2.1: 'Clients SHALL avoid’ - is that normatively different to ’SHOULD’ given > it appears to be permitted?
SHALL is equivalent to MUST, changed it into SHOULD for the reason you gave. I also changed other occurrences of SHALL to MUST as it seems people are more familiar with this term. > > I find it a little hard to understand exactly what "avoid any redirects or > forwards which can be parameterized by URI query parameters” means > (particularly as it comes directly after a paragraph on the redirect_uri and > I initially thought it was talking about that. Perhaps something along the > lines of “avoid forwarding the user’s browser to a value from a uri query > parameter” might be clearer. Incorporated your text. > > " Clients SHALL ensure to only process “ could just be written ‘Client SHALL > only process” I think. That’s indeed simpler :-) > > > 2.1.1: > > "Authorization servers SHALL consider the” - is ’SHALL consider’ different > to ’SHOULD’? Or does it mean something like “SHALL implement at least one > countermeasure from <…>”. That wouldn't work since the text in RFC6819 gives implementors multiple mostly complementary measures. But the direction of your proposal makes sense, so I added the requirement for the AS to bind every code to a client (already stated in RFC6749) and to authenticate the client. Thanks to Dynamic Registration and PKCE this is now feasible and it seems to be the most effective mitigation to me. I also made the reference to RFC 6819 a SHOULD. > > 3.2.4: > > This says "Authorization codes SHOULD be invalidated by the AS after their > first use at the token endpoint”. > > https://tools.ietf.org/html/rfc6749#section-10.5 says: > > "Authorization codes MUST be short lived and single-use.”. > Thanks for pointing this out! > Does this "MUST be single-use” not effectively already require the code is > invalidated after first use? If so why downgrade this to a “SHOULD”? You are right. My feeling is single use can turn out to be a really hard to implement requirement. That’s why I would like to relax it. Given we now have a stronger requirement on client authentication that should be fine. Question to the list: what is your implementation experience regarding one time use authorization codes? Thanks for your feedback! kind regards, Torsten. > > > Cheers, > > Joseph > > >> On 9 Nov 2018, at 09:42, Torsten Lodderstedt <tors...@lodderstedt.net> wrote: >> >> Hi all, >> >> the new revision incorporates the recommendation to use more secure grant >> types instead of implicit we agreed to add during the WG session on Monday. >> It also has more text around justifications for our recommendation. >> Especially, there is a new section 3.6 on access token injection. >> >> I also posted about this topic on LinkedIn >> (https://www.linkedin.com/pulse/why-you-should-stop-using-oauth-implicit-grant-torsten-lodderstedt/) >> and Medium >> (https://medium.com/@torsten_lodderstedt/why-you-should-stop-using-the-oauth-implicit-grant-2436ced1c926) >> >> kind regards, >> Torsten. >> >>> Am 09.11.2018 um 09:32 schrieb internet-dra...@ietf.org: >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Web Authorization Protocol WG of the IETF. >>> >>> Title : OAuth 2.0 Security Best Current Practice >>> Authors : Torsten Lodderstedt >>> John Bradley >>> Andrey Labunets >>> Daniel Fett >>> Filename : draft-ietf-oauth-security-topics-09.txt >>> Pages : 35 >>> Date : 2018-11-09 >>> >>> Abstract: >>> This document describes best current security practice for OAuth 2.0. >>> It updates and extends the OAuth 2.0 Security Threat Model to >>> incorporate practical experiences gathered since OAuth 2.0 was >>> published and covers new threats relevant due to the broader >>> application of OAuth 2.0. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ >>> >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09 >>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-09 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-security-topics-09 >>> >>> >>> Please note that it may take a couple of minutes from the time of submission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> 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 >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
