Meeting on 12-01-2023

# Meeting on 12-01-2023 ## Attendees - Rifaat Shekh-Yusef (EY) - Arndt Schwenkschuster (Microsoft) - George Fletcher (Capital One) - Dr Kelley Burgin (MITRE) - Atul Tulshibagwale (SGNL) - Ken McCracken (Google) - Justin Richer (Bespoke) ## Issue Tracking - Each doc does it differently - Arndt to add the Transaction Tokens and Identity Chaining docs to OAuth GitHub - Various issues around transferring repos - (George) we should talk to Mark Haine of the OpenID Foundation because he has a lot of experience in doing this - (Atul) Should we invite Brian Campbell to this meeting to hear his feedback? - Pieter to reach out to Brian about joining this meeting or other logistics - done ## Wimse Interim Meeting - (Justin) Both Transaction Tokens and Identity Chaining were discussed - (Pieter) Lots of traffic on the Wimse list - (Justin) Strongly recommend everyone to subscribe / read the emails on that list and participate - (Justin) Yaron, Pieter and I are starting to finalize a list of deliverable docs - (Justin) Over time, Transaction Tokens and Identity Chaining could be moved to Wimse - (Justin) If Wimse had existed earlier, it would have made sense for TraTs to be adopted there - (Justin) Any help on deliverables and documents section is appreciated so that we can get an official approval from IESG - (Arndt) I'd recommend the first charter to be the bare minimum because there's a lot of enthusiasm in different directions - (Justin) There are some clearly defined wins in the charter, and we should try to keep the list of deliverables close to that - (Justin) BoF feedback was that the deliverables list was too wide - (Pieter) Agree. There's a variety of solutions that people have implemented, so creating an architecture may be hard to agree on. So the near term wins should be clearly defined - (Pieter) We should review the [Zscaler proposal](https://mailarchive.ietf.org/arch/msg/wimse/w_hnUv42NXDPFdnnWM-U2EmbcW4/) about identity chaining. It has a slightly different way of solving it, using something known as DOMs. - (Arndt) All three major cloud providers have metadata and they get access tokens. All those interfaces look similar but are different. Developers would benefit a lot if all these can be aligned for the basic use cases. Workloads can then have just one API to talk to - [AWS](http://169.254.169.254/identity-credentials/ec2/security-credentials/ec2-instance) - [Azure](http://169.254.169.254/identity/oauth2/token) - [GCP](http://169.254.169.254/computeMetadata/v1/instance/service-accounts/{}/token) - (Pieter / Rifaat) The WG needs to discuss where the work gets done ## Call Chain Information - (Atul) Can we use replacement transaction tokens to incorporate call chain information - (George) I'd rather use Justin's token bucket idea for call chain information - (George) If the Transaction Token service can add the requesting workload into the "requesting workload" field, so the token doesn't change, it can just include call chain information that way - (Atul) That's what I was outlining - (Pieter) What would we add / change - (Ken) This seems like a gap. I recommend using the "act" claim it could be included as a "MAY", but it could be useful to validating upstream workloads - (George) That means we need to pull the requesting workload out of the "requesting workload" field and have a "requesting path" - (George) The replacement token is scary because it can change everything about the token. We need to be a lot more prescriptive about what can and cannot be done while issuing replacement tokens - (Arndt) Would we allow any client to get replacement tokens? Or should there be policy? - (George / Pieter) There should be policy in the Transaction Token server. It is at the discretion of the server - (Atul) We should include something in the Security Considerations to state that there should be some policy - (George) You want to know whether this service is authorized to obtain a transaction token for this purpose - (George) If in a replacement Txn-token, you can change the purpose, then you need to have an authorization policy at that level as well - (George) It could be a part of the normative text that the Transaction Token server SHOULD consult policy regarding who can issue / replace transaction tokens, and then expand on that in the security considerations section - (Justin) Security Considerations sections should not have any normative text - (Arndt) If I'm a workload, and I receive a Txn-token, but how do I validate it. If I have a huge trust domain, and multiple gateways and I want to trust only one gateway - (George) There is the possibility of allowing local workloads to run policy on a Txn-tokens. It's not that the Txn-token requires a receiving service to act, it just provides the information and the service can make a decision whether or not to respect it. - (George) Over time, there will be some policy there too, but even if we deploy Txn-tokens now without local workload policy, it will be vastly better than what we have today - (George) I'd love to get some implementations and experiment with local workload policy and path chaining and fine-grained policy around purpose and intent - (Rifaat) It's important that we start getting into implementations. If you want this to be published as an RFC, we need some implementations - (Arndt) If any client can issue Txn-tokens, then it becomes meaningless. - (George) Only a few services such as external API gateways should be permitted to request Txn-tokens. The Txn-token server can restrict the purpose of the issued tokens based on the identity of the requesitng service (e.g. an email server can only request tokens with specific purposes) - (Pieter) I heard Arndt's question a bit differently: I thought you were also suggesting that which Txn-tokens are accepted by which workloads - (Arndt) It's either that the workloads only accept a subset of Txn-tokens or you restrict who can request Txn-tokens. - (Pieter) You probably need both. This is a policy thing, you check in the local service whether the requester is one you trust for the purpose - (Rifaat) Agree with Pieter - (Atul) Having policy at each local workload makes management complicated - (Pieter) It should be a deployment choice, the mechanism should support it, but how to implement the policy is a deployement choice - (George) Agree. How someone wants to manage / define policy is out of scope for us, but we should allow all possibilities. I believe we can improve overall security by just having this immutable context. That in itself will elevate the security of a lot of environments - (Atul) Once the draft is transferred, I'll add issues and open a PR ### Process Update - (Justin) Now that this is a working group document, none of this discussion matters, it needs to get involvement from the WG - (George) Create the issue and send it to the OAuth mailing list, in order to get the wider opinions - (Justin) In my experience, we should not wait for people to comment, put the change in a PR, and solicit comments on that. Even when a adopted draft is updated, people can comment on that too - (Atul) Since the drafts are now WG drafts, should we involve everyone in the call? - (Rifaat / Justin) Not necessary to involve everyone in the calls, but we can use the mailing list to get comments. We should not look for feedback on this call, but actually from the mailing list - (Pieter) I'd like to keep these calls, it's a good place to discuss things, but we should always discuss any decision with the OAuth list - (Pieter) I like Justin's idea that we should call out that if we are discussing anything controversial, to put it on the agenda for the next OAuth Office Hours