Use of WIT without proof of possession and interop with legacy systems

[jsalowey]

The current draft says that the WIT must not be accepted without proof of possession of the corresponding private key. This is for security reasons because if you are willing to accept the WIT without proof of possession then the security benefit of the WIT is greatly diminished.

This restriction makes it difficult to integrate a WIT seamlessly into existing applications. I question whether this could be done securely, but I think we should have the discussion:

1. Is there a sensible policy that would make this OK? It seems that legacy application would be none the worse off, but application that could handle the WIT would still benefit. I think there is a difficulty here in that you have client an services sides that might be updated a different times making it more complex.
2. Perhaps there is an alternate form of POP that would be easier. For example binding to a TLS key or identity. While this seems attractive, one of the reasons for the WIT is to suport cases where MTLS isn't realistic.

[yaronf]

And then the do-nothing alternative:

3. Don't allow using WIT without PoP (granted there's no way to enforce this restriction in the real world), and rely on token exchange to translate between legacy bearer tokens and WITs.

[kenmccracken-google]

I agree with both points (1.) and (2.).

1. is needed for backward-compatibility with existing "legacy" systems.
2. allows WITs to be built on top of existing X.509-credentials, which should be part of the recommended mTLS solution.

For both of these cases, claims within the WIT can further constrain access using "aud"/"scp" to express least-privileges access on top of an identity's (possibly-broad) access privileges imparted by Workload identity alone. The "aud"/"scp" constraints can also be preserved during federation with OIDC-like IdPs.

IMO, the WIMSE s2s protocol should provide the option 2 for PoP, where the protocol can accept WITs layered on top of existing X.509-credentials for situations where mTLS is realistic. In these cases, reducing the number of tokens required can reduce developer integration bugs and misconfigurations, when compared to the multi-token-requirements of Section 4. X.509 Certificate hash binding or SAN identity binding should be considered, as an adaptation of https://www.ietf.org/archive/id/draft-ietf-wimse-arch-01.html#name-identity-credentials "Alternatively, sender constrained tokens can be used such as TLS session binding."

[yaronf]

• For legacy systems, the bearer token's format is unspecified, so the WIMSE token cannot be coerced to have it.
• Also the type field would mismatch, and aud would be missing.

We don't see a way to use WITs with legacy systems.

A WIT would be ignored by a legacy system, but the non-legacy system would still need to include a legacy token as well.

[jsalowey]

A WIT is transported in its own header so it can co-exist with a legacy bearer token attribute.

• A legacy receiver will ignore the WIT and only use the bearer token
• A legacy sender will send both the WIT and the bearer token if it knows it needs to send the bearer token.

The systems that rely upon the WIT will be secure because it will not be used as a bearer token. The bearer token approach would still have all the problems of a bearer token. In this approach the WIT should convey the information from the bearer token that is necessary for it to be usable by the system.

There could be an alternate approach where the bearer token could have a superset of what is in the WIT if it also includes the identity in the WIT in a standard field. That way a system that understands how to use the WIT could also validate that the bear token is bound to the WIT (and not really a bearer token when used by a system that understands the WIT).

I'm not sure which approach is better right now, but the more information you include in the WIT the more chance it needs to be updated or revoked, so it might be worth defining what the legacy binding attribute to bind an existing token format to the WIT.

[yaronf]

A legacy sender will send both the WIT and the bearer token if it knows it needs to send the bearer token.

@jsalowey I think you meant to say, A non-legacy sender communicating with a legacy receiver will send...

But I think the point of the issue is that a non-legacy sender can send the WIT itself as the bearer token. I can see systems where this would work, if the bearer token is opaque to the receiver and is only validated by another service (e.g. an API Gateway), and where we're willing to modify that service to detect and validate WITs. That could be a reasonable migration strategy I believe.

[jsalowey]

I think it would be better to not allow using the WIT as a bearer token. It will cause problems because entities that use the WIT with POP do not have to be as concerned with what to do if a WIT is disclosed. If you start using it as a bearer token then that you reintroduce these concerns. If you're going to modify a system to use a WIT it needs to use the POP. If not just keep using the legacy Token.

[yaronf]

I can think of ways to deal with it. But all in all, I agree that it's simpler (for implementations) and more secure to keep the current wording that requires PoP for any use of the WIT.

[jsalowey]

The draft already states that the WIT MUST NOT be used as a bearer token and it defines new headers for the WIT and WPT so there is no conflict with existing tokens so they could be presented at the same time. I think this issue could be closed, but we could also add text to the document describing that bearer tokens in existing headers can be presented in the same message as WPT and WIT tokens for compatibility during transitions but applications should implement policy controls to reject the use of identity bearer tokens once the WIT is in use.

[jsalowey]

On call decided to add section on co-existance with bearer token JWT