# Meeting Notes 2023-09-29
## Agenda
* Transaction Tokens issues review
* WIMSE charter
* Multi-token container
* Identity Chaining
* Transaction Tokens adoption timeline
## Attendees
* Atul Tulshibagwale (SGNL)
* Pieter Kasselman (Microsoft)
* Justin Richer (Bespoke)
* George Fletcher (Capital One)
* Kelley Burgin (MITRE)
* Hannes Tschofenig (GMX)
## txn claim clarification
* Clarify in draft
* Use the existing claim named `txn` from SETs
## [azc content recommendations](https://github.com/SGNL-ai/transaction-tokens/issues/30)
* Using sub_id is fine
* (Atul) Should we have two claims within `azc` to designate originator and purpose?
* (George) You could define policy based on just originator / requesting entity and purpose. These attributes are useful in determining policy. The purpose gives the ability to downscope a token.
* (George) Other context e.g. originator IP, device ID, can be separate. We could use `azd` like in RAR
* (George) I'd prefer these to be outside `azc`
* (Pieter and Atul) These are useful (originator and purpose)
* (Pieter) Unsure about the pro's and con's of putting it inside or outside the `azc` container
* (George) Some context gets stripped off at the edge, and it is hard to establish it in downstream services.
* (George) We can use the `act` claim from Token Exchange for originator (actor)
* (George) I like Atul's point of not having a name for purpose that can be confused with OAuth scope
* (Atul) Let's come up with a name and review it in the PR
## [Short lived tokens](https://github.com/SGNL-ai/transaction-tokens/issues/6)
* (George) What do you do when the Transaction Token is about a user who is trying to delete their data. You can't mint a new token in that case after the user. So there may be edge cases, but we can assume the transaction tokens are short lived.
* (George) This could also be solved by replacement tokens or even nesting
* (Pieter) I was thinking of long lived tokens from the revocation perspective.
* (George) If you need to stop a transaction in flight, then we get into non-atomic transaction considerations. We need a mechanism where the danger of replay is minimal.
* (Pieter) You have to treat this differently, because it is meant to be transient. I agree with the observation that once you have started the transaction, you...
* (George) I've seen systems fail because of transactions that last too long
* (George) If we need to do something it longer lasting, we need a different construct. That could build on transaction tokens, but it will need additional rigor
* (Hannes) Can we reuse some text from TLS? They had to address something similar in 1.3.
* (Pieter) Perhaps the guidance should be to keep the transaction tokens to be valid, but it should be long enough to complete the entire transaction, taking into account how long a transaction may last in your system.
* (Justin) "Short" is always contextual and relative.
* (Pieter) Giving this guidance in the draft is still helpful
## WIMSE Charter
* (Justin) The deadline is today for comments on the WG forming BoF
* (Justin) Deadline is 8PM ET today (~midnight GMT)
* (Justin) WIMSE BoF has been approved!! So is SPICE
## Multi-Token Container
* (Justin) Orie pointed at some related work that could be useful to the Multi-token Container work
* (Justin) Orie is also trying to get another WG called "SPICE" started. Although it is a separate BoF, it could have some coordination with WIMSE
## Identity Chaining
* (Pieter) There are a couple of PRs that need review
## Transaction Tokens Adoption Timeline
* (Justin) Transaction Tokens are perhaps better aligned with WIMSE, so there might be some post-shuffling
* (Hannes) In OAuth we need to update the charter and figure out where all this ends up.
* (Atul) Are there any charter proposals?
* (Hannes) We will conclude the dicsussion in Prague IETF. Because we have these BoF proposals, specifically the SPICE BoF wants to move some of these items.
* (Justin) There are other areas of reshuffling, e.g. HTTP is moving to a new WG.
* (Justin) The important thing is that the drafts move forward and the right people are involved.
* (Justin) Right now, WIMSE might end up in the Apps area and not the Security area.
* (Hannes) OAuth started in the Apps area as well
* (Atul) Can we try to get adoption for Transaction Tokens over email before Prague or at least in Prague.
* (Hannes) We can argue whether this fits in WIMSE later
* (Pieter) What is driving the urgency
* (Hannes) If it turns out it is not that urgent, (earlier there was a greater sense of urgency) then we can wait
* (Atul) There is implementation interest, which should rather the based on a WG draft