Meeting on 02-02-24

# Meeting on 02-02-24 ## Attendees * Aaron Parecki (Okta) * Mike Jenkins (NSA) * Atul Tulshibagwale (SGNL) * Kelley Burgin (MITRE) * Brian Campbell (Ping) * Pieter Kasselman (Microsoft) * Ken McCracken (Google) * George Fletcher (Capital One) * Joe Jublinski (MITRE) ## Agenda * TraT issues * Identity Chaining ## TraT Issues * Is the `aud` field always required ([Issue #63](https://github.com/oauth-wg/oauth-transaction-tokens/issues/63)) * Should `subject_token` be required in a TraT request? ([Issue #53](https://github.com/oauth-wg/oauth-transaction-tokens/issues/53)) * `aud` format ([Issue #66](https://github.com/oauth-wg/oauth-transaction-tokens/issues/66)) * Should TraTs bet JWTs? ([Issue #50](https://github.com/oauth-wg/oauth-transaction-tokens/issues/50)) * Preserving `sub` value in replacement TraTs ([Issue #44](https://github.com/oauth-wg/oauth-transaction-tokens/issues/44)) ### Aud claim required? * (Atul) It could be a problem if it gets replayed in another trust domain * (George) With the change related to the `sub` field, the token should have something related to the trust domain * (Kelley) I'm in favor of keeping it required, so that the receiving party can verify the domain * (Atul) I will close the issue * (Brian) Keeping it required is reasonable and straightforward to other alternatives of figuring out the trust ### `aud` Format * (Brian) Just referring to JWT spec should be fine, without changing the definition of the claim * (Atul) I'll make the changes ### Should `subject_token` be required in a TraT request? * (George) There are two possibilities * (George) Inbound mail delivery is an example where there is no inbound token. You still have the email address, and you can put that in the `subject_token` field. We could put it in a signed JWT or we could just put the bare email address * (George) This spec is not prescriptive about that * (Atul) The text needs to be updated so that it doesn't assume an inbound token * (George) We shouldn't be prescriptive about what goes into the `subject_token` field * (Brian) We should not be prescriptive, but we should have something there * (George) We can add non-normative text that identifies possible ways in which you can use the `subject_token` field in the request ### Preserving `sub` value in replacement TraTs * (Pieter) When you get a replacement token, what is the expectation about the `sub`? Is it the requester of the replacement or the original `sub` value * (George) Great point. It depends on what replacement means. If replacement means I'm going to start a new transaction, in order to complete a bigger transaction, then the `sub` value could be different. * (George) So if you just want to update the claims in the original TraT, then the `sub` should be the same. * (George) If you pass a `subject_token` that is the original TraT, then you are just updating claims in the TraT. If the `subject_token` in the request is not the TraT, then you're just minting a new TraT * (George) We need clear use-cases for the replacement TraT in order to clarify this issue * (Pieter) Maybe there are two things: * augmenting an existing TraT and * Getting a new TraT * (Pieter) So if you are getting a new TraT, that's not a replacement * (George) So we need to clarify the text that the replacement TraT should have the same `sub`. We need to be prescriptive about that. * (Atul) We should be prescriptive about what goes into `sub`, and say that getting a new TraT is not replacement, just getting a new one * (Pieter) Is the action replacement or augmentation? * (Pieter) "prove to me that you've been to the fraud service" can be a replacement TraT * (George) Is the replacement process the right way to do this? The way this could work with replacmeent is that the fraud service requests the replacement, and the resultant TraT has the fraud service in the `azd` claim * (George) I would like to think about what is a viable way to do that with what we have now, before writing it into the spec. * (George) You don't want to lose the previous entities, so there needs to be some actor nesting * (Brian) Seems to me like the `sub` would still remain the same even with the augmentation use case. There is the `act` claim in the token exchange, but it's a fuzzy area. It may not be defined well in the token exchange spec for this particular use case * (Pieter) One of the things we have talked about in the past is preserving the call chain. The replacement process gives us one way to do that. Question is if we take out the replacement part, do we lose the mechanism to preserve call chain information * (Atul) Are we debating whether we need to have the replacement process? * (Pieter) That is the issue * (Pieter) If we don't have concrete use cases, having clarity about the language / what goes into the spec becomes unclear * (George) I would be OK if we add two prescriptive pieces: * The replacement should have identical subject as the original and * The subject token in the request must be the current transaction token * (Pieter) I think this is fine. We need to open a second issue that asks whether we need replacement transaction tokens? * (Atul) I remember Google had this requirements * (Ken) I know we were interested in preserving the call chain as the call passes through proxies, but I don't have the full context here. * (George) I'm not sure trying to track this inside the TraT is the best way to do this. One of the benefits of TraTs is that we can use them directly with other serivces. If we always have to go back to the TraT service to get a new token, then it becomes very inefficient (and is addressed by other specs) * (George) If it is more selective (i.e. only two of 10 intervening services need to keep their call chain) ## Identity Chaining ### Status of PR to limit the grant format to JWT * (Aaron) What is the status of this PR? * (Brian) I've created the PR that does exactly that - constrained the grant type to JWT. Also fixed some examples in the process, and the keeping the issued token type a JWT * [PR link](https://github.com/oauth-wg/oauth-identity-chaining/pull/72) * (Brian) I couldn't add Pieter as a reviewer * (Aaron) You probably don't have the right access * (Pieter) I'll try to review it - have any of the other authors looked at it? * (Aaron) Q for Brian: In the process of making the grant a JWT, I would like a term that is unique to this draft that describes this thing, beyond just a "token". Do you have any suggestions? * (Pieter) Identity chaining token * (Aaron) The other acronym "ACDC" seems convoluted * (Aaron) Identity chaining token has the same problem, because it doesn't say authorization * (Pieter) Just "Chaining Token"? * (Brian) We don't have an all-encompassing name for it. "authorization code" is problematic because ... * (Joe) "Linking Token"? * (Aaron) I'm agreeing with Brian that we should look at existing language in other specs rather than invent something new * (Brian) ... * (George) Of all the suggestions I like "chaining grant" the best * (Pieter) Are we addressing this in the current PR? * (Aaron) No. This is a separate discussion * (Brian) This draft only qualified it a bit more ### Other Changes to Id-Chaining * (Brian) There are some minor things that are important from a protocol point of view, but minor text changes. I will take that up * (Aaron) I was going to write up use-cases and restructuring the draft to move the use-cases to the appendix with the examples. I will create a separate PR for that ### Prospective name change of Id-Chaining * (Brian) There's a long email thread about that * (Pieter) There are two candidates: * "OAuth Multi-Domain Authorization and Identity Chaining Framework" * “OAuth Identity and authorization chaining across domains” * (Pieter) Mike / Kelley do you have a stronger requirement / opinion on the name? * (Aaron) Should we post these two options to the list and get more feedback? Having two options will narrow the conversation * (Pieter) Among ourselves, are we OK with either name? Do we need to consider other proposals? * (Mike) For me, I didn't like "identity" not being in the name. But adding cross-domain makes it complicated. Saying "multi-domain" avoids this issue * (Brian) I suspect many people are unaware of the issues with "cross-domain" * (Brian) Kelley's proposal to just add "Authorization" to the title looks good * "Identity and Authorization Chaining Across Trust Domains" * (Pieter) It's OAuth, and we are adding Authorization * (Pieter) Do we need to notify the mailing list? * (Brian) This is uncharted / unclear territory * (Brian) Having a small title change may not require discussion on the mailing list * (Aaron) I agree the version "Idenitty and Authorization Chaining Across Trust Domains" is a small enough change that we can just notify rather than ask for discussion on the mailing list * (Pieter) I'll get feedback from other editors, and others and make the changes