diff --git a/draft-ietf-wimse-s2s-protocol.md b/draft-ietf-wimse-s2s-protocol.md index fbced6f..47207c0 100644 --- 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