# Meeting 07-07-2023

## Attendees

## Agenda
* [Workload identities in leaf transaction tokens](https://github.com/SGNL-ai/transaction-tokens/issues/12)
* George - need a way for intermediary servers to add extra authoritative information.
* Justin's solution may help with this.
* Justin - can we get away from putting everything in a single token.
* Justin - we may have a type of graph instead.
* Justin - we have a dictionary instead of a monolithic token.
* Atul - this allows a token to send multiple tokens and then reference them. Can this work with JWT embedded tokens?
* Justin - nothing is specific to JWT.
* Atul - have a draft that can be referenced by embedded JWT spec.
* Justin - its a seperable concern
* George - for nested tokens, would like some real world solutions
* George - can we use secure forward header (include hashes of previous tokens).
* Justin - need a mechanism to add things in the middle.
* Pieter - does not need to be tokens, can be other information? Correct.
* Pieter - Can you establish a Merkel chain?
* Justin - I don't think there's a single order chain. There will be things that care about all the previous intermediaries, but others that will be selective
* George - In a call chain, you would need an order of events.
* Justin - You can enforce order if you wanted to
* Atul - Do all services need to sign in what George is proposing?
* George - Most won't.
* George - There may be a few cases where we may require the entire call chain to be secure, but in that case, the individual services will know they need to do that
* Hannes - What kind of call-chain conversation do we want to standardise?
* George - sometimes you need to know which servers were previously involved (like a log file). Ties back to specific AuthZ policies that need this level of information.
* Rifaat - STIR has use cases like this (JWT embedded tokens helps with this)
* Atul - Want to know if the same transaction was processed by another service.
* Mike - Thinks a little different about a transation. Need to knwo the flow of information
* Pieter - Does the ordering also matters - Mike to confirm. definately cares about the endpoints.
* Rifaat - Why do you need the order? Mike to confirm.
* Atul - May care about the ordering in some cases needs to be estabished.
* Atul - the Draft does give you the order.
* George - sometimes you get a transaction token, sometimes a nested token. May prefer option 4 - always get a fresh transaction token. Gives consistency - always a transaction token. Structural processing is the same. Always get a fresh transaction token instead of mixing it.
* Atul - if we keep it, we should specify it more completely.
* George - we need more use cases - perhaps remove the nested model?
* Hannes - can we change the name of the token - if it is only about keeping call-chain information, perhaps calling it a signed log? AuthZ implementors may get confused by tokens and make bad decisions.
* Justin - Security event working group - introduced as "JSON Web Logs" initially, eventually became "Security Event Token" (SET)
* Atul - conclusion: work on more details for the Workload 4 flow. Need more discussion on Workflow 3.
* Atul will submit doc so we have a discussion at IETF 117 in July.
* [Security considerations of leaf versus nested transaction tokens](https://github.com/SGNL-ai/transaction-tokens/issues/11)
* [Is the Transaction Token Service just another endpoint?](https://github.com/SGNL-ai/transaction-tokens/issues/10)
* [Standardizing machine identity terminology](https://github.com/SGNL-ai/transaction-tokens/issues/8)
* [Naming: tx-token => txn-token](https://github.com/SGNL-ai/transaction-tokens/issues/7)
* [Transaction Token lifetime](https://github.com/SGNL-ai/transaction-tokens/issues/6)
* [Transcribing claims](https://github.com/SGNL-ai/transaction-tokens/issues/4)
* [Mutual authN of Transaction Token requests](https://github.com/SGNL-ai/transaction-tokens/issues/3)
* "tid" and "azc" claim definition (IANA registration?)
* Explaining the self-signed nested transaction tokens part more clearly
* Token Data Structures (Justin)

## <item 1>