As I look at it more and more, it started to look like the problem of accepting tainted values without message authentication. To fix the root cause, we would have to authenticate response. ID Token was designed to also serve as a solution anticipating it.
Any concrete ideas? On Sat, Apr 23, 2016 at 04:47 Torsten Lodderstedt <[email protected]> wrote: > Hi all, > > discussion about Mix-Up and CnP seems to have stopped after the session > in BA - at least in the OAuth WG. There is a discussion about > mitigations in OpenId Connect going on at the OpenId Connect mailing list. > > I'm very much interested to find a solution within the OAuth realm as > I'm not interested to either implement two solutions (for OpenId Connect > and OAuth) or adopt a OpenId-specific solution to OAuth (use id! tokens > in the front channel). I therefore would like to see progress and > propose to continue the discussion regarding mitigations for both threats. > > https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigation-00 > proposes reasonable mitigations for both attacks. There are alternatives > as well: > - mix up: > -- AS specific redirect uris > -- Meta data/turi > (https://tools.ietf.org/html/draft-sakimura-oauth-meta-07#section-5) > - CnP: > -- use of the nonce parameter (as a distinct mitigation beside state for > counter XSRF) > > Anyone having an opinion? > > best regards, > Torsten. > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
