azc content recommendations?

[tulshi]

          Are there any recommendations on the type of data to include or not include in `azc`? Or is it up to the individuals to encrypt if there is any sensitive data in it?

_Originally posted by @naveencm4u1 in https://github.com/SGNL-ai/transaction-tokens/pull/29#discussion_r1296765403_

[gffletch]

I think details about the transaction itself (e.g. a RAR structure) could be put in the 'azc' but in their own sub-object. Generally, my thoughts have been the primary contents is the context of the transaction itself. Who requested the token, the purpose of the transaction, maybe other context that should be immutable (e.g. source IP address, device identifier, time of day, type of authorization token [bearer vs sender-constrained], ...)

[tulshi]

I feel some of this information (requester, source IP, device ID) may be more interesting from an offline analysis point of view, rather than the transaction processing point of view. If so, the TraT service should just log this information instead of putting it into the TraT in order to prevent token bloat. If it is needed for transaction processing, it can always be included in the azc field.

[gffletch]

So for me, a minimum set is... Requesting Entity (GW, Application, etc) Purpose of the transaction (to allow for "downscoping") Subject of the transaction (user/machine id)

I do think that preserving other context of the transaction is useful from any risk engine that might be used by a downstream workload. But maybe we can separate that out.

{ 'iss' ... 'azc' 'cxt' / OPTIONAL: context of the transaction / 'azd' / OPTIONAL: Authorization details / }

The 'azd' claim would allow for the additional information like what can be provided in RAR.

The 'cxt' claim would allow for capturing other contextual details of the transaction. As optional, it can be left out to reduce token bloat.

[tulshi]

Sounds reasonable. We have the subject sub_id claim. Should we add a sub-container or just have specific fields for the originator and purpose claims?

[PieterKas]

It would be good to show how, in a replacement txn-token, the identity of the previous sub_id is preserved. The replacement token may have a new sub_id that represent the workload that requested the replacement token.

[tulshi]

Closed in PR #43