(There are a lot of sources on the 'net discussing "threat vs. vulnerability vs. risk"; here's one. 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, 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...)