Hi all, I took an action item last week to summarize issue 239 in a human readable format. I've included it below. It sounds like there is also a need for a general analysis of the proposed solution and why we chose it. I can write that up too. For now, here's a very high-level description of what's going on: Alice wants to share a photo with Bob, and only Bob. Eve would like to see the photo, but she is not allowed. Alice stores the photo on her resource server and protects it with her authorization server. She sets a policy stating that only Bob should have access to the photo. In order to get Bob access to the photo, three steps are completed: 1. Bob begins his transaction by requesting the photo 2. Bob identifies himself within the context of his transaction 3. The authorization server grants access to the photo within the context of his transaction Eve would like to access the photo as well. She completes the following steps: 1. Eve begins the transaction by requesting the photo 2. Rather than identifying herself, Eve phishes Bob and convinces him to identify himself within the context of her transaction 3. The authorization server grants access to the photo within the context of her transaction Because Eve’s attack involves a successful phishing event, this scenario is not considered a vulnerability in the classic sense. The attacker must know the victim and successfully trick him. As such, the UMA working group is proposing that no normative changes be made to the core specification at this time. We propose a security enhancement extension to be used optionally in contexts where a higher level of security is appropriate. The extension we propose would disallow access to Eve by making each step in the process a different transaction so that when Bob identifies himself, it then becomes his transaction and Eve has no way to recover the context in which access was granted. We feel that this is an elegant solution that is easy to implement and in fact makes the software Bob has to use (also known as the Client) simpler than it would otherwise be since it no longer has to remember the transaction context from beginning to end. Sarah Squire Engage Identity http://engageidentity.com