Tx token lifetime guidance missing for replacement token

[ashayraut]

There should be guidance for token lifetime of replacement token. A replacement token can have lifetime of whatever is left in the original token that was used to replacement or someone will keep using replacement token feature to keep increasing lifetime of the original incoming token.

[arndt-s]

I believe this is partly covered by Section 2.3 Txn-Token Lifetime

Except in the case where the request is made using a self-signed JWT, if the token or other credential presented to the Txn-Token service when requesting a Txn-Token has an expiration time, then the Txn-Token MUST NOT exceed the lifetime of the originally presented token or credential.

However, I agree that this is very focused on the original token and not in cases where transaction tokens are replaced.

[ashayraut]

Yes, I'd say we must include details about it so that there is some guidance for replacement tokens too. Default suggestion could be to set expiry time on replace token, same as expiryTimeOfOriginalToken. So it also discourages replacing a token multiple times.

other alternatives are to keep a counter on Tx Token Service side (or inside the token itself) where we can keep track on how many times it was replaced and limit on Tx token service side if a certain token is replaced too many times but unfortunately, it will be difficult to gauge value for "replaced too many times".. :-)

[tulshi]

The intent was that the replacement token should expire no later than the expiration of the original TraT, but I don't recollect whether that is in the spec or not.

[obfuscoder]

If there are long running batch processes involved, it may be necessary to extend lifetime of such TraTs (or issue TraTs out of bounds as discussed in other issues). However, the TraT Service should have the authority about what is possible.

[ashayraut]

I didn’t see Tx token lifetime for replacement token in draft. We should add it.

about long running process I have a proposal in other GitHub issue. In general the Trats service can decide to issue tokens with higher lifetime but with Trats tokens it’s a risk to have higher lifetime as they are bearer tokens can be used by anyone. So my proposal addresses that by using another token for it.

[obfuscoder]

I didn't mean that the TTS should issue TraTs with long lifetimes. That would be bad indeed. Instead the TTS should be able to issue new TraTs with short lifetime, but the lifetime can essentially exceed that of the presented one. As I suggested in #62, the presented TxT could even be expired aand the TTS could allow to issue a new TxT to that specific workload as the TTS knows that this workload is a long running batch processor.

[PieterKas]

Note- combine this with any PR on "refresh" tokens when time extension/replacement is needed to keep language consistent.

[ashayraut]

Raised a PR with minor fixes #147