# 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