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 <notificati...@github.com> 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 < oauth-transaction-tok...@noreply.github.com> Cc: Atul Tulshibagwale <a...@sgnl.ai>, Comment <comm...@noreply.github.com> @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/2330558...@github.com>
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
