[OAUTH-WG] Fwd: [oauth-wg/oauth-transaction-tokens] Batch or long running processes and extending lifetime of a token (Issue #111)

[Atul Tulshibagwale <[e-mail]>]

Since this discussion might create a whole new feature in the TraTs
service, I wanted to share this with the list. The issue discusses how one
can create short-lived TraTs for long-lasting batch processes.

---------- Forwarded message ---------
From: ashayraut <[e-mail]>
Date: Wed, Sep 4, 2024 at 9:11 PM
Subject: Re: [oauth-wg/oauth-transaction-tokens] Batch or long running
processes and extending lifetime of a token (Issue #111)
To: oauth-wg/oauth-transaction-tokens <
[e-mail]>
Cc: Atul Tulshibagwale <[e-mail]>, Comment <[e-mail]>


@gffletch <https://github.com/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 <https://github.com/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.

—
Reply to this email directly, view it on GitHub
<https://github.com/oauth-wg/oauth-transaction-tokens/issues/111#issuecomment-2330558630>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB55UG4OLSDISRJABCHOPHDZU7KXNAVCNFSM6AAAAABK2AEJHSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMZQGU2TQNRTGA>
.
You are receiving this because you commented.Message ID:
<oauth-wg/oauth-transaction-tokens/issues/111/[e-mail]>