revoke token does not revoke the tokens created by the original

[Adam Young]

 We don't keep track of what token was used to create a token.
So If we revoke a specific token, and that token was used to create another token, the "downstream" token does not get revoked.

[Dolph Mathews (dolph)]

This also affects trusts; "in addition to revoking all tokens" you need "to revoke all tokens created by trusts of that trustor" -ayoung

[Dolph Mathews (dolph)]

Related to bug 1097995 -- deleting a domain should cascade to delete that domain's users, as well as revoking tokens created by trusts where the trustor is in the deleted domain (sorry that's so confusing!).

[Thierry Carrez (ttx)]

I'm not sure that's a vulnerability to be honest. I'm fine with fixing it -- just not convinced the current behavior should be seen as a vulnerability (in the same way as bug 1097995 is not seen as one).

You can still revoke those tokens manually, I suspect ? I guess that's a question of natural expectations. Is the revocation operation seen as atomic (revoke token), or functional (revoke this token and everything related to it) ? Unless we clearly advertised that the "revoke token" operation also revokes tokens created by this token, I think this is not vulnerability territory.

[Adam Young (ayoung)]

Then lets do this as "feature request" I'll open it as a separate bug if all approve.

[Russell Bryant (russellb)]

Yeah, this doesn't seem like a vulnerability to me.

[Thierry Carrez (ttx)]

Opened

[Adam Young (ayoung)]

The work for this is well underway with the revocation events.

[Juan Antonio Osorio Robles (juan-osorio-robles)]

OK, thanks for the heads up. I was already looking into it.

[Morgan Fainberg (mdrnstm)]

Unassigning due to inactivity.

[Steve Martinelli (stevemar)]

this is covered by revocation events and audit ids that have been around for a few releases