- The policy conditions include both some claim(s) being supplied and, afterward, Bob being able to authenticate, to some level of strength, as Bob. (That is, there is a certain authentication_context and identity required, whether explicitly in an error_details hint, or implicitly. Currently we only have an in-band way to indicate authentication hints, not the required identity.)
Notice that a precondition for the attack is that Eve and Bob each have their own AATs, even though their clients have identical client IDs; this gives a hook for transaction context differentiation. The theory is that, if Eve were to initiate the session, phish Bob to gather his credentials, and then take over again after he's done, Eve would fail the second policy condition because she can't authenticate as Bob -- unless she also stole his credentials, and that's a different attack entirely. And if Bob started the session legitimately, then of course Eve missed her chance to phish him and he can pass the strong-auth trust elevation test himself.
Recall that elevating trust through authentication_context is basically like refreshing/strengthening the AAT. If anyone wants to squeeze identity out of an AAT, it's best to use OIDC vs. plain OAuth for it.
My investigations showed that using an AAT for trust elevation is not unknown -- in fact, it's known to both Gluu and ForgeRock, in cases where you expect the AS to serve as the IdP for the requesting party as well as the resource owner. I suspect there may be privacy considerations to doing this in other topologies that should be carefully examined -- such as, could a requesting party's "AAT identity" compromise him somehow if it is used as part of trust elevation in addition to "claims-based RqP identity" at the AS? I thought this was incontrovertibly true once, but I haven't been able to re-prove it to myself...
That's probably enough/too much food for thought for now, from me. I know others will want to jump into the thread before the meeting with more.