# Notes - George Fletcher Session on Transaction Tokens at IIW 37 - 10-12-2023

- Cross-domain trust is being handled separately, so this is just within a single authorization domain
- Number of OAuth scopes coming from the client are going to be fairly limited, because the consent has to be simple
- That means, the authorization domain representing the microservices is different from the authorization domain of the client (which uses coarse grained scopes)
- Instead of using the external OAuth token, we can create a new token for the microservices authorization domain - the Transaction Token
- () The authorization token can be opaque to the left and a JWT on the right (where the microservices are)
- () Calling the client part an authorization domain is incorrect because the client side is untrusted
- (Justin) With "authlete" you can create a number of services with the same account. The token used to provision services didn't have the rights to use that service, so you needed a new token / escalate the rights of the same token
- () Isn't token exchange the solution to this?
- Adding OAuth tokens internally added a whole lot of complexity
- E.g. token introspection
- () In some cases, you may want to "up scope" the incoming OAuth token, because you don't want untrusted clients some powerful scopes
- A call chain cannot be rolled back once started
- E.g. if the user changes their password within the execution of a call chain, you may end up with a partially executed transaction if you are using OAuth tokens internally
- () "Solving the Transitive Access Problem" paper presented earlier at a conference in Prague
- () This sounds very synchronous. How do we address asynchrocity
- At the edge, issue a different type of token, which is focused on the transaction
- A lot of backends have no idea of the services invoked in the call chain
- The txn-token has:
- iss
- txn
- sub_id
- capabilities / purpose
- azc
- originator
- context
- authorization details
- () Are you also trying to bake into it the call chain part?
- (Justin) Token buckets will address the call chain part. We don't want it to keep getting re-issued at every step of the way
- () Is the word "transaction" misleading? Should it be called a "request token"? - many disagreed with this
- () Isn't this just token exchange? Do we need to call it something?
- () Having standard claims is good,
- (Sarah) If I am a new microservice, how do I know what purpose I'm going to be called for?
- The new service can limit what purposes it can be used for
- This is a complex problem, e.g. what purposes should be supported by a new service?
- () Service meshes have related functionality
- () Why not use a header that says this is a wrapper around the invound token?
- (atul) not all of the context is inside the inbound token
- Replacement tokens
- It creates a lot of complexity for the security model
- It is allowed in the spec today
- () What happens when you have an externalized service that also talks internally?
- The spec doesn't say anything about how the model is defined
- (Alan) I'd like to think of this in terms of attenuated delegation
- () Isn't it easier because this is atomic?
- The trust boundary aspect is important, crossing trust boundaries is a whole another mechanism
- Token exchange is just a mechanism, it could be anything
- To cross authorization domains, you are not talking to the Transaction Token service, you need to talk to the AS.
- (Justin) MITRE has written an extensive paper about crossing domain boundaries
- () We also have third-party services that provide APIs. I wonder if Txn-tokens are useful in that case?
- The expectation is that TraTs are within a domain, and I should never see them outside the domain
- () The time limit is one thing, but the "one-time use" property is also required
- () You don't want transaction tokens to be reissued multiple times
- The simple use case is that once a TraT is created, it's never re-issued
- The content of the TraT is dependent on the actual transaction in question, the spec is not prescriptive about it
- () By value passing you could make the tokens really long
- () Having all the details in the TraT is important
- Any element of what the user / service is trying to do that is immutable can be inserted into the authorization details
- A few years ago, microservices allowed any user to be impersonated
- () This sounds like Twitter's Finatra / Finagle context passing
- () Don't you always need an inbound token?
- No, as long as you can know the service that is invoking the endpoint issuing the Transacction Token