I could be wrong, but I fell Txn-Tokens are unnecessary. Maybe I need an additional example use case for it. I feel with the existing token exchange grant you can accomplish what's needed. Why introduce a new type of token? Curious if anyone else has thoughts on this.
I suppose that depends on your use cases and I admit I'm biased as one of the editors of the Transaction Token specification :) Today, what I see mostly in backend infrastructures is the concept of hop-to-hop security. Meaning there is client authentication (e.g. mTLS) between services but the context of the transaction is NOT maintained through all the workloads required to complete the transaction.
The purpose of transaction tokens is to provide that immutable context of the transaction through all the workloads required to complete. Having each workload request it's own new token for the next leg of the journey loses the end-to-end nature of the transaction.
There are some additional benefits like being able to reduce the authorization/scope of the transaction to specifically what that transaction is accomplishing (e.g. add a stock to a watch list where the originating OAuth access_token from the client has a scope of "financial write" which is MUCH broader). I'm happy to discuss that point in more details if people are interested.
I hope this helps and always interested in feedback and use cases!
hey! i know those strongdm peeps! thanks for the shout out!
I could be wrong, but I fell Txn-Tokens are unnecessary. Maybe I need an additional example use case for it. I feel with the existing token exchange grant you can accomplish what's needed. Why introduce a new type of token? Curious if anyone else has thoughts on this.
I suppose that depends on your use cases and I admit I'm biased as one of the editors of the Transaction Token specification :) Today, what I see mostly in backend infrastructures is the concept of hop-to-hop security. Meaning there is client authentication (e.g. mTLS) between services but the context of the transaction is NOT maintained through all the workloads required to complete the transaction.
The purpose of transaction tokens is to provide that immutable context of the transaction through all the workloads required to complete. Having each workload request it's own new token for the next leg of the journey loses the end-to-end nature of the transaction.
There are some additional benefits like being able to reduce the authorization/scope of the transaction to specifically what that transaction is accomplishing (e.g. add a stock to a watch list where the originating OAuth access_token from the client has a scope of "financial write" which is MUCH broader). I'm happy to discuss that point in more details if people are interested.
I hope this helps and always interested in feedback and use cases!