coexistence with bearer tokens

ietf-wg-wimse · Dec 23, 2024 · d9b62cd · d9b62cd
1 parent 165f190
commit d9b62cd
Showing 1 changed file with 13 additions and 0 deletions.
diff --git a/draft-ietf-wimse-s2s-protocol.md b/draft-ietf-wimse-s2s-protocol.md
@@ -523,6 +523,19 @@ so it cannot be easily reused in another context, which is often a security impr
 be designed to include extensibility to sign other fields, but this would make it closer to
 trying to reinvent Message Signatures.
 
+## Coexistence with JWT Bearer Tokens {coexist}
+
+The WIT and WPT define new HTTP headers. They can therefore be presented along with existing headers used for JWT bearer tokens. This
+property allows for transition from mechanisms using identity tokens based on bearer JWTs to proof of possession based WITs.
+A workload may implement a policy that accepts both bearer tokens and WITs during a transition period. This policy may be configurable
+per-caller to allow the workload reject bearer tokens from callers that support WITs. Once a deployment fully supports WITs, then the use of
+bearer tokens for identity can be disabled through policy.
+
+The WIT can also coexist with tokens used to establish security context, such as transaction tokens {{?I-D.ietf-oauth-transaction-tokens}}. In this case a workload's
+authorization policy may take into account both the sending workload's identity and the information in the context token. For example, the
+identity in the WIT may be used to establish which API calls can be made and information in the context token may be used to determine
+which specific resources can be accessed.
+
 # Using Mutual TLS for Service To Service Authentication {#mutual-tls}
 
 As noted in the introduction, for many deployments, transport-level protection