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. 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? 3rd paragraph: why not a MUST for invalidating state (and randomizing it for that matter) but only a SHOULD? 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? 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. 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. -- hans.zandb...@zmartzone.eu ZmartZone IAM - www.zmartzone.eu
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
