Oh, I see where you are heading. We potentially can cut some bells and whistles out of the current text.
> Am 19.11.2019 um 18:06 schrieb Hans Zandbelt <hans.zandb...@zmartzone.eu>: > > > How about: > > - don't use the Implicit or Resource Owner Password Credentials grant types > - perform exact matching of redirect URIs and make then Client/AS specific > - use PKCE > > Hans. > >> On Tue, Nov 19, 2019 at 5:58 PM Torsten Lodderstedt >> <tors...@lodderstedt.net> wrote: >> >> >> > On 19. Nov 2019, at 17:10, Hans Zandbelt <hans.zandb...@zmartzone.eu> >> > wrote: >> > >> > >> > >> > On Tue, Nov 19, 2019 at 10:38 AM Torsten Lodderstedt >> > <tors...@lodderstedt.net> wrote: >> > Hi Hans, >> > >> > > On 18. Nov 2019, at 04:11, Hans Zandbelt <hans.zandb...@zmartzone.eu> >> > > wrote: >> > > >> > > Hi, >> > > >> > > Please find my feedback from page 21 onwards below. >> > > >> > > Hans. >> > > >> > > Overall I would argue there's room for a very concise guidance section >> > > that says: do this, don't do that, without explanation, just as a >> > > reference for developers; the current text provides in depth analysis >> > > but that is perhaps not suitable for developers who just want to know >> > > what to do (or not to do) and don't really care about the >> > > background/reasoning >> > >> > While section 4 gives the raw security threat analysis, we tried to >> > summarise the actionable guidance in section 3. What do you miss there? >> > >> > I'd rather see it even shorter and more concise, but I guess you're right, >> > it is there >> >> Do you want to suggest some text? >> >> > >> > > >> > > P21 >> > > first bullet >> > > "the client has bound this data to this particular instance." -> >> > > particular instance of what? >> > >> > This bullet refers to the note above. >> > >> > "Note: this check could also detect attempts to inject a code which >> > had been obtained from another instance of the same client on another >> > device, if certain conditions are fulfilled:" >> > >> > ok, I see >> > >> > > >> > > 3rd paragraph: >> > > "call to the tokens endpoint." -> "call to the token endpoint." >> > >> > Fixed >> > >> > > >> > > last paragraph could forward point to the next section by adding >> > > something like >> > > "using one of the mechanisms described in the next section." >> > >> > Incorporated >> > >> > > >> > > P22 >> > > 3rd paragraph: >> > > is the token binding guidance still accurate? it seems to be >> > > overestimating the adoption >> > >> > You mean this statement? >> > >> > "Token binding is >> > promising as a secure and convenient mechanism (due to its browser >> > integration). As a challenge, it requires broad browser support >> > and use with native apps is still under discussion.” >> > >> > yeah, but after re-reading I guess this actually spells out the adoption >> > conditions, so it is fine >> > >> > Hans. >> > >> > >> > Thanks, >> > Torsten. >> > >> > > >> > > -- >> > > hans.zandb...@zmartzone.eu >> > > ZmartZone IAM - www.zmartzone.eu >> > > _______________________________________________ >> > > OAuth mailing list >> > > OAuth@ietf.org >> > > https://www.ietf.org/mailman/listinfo/oauth >> > >> > >> > >> > -- >> > hans.zandb...@zmartzone.eu >> > ZmartZone IAM - www.zmartzone.eu >> > > > -- > hans.zandb...@zmartzone.eu > ZmartZone IAM - www.zmartzone.eu
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
