Meeting on 2024-05-17

# Meeting on 2024-05-17 ## Attendees * Atul (SGNL) * Joe Jublinsky (MITRE) * George Fletcher (Cap One) * Aaron Parecki (Okta) * Arndt S (Microsoft) * Ken McCracken (Google) * Justin Richer (Bespoke) * Brian Campbell (Ping Identity) * Pieter Kasselman (Microsoft) * Mike Jenkins (NSA-CCSS) ## Agenda * Token Exchange Type ## Notes * (Aaron) There's no ambiguity if you are using Token exchange only for one thing, but if you want to add different types of token exchange, then you need to profile it differently (specific params, what they mean) * (Aaron) At best it's weird, and at worst, it is ambiguous * (Aaron) We should add a parameter to specify the type of token exchange we are doing * (Aaron) Has anyone else encountered this issue? * (George) I've seen the general problem in the past. E.g. If the "actor token" is present then the "subject token" is x, etc. leading to a large case statement in the dispatch function. If you only need to do 2-3 things in a token exchange, then its fine, but if the combinations explode, then it will get much more complicated * (Aaron) I've tried to list out how to solve this with a couple of options * (Brian) It's not in line with the extension mechanism * (Aaron) The other idea is a token exchange extension document that defines the "token exchange type", which can be used broadly, and you could have a registry for it * (Atul) Sounds like a good idea * (Brian) Totally disagree * (Brian) This is not actually problem, this creates an additional thing that complicates logic, and won't be supported by existing token exchange implementations * (Aaron) I'm going to try and find a situation where there is actual ambiguity, where all inputs are identical, but they do different things * (Brian) You can use token format or other things that already exist in the token exhcange spec to differentiate * (Arndt) IIRC we had a discussion about this, we used to have a requested token type parameter to indicate what we want, but we have removed it. * (Aaron) The draft now says "don't use requested token type" * (Arndt) If someone ... * (George) We're allowing for requested token type in TraTs * (Aaron) The TraTs spec defines a new token type * (Arndt) If requested token type were specified, would that help? * (George) We can specify a URI for the requested token type and expect a specific type of token in response * (George) My understanding was that we were going to remove the statement that you can't requested token type from the ID Chaining draft * (Aaron) The ID Chaining draft doesn't really say much about ... * (Arndt) Would it help you to have requested token type, where you would be able to differentiate what type of token you are requesting. You can execute without having to decode parameters * (Pieter) Issue "relax recommendation against requested_token_type use": https://github.com/oauth-wg/oauth-identity-chaining/issues/82 * (Justin) If we add a requested token type, it's not going to simplify the logic * (Aaron) The code path will be just "switch on this parameter" * (Justin) Until you get to the point where two paths use the same input parameter * (George) The other piece is that you're in a mode where other parameters may determine the code path, including the requested token type. The logic won't get simpler. * (Aaron) That's assuming there's an existing token exchange code that has to handle multiple types of tokens * (Joe) What happens if they don't match - the type versus the claim / assertion * (Aaron) The point is to know what code paths you are going to choose in a cleaner way. * (Joe) So you are taking it on faith that this is the right type * (Aaron) Not really * (Joe) What if they don't match? * (Aaron) There are error cases, e.g. if a client is not allowed to do something, and if the server doesn't know what the client is trying to do, the server is going to figure it out based on the parameters. * (Arndt) Back to the conversation about whether this pushes the problem down the load- for our ID Chaining use case, the logic will be pushed lower down with the requested token type parameter * (Pieter) If there's a very contrete example where we have an implementation that is running into this issue. It will be good to document such an example * (Aaron) If a client is first going to do a token exchange to get an access token from an ID token, and the audience of the access token is the resources it is talking, and if later it needs to get another access token to talk to another authorization server. In that case we can figure out the intent from 4 parameters, the best being the audience being the authorization server. Each such example may not be a problem in itself, but when this all comes together, it becomes one. * (Aaron) Maybe I can write up some examples * (Pieter) * (Aaron) This could be a token best practices * (Brian) I object to the idea of calling something that doesn't exist a best practice * (Aaron) One solution is a unique requested token type for each type. That could be used as a "clean switch" * (Brian) Is that access token being used as an access token, or is it just used in token exchange? * (Brian) IF it's not being used as an access token, then it's not an access token. I'm somewhat unhappy with the number of options we already have to indicate policy, and using requested token type narrows it a little, but it further exacerbates the logic. Using requested token type is better because that's what it is there for, instead of using a new parameter. * (Atul) Is it that we're trying to use Token Exchange where we shouldn't be? * (Aaron) That's one way we could go, to define a new spec that is different from token exchange * (Brian) There was early discussion on using the authorization grant to obtain an access token using a different mechanism. Token exchange works because it is open-ended enough to apply to other use cases * (George) Token-exchange == STS for historical purposes * (Brian) Defining a type for something that already exists and defining logic around it might complicate the picture even more * (Aaron) Right now an AS can't really ship token exchange as a feature unless it has some specific use-cases it is trying to address * (Aaron) You can support token exchange if you have well defined input parameters * (Aaron) for Okta to ship a token exchange service, we need to have clear rules(?) * (Brian) The Ping product that can be downloaded and run, the processing model is one where there is an abastract framework for accepting parameters, and based on policy you can determine how to use the parameters, how to validate the request, and delegate the production of a particular output token. This is all extensible and pluggable for all types of token types * (Brian) Theoretically, one could use a similar strategy. In that wold, the token type is not important, the decision could be based on all parameters. Defining a new type doesn't help in that case. It adds work where it is not needed. Even in the case of Okta, where the same source is deployed in a multi-tenant environment, new requested token types can be supported by policy and it would be sufficient for variuous functionalities. * (Aaron) One other implication is to admin UIs. We have check boxes to indicate which client can do what. Right now, a "token exchange" checkbox doesn't really mean anything. Instead we will have to create check boxes per use case, which aren't defined anywhere - in the token exchange spec or anything. * (Brian) I acknowledge this difficulty, there maybe shouldn't have been a grant type for the token exhange, but we have what we have now. * (George) To Aaron's point, it seems like potentially a small data table with various input parameters (requested token type, actor token type), etc. to some internal names, and then the name could be what you enable each client for * (Aaron) Why do I have to make up the name, when we are trying to follow standards * (George) IF it's profile based, then it is easy, e.g. "transaction token", or something like that * (Brian) TraTs are very much about the return type more than the input type * (George) The point is that we have an actual spec. * (Brian) There are a lot of use cases, which are not based on specs profileing token exchange, but based on policies * (George) But someone defined those policies to process certain inputs in a certain way. They're all defined outside the standards world. I don't know if we need a standard name / value for these things. Where we have an explicit porfile, e.g. TraTs, we can use that, else they can use internal names. * (Brian) Most of what I know things are driven off of are specific inputs and outputs. It's not in a client metadata anywhere AFAIK. The requested token type URI could for example drive the policy on the output. * (Aaron) It can't be just requested token type, because multiple type of input requests could result in access tokens * (Brian) It might be confirmation bias, but it confirms my feeling that you can't capture this in one type. You would be constraining * (Aaron) I can try to list out some token exchange use cases, and see what it takes to disambiguate in those cases. -- * (George) We need to come up with a list of issues we need to address before IETF 120, the close of submissions will be three weeks before that, which would be late June. * (Brian) There's conceptual overlap in this work between Wimse and OAuth * (Justin) I'm open to having this on the Wimse agenda * (Justin) We are having the Wimse interim meeting next Wednesday * (Brian) The draft submission cut off date is July 8th. (see https://datatracker.ietf.org/meeting/120/important-dates/) *