Nat,
Cheers ! The use case of buying Vodka is a nice illustration. :-)
Torsten,
I think what Denis is referring to is the case where two bad actors,
Alice and Bob collude and take advantage of the "bearer token".
By doing so, instead of Bob buying Vodka for Alice, Alice can order
Vodka disgu
Torsten,
I think what Denis is referring to is the case where two bad actors, Alice
and Bob collude and take advantage of the "bearer token".
By doing so, instead of Bob buying Vodka for Alice, Alice can order Vodka
disguised as Bob. So, the increased risk here is that Alice does not have
to bothe
Nat and Torsten,
My responses ares embedded in your text.
I agree, we should analyse the threat. From my first impression it
feels like injection with some specialties.
Not exactly. In most scenario attacks, we have two good guys (Alice and
Bob) and one bad guy (Carol) acting as the single a
I agree, we should analyse the threat. From my first impression it feels
like injection with some specialties.
@Denis:
So far, I'm struggeling to understand how this attack is performed from
a practical perspective. Every token/assertion issued to the uncle is
bound to its identity. So it the
Thanks Denis for pointing it out. It may be desirable to add ABC attack to
the list of threats. Torsten et al. are updating Threat Model and Security
Considerations so it could potentially be included in there.
Some remarks:
- I suppose the assumption is that the Bob does not share his
cred
Section 5 of "draft-ietf-oauth-pop-architecture-08.txt" identifies
requirements.
One of them (which, BTW, should be moved into Section 4 - Threats) is :
Collusion:
Resource servers that collude ...
This threat addresses the case of "/collusion between servers"/ while
the case of "/collusion b
