Hi Hans, > On 11. Nov 2019, at 17:57, Hans Zandbelt <hans.zandb...@zmartzone.eu> wrote: > > Hi, > > Please find my feedback on page 11-20 below. > > Hans. > > P14 > 4.2.4 For an RP there should be more explicit text and guidance about having > a single dedicated immutatable redirect URI per client that "demultiplexes" > access to the protected resource by storing the original location that the > user agent was trying to access in the state associated with the > authorization request. >
Anything different from the guidance given in 3.1? > P15 > same section 4.2.4, 2nd paragraph: if I'm correct the text about > authorization codes being single use only and revoke access tokens on 2nd use > is not different from the original RFC is it? If so, why repeat here? To provide a complete list of measures and to remind the reader of what is already stated in RFC 6749. The alternative would be to state something like, "beyond the measures given in RFC 6749, the following additional measures further reduce the chances of a successful attack:" > > 3rd paragraph: why not a MUST for invalidating state (and randomizing it for > that matter) but only a SHOULD? Because this is a discussion of options not the normative recommendation. Beside this, invalidating state introduces more state at the client, which might cause scalability problems. > > P16 > 4.3.2 the "postmessage communication" is mentioned here without any context > or explanation; I guess this refers to the OIDC session management spec > somehow? It refers to a (non-existing) postMessage-based protocol to pass the code to the RP. We adopted the second measure with our recommendation towards code&PKCE. > > 4..4 Mixup: I would like to emphasize here that the mixup attack works > perfectly fine against two statically configured OPs, to avoid the impression > that it is somehow applicable in dynamic scenarios only. Changed it "Mix-up is an attack on scenarios where an OAuth client interacts with multiple authorization servers, as is usually the case when dynamic registration is used or if the client is statically configured to interact with multiple authorization servers." > > P17 > About the description of the mixup attack: as long as the attacker is able to > trigger a request (by having the user click a link) and read the query/POST > parameters on the A-AS (perhaps from the logs) he can execute a mixup attack > by starting from the A-AS rather than the H-AS (as demonstrated in the OAuth > 2.0 security workshop in Darmstadt December 2016). Perhaps this can be made > more explicit. I will ask Daniel to take a look into this. best, Torsten. > > -- > hans.zandb...@zmartzone.eu > ZmartZone IAM - www.zmartzone.eu > _______________________________________________ > 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
