WIMSE Token Exchange / Translation
October 22, 2024

Attendees:

- Dean H. Saxe (Beyond Identity)
- Ken McCracken (Google)
- Flemming Andreasen
- Arndt Schwenkschuster
- John Kemp
- Yaroslav Rosomakho
- Justin Richer

Ken - there is a TBD property in the recent update for a x509 certifcate to access token exchange. Line 169 for the subject token. In this case token is used to refer to many different things. The subject token is an x509 certificate. Should the be required to be filled in? What happens if the subject is different from the x509 used to establish mTLS.

JohnK - Could it be a value we define that says the subject is in the mTLS handshake cert?

DHS - seems reasonable with a low likelihood of mistakes

Yaroslav - is mTLS mandatory? Can this work when mTLS is impractical or broken?

Ken - didn't think about that... was only thinking about mTLS having occurred? Maybe we can relax that constraint? The conventional thing is to do mTLS if we can.

JohnK - You wouldn't pass the defined value in the case where mTLS isn't used, this is about the mTLS only. In the non-mTLS case this won't be redundant.

Yaroslav - mTLS should be encouraged, but it can't be mandatory due to issues like load balancing

Flemming - We're trying to come up with scenarios and describe them in detail. We can specify a scenario without mTLS

Arndt - should it be empty or a fixed string? Token exchange specifies multiple ways to do client authN. There's a lot of risk here if we don't make it explicit. Likes the idea of a static string.

DHS - maybe it's a good idea to have multiple profiles

Yaroslav - I have deja vu, similar conversations happened in the design team. This lead to the requirements document.

Flemming - we talked about having a framework for coming up with the profiles. Agree with DHS, we can't solve the entire problem space. Have a framework to document these issues and specify common issues. Add new scenarios later.

DHS - Let's use Ken's work to define the profile format in an appendix and then use it to discover further disagreements.

Ken - 6749 has extensibility points in it. Are you saying we should be more concrete? What can we constrain, what can we modify? For example, new subject token types. Ken suggested a new one for x509, do we need one for a workload identity token itself? That would be another registered token type. The grant type is fixed by the RFC. (Ken meant to state RFC8693 which has the extension points.)

DHS - Informed Justin about the broad scope

JohnK - I reached out to BC to see whether he thinks 8693 meets the requirements. John thinks this does meet the 8693 requirements, we might be able to use this without saying anything further. In some ways we're constraining or profiling further 8693. Do we really want to do that through profiles? A usecase John knows about is using SPIFFE/SPIRE and wants to use Goog/AWS, how do we do that token translation? AWS IAM Roles Anywhere is one way to do this. John talked to Brian who pointed at a cross-domain token exchange (identity chaining) in OAuth. John doens't think this is totally appropriate, but we still need a mechanism for cross domain

Justin - From the chair perspective, not as the chair: Encourage the group to be wary of the OAuth hammer and we look like a nail. Many OAuth issues are wildly unconstrained and this has value and risk. What happens when you have a whole bunch of mutually blind to each other constraints on OAuth token exchange and you have to step through them at the same time? (DHS - Aaron Parecki raised this in Brisbane, perhaps?)

DHS - How do we define profiles and ensure they are used consistently?

Justin - (No chair hat) IANA doesn't require an RFC, just a designated expert that can approve. Hard to argue for this with IESG because of the rigor needed. IETF is slow, but it will shake out bugs that we might create if we go fast. RFC process doesn't have to be fast. Doc must be small, atomic, and focused work. If the extension mechanism is based on OAuth Token Exchange, for example, there is no definition for that.

Yaroslav - RFC publishing review isn't a gate for implementations, allows for evidence that things work before publication. When we were a design team we had the same challenge - too broad a set of use cases. We can go back to a definition of what needs to be documented for token translation profile.

DHS - Reinforces the idea of a documented set of requirements for a profile.

Justin - Process update - data tracker reopens the first day of IETF 121. We can push another update, but don't expect that it will be read.

Yaroslav - Can we ask for a side meeting?

Justin - Yes, you can. And that is appropriate.

Yaroslav - After WIMSE would be good.

Justin - meeting 1PM Thurs

DHS - Can we book a side meeting for Friday morning (Yaroslav)

Justin - don't conflict with SAG, also look at Thurs afternoon.

Yaroslav - will try not to clash with HTTP

Ken - Do you think the beginning of the token translation doc should describe how each instance of a profile would work? Where does the repeatable process go?

DHS - I think this goes in the appendix, but I'm not sure. We can write it and move it around.

Yaroslav - Friday morning side meeting being booked. 08:00 - 09:30