Maciej has prepared a new version of the extension spec, and it's now on GitHub <http://htmlpreview.github.io/?https://github.com/KantaraInitiative/wg-uma/blob/master/draft-uma-claims-sec-ext-v1_0.html>. And thanks to input from Sarah, I've put together a companion non-normative document on the UMA wiki <http://kantarainitiative.org/confluence/display/uma/Understanding+the+Session+Fixation+Attack+on+UMA+Claims-Gathering+and+the+Provided+Mitigation> . In writing the final part of the companion document, I started thinking about a potential new mitigation idea when it came to describing why strong authentication *after* claims-gathering wouldn't work: I suddenly wasn't sure that strong auth doesn't work in all circumstances. *N.B.:* With this inquiry, note that my goal isn't to delay getting the word out about this whole thing! It's simply to consider any mitigation that might be reasonable, and discard it expeditiously if it doesn't fit. So I'm hoping we can examine it in our call and: a) reject it as unsuitable, b) reject it as technically suitable but failing some other criterion, or c) accept it as an alternate or additional mitigation. So here goes. Given the following: - The cycle of trust elevation (need_info) is repeatable, according to AS needs. (Which gives an interestingly flexible mechanism.) - Only trust elevation that uses the requesting party claims endpoint is susceptible to session fixation. ...I started wondering whether it *might* be viable to suggest the following as a mitigation: - 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. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl