Batch or long running processes and extending lifetime of a token

[ashayraut]

If we provide refresh token which is signed and contains the original token inside it, then refresh token when passed to Tx token service, then Tx token service can verify if 1) refresh token is signed with its private key, 2) the token inside will be expired but it can still read the token and verify caller's identity is associated with all the claims or not, if yes, then it can get new Tx token with same claims or it can get new token but claims that are associated to them and not the exact claims present in the token inside refresh token. Why not request new token always when batch process or workflow resumes from long pause? Because sometimes the service might just want to use the claims of its caller (as long as its permitted to do so) rather than new token.

For example, if an internal service C is called by A and B, and C is allowed to make requests to D for tax or accounting purpose. A->C B->C C->D A is allowed to make request and request Tx token for tax purpose. B is allowed to make request and request Tx token for accounting purpose. C is allowed for both accounting and tax purpose because is a common service

Now, C simply wants to use usage claim based on who called - A or B. C can do so by passing token generated for A or B to D. But if C is a workflow that pauses for more than TTL of Tx token, then token expires and it loses all the context about claims associated with A and B. In such case, before going on long pause, C can request refresh token from Tx Token service by passing original valid token it receives. It requests this token before going into long pause. It receives refresh token which it will use when it resumes. Refresh token will have longer TTL. Tx Token can configure TTL per use case and/or per caller (e.g. C). Tx token service will include claims in the input valid token in the refresh token but the refresh token cannot be used to access data from any service. Services should ignore refresh tokens in case someone (C) tries to use it directly. C has to make an exchange and pass refresh token to TxToken issuer service to get new token to pass to D.

[tulshi]

Interesting proposition.

[ashayraut]

Thanks. I think we can generalize it a bit and share some guidance for batch proposes. Important thing is to think through all security threats.

[gffletch]

Just to make sure I understand... the "refresh token" (I'm going to call it the "batch token") is ONLY valid at the Transaction Token Service (potentially encrypted such that ONLY the Transaction Token Service can decrypt it). The "batch token" contains the context from the A/B transaction token with the longer TTL. I think this "batch token" should also be sender constrained in some way. Is this along the lines you were thinking?

[tulshi]

@ashayraut Please post the description of this issue on the IETF OAuth mailing list, and point people to this issue to add their comments here. This together with Issue #110 should be addressed in a single pull request.

[ashayraut]

This is taken care of. I have emailed with the subject "[OAUTH-WG] Proposal for Tx token batching processing on draft-ietf-oauth-transaction-tokens-03".

On Wed, Jul 24, 2024 at 2:50 PM Atul Tulshibagwale @.***> wrote:

@ashayraut https://github.com/ashayraut Please post the description of this issue on the IETF OAuth mailing list, and point people to this issue to add their comments here. This together with Issue #110 https://github.com/oauth-wg/oauth-transaction-tokens/issues/110 should be addressed in a single pull request.

— Reply to this email directly, view it on GitHub https://github.com/oauth-wg/oauth-transaction-tokens/issues/111#issuecomment-2248958420, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABHO2XZDBROMGLSCCA6I3C3ZOAORZAVCNFSM6AAAAABK2AEJHSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENBYHE2TQNBSGA . You are receiving this because you were mentioned.Message ID: @.***>

-- Regards, Ashay Raut

[ashayraut]

@gffletch You comment - "batch token is ONLY valid at the Transaction Token Service (potentially encrypted such that ONLY the Transaction Token Service can decrypt it)"

Ashay: Yes, you are right. Its' valid only in Tx token service. We can encrypt it or but won't signature just suffice?

@gffletch About your comment - "I think this 'batch token' should also be sender constrained in some way."

Ashay: The way we implemented this is by creating a unique use case id or you call it namespace. So, the problem is -> A requests a batch token which it can pass to B but B would need some permissions to get Tx token back from A's batch token. To solve it, when A onboards Tx Token issuer, it creates a use case id unique to A which is registered with Tx token issuer. Every time Tx Token issuer issues a 'batch token' to A, it will find the usecaseId and put it in batch token. If B gets batch token from A (or steals it somehow), then B will not be able to get a Tx token back from issuer. Tx token issuer maintains an allowlist against each unique usecaseId, for who is allowed to get token back for that use case it. To get token back, B has to register itself to Tx token issuer against A's usecaseId.

We call services like A, the "batch token initiator" and services like B "the batch rehydrator" as it rehydates Tx token back from batch token.

Edge case - A can play both roles - initiator and rehydrator. This might lead to problem of infinite exchanges. But not sure if its a problem. It may be a problem for some use case. Tx token can also keep a counter in batch token and Tx token to ensure only finite amount of exchanges are allowed.

Overall, how does the proposal sound? I think we cannot write all this into a complexity into RFC. For RFC, we can keep it simple that there can be long lived batch token and Tx token must implement some sort of access control to ensure only authorized services can convert the batch to Tx token.

Supporting batch has been super important for my company and major milestone as many critical workflows are model on such event based architecture.

If everything looks good, I can create PR for it and take a stab at updating our draft.