In case the technical particulars of issue #239 might have made some folks' eyes glaze over, I wanted to paraphrase it in a couple of different ways to help us all analyze it. The ad hoc meeting this morning was very useful to dig into more details (and I'm sure there's more to come), but at this point we've been focusing most heavily on the tech side. We started thinking in terms of "risk" towards the end of the call, a more subjective and squishy task when we're talking about protocols. (There are a lot of sources on the 'net discussing "threat vs. vulnerability vs. risk"; here's one http://simplicable.com/new/security-risk-vs-vulnerability-vs-threat. The idea is that risk has to capture the business upside of doing X with good guys involved, along with the business downside of doing X with bad guys in the mix.) The attack in issue #239 https://github.com/KantaraInitiative/wg-uma/issues/239, put in more business-y terms, could be stated this way (Justin et al., please adjust if I've misrepresented too much): Alice has a resource R she wants to share with Bob, and she uses an UMA authorization server and resource server to do so. Before Bob gets as far as actually attempting access to that resource using his legitimate UMA client app C, attacker Eve starts the "UMA dance" using an UMA "attacker client" app AC that has the same identifier as Bob's app. Eve's app manages to "phish" Bob into providing the necessary claims to Alice's AS for some other apparent purpose (not for getting Alice's resource R), and the rest of the UMA flow unfolds in a way that lets Eve get resource R instead of Bob. In legal-y (model text-y) terms, we could observe that: - Alice the RO (Authorizing Party or AuthzP), the resource server operator (RSO), the authorization server operator (ASO), and possibly the Client Operator??, are all let down because resource R is ultimately exposed to Eve (the attacker) and not the intended RqP, Bob. This is really bad. - Also, the ASO has been tricked into collecting claims outside of the intended purpose of authorizing access to the AuthzP's resources. I think we have a model clause about how the ASO needs to be restrained about why to collect claims. - However, Bob (RqP) has exposed his claims to an ASO that he does have an authorization API token (AAT) with, and that ASO normally would hang onto his tokens for legitimate access to various resources. Not sure if that makes this a "breach" of his claims or not. - (There's maybe some other observations we could make here...) All in all, it's a great use case for the model text work. *Eve Maler*Cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl