Skip to main content

WIMSE Service to Service Authentication
draft-ietf-wimse-s2s-protocol-01

Document Type Active Internet-Draft (wimse WG)
Authors Brian Campbell , Daniel Feldman , Joe Salowey , Arndt Schwenkschuster , Yaron Sheffer
Last updated 2024-10-18
Replaces draft-sheffer-wimse-s2s-protocol
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Proposed Standard
Formats
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state I-D Exists
Consensus boilerplate Yes
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-wimse-s2s-protocol-01
Workload Identity in Multi System Environments               B. Campbell
Internet-Draft                                             Ping Identity
Intended status: Standards Track                              D. Feldman
Expires: 21 April 2025                                       Independent
                                                              J. Salowey
                                                                  Venafi
                                                      A. Schwenkschuster
                                                                   SPIRL
                                                              Y. Sheffer
                                                                  Intuit
                                                         18 October 2024

                WIMSE Service to Service Authentication
                    draft-ietf-wimse-s2s-protocol-01

Abstract

   The WIMSE architecture defines authentication and authorization for
   software workloads in a variety of runtime environments, from the
   most basic ones up to complex multi-service, multi-cloud, multi-
   tenant deployments.  This document defines the simplest, atomic unit
   of this architecture: the protocol between two workloads that need to
   verify each other's identity in order to communicate securely.  The
   scope of this protocol is a single HTTP request-and-response pair.
   To address the needs of different setups, we propose two protocols,
   one at the application level and one that makes use of trusted TLS
   transport.  These two protocols are compatible, in the sense that a
   single call chain can have some calls use one protocol and some use
   the other.  Service A can call Service B with mutual TLS
   authentication, while the next call from Service B to Service C would
   be authenticated at the application level.

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at https://ietf-wg-
   wimse.github.io/draft-ietf-wimse-s2s-protocol/draft-ietf-wimse-s2s-
   protocol.html.  Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-ietf-wimse-s2s-protocol/.

   Discussion of this document takes place on the Workload Identity in
   Multi System Environments Working Group mailing list
   (mailto:wimse@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/wimse/.  Subscribe at
   https://www.ietf.org/mailman/listinfo/wimse/.

Campbell, et al.          Expires 21 April 2025                 [Page 1]
Internet-Draft               WIMSE S2S Auth                 October 2024

   Source for this draft and an issue tracker can be found at
   https://github.com/ietf-wg-wimse/draft-ietf-wimse-s2s-protocol.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 21 April 2025.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Deployment Architecture and Message Flow  . . . . . . . .   4
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   5
   3.  Workload Identity . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Trust Domain  . . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  Workload Identifier . . . . . . . . . . . . . . . . . . .   6
   4.  Application Level Service To Service Authentication . . . . .   6
     4.1.  The Workload Identity Token . . . . . . . . . . . . . . .   7
       4.1.1.  The WIT HTTP Header . . . . . . . . . . . . . . . . .   9
     4.2.  Option 1: DPoP-Inspired Authentication  . . . . . . . . .  10
     4.3.  Option 2: Authentication Based on HTTP Message
           Signatures  . . . . . . . . . . . . . . . . . . . . . . .  14

Campbell, et al.          Expires 21 April 2025                 [Page 2]
Internet-Draft               WIMSE S2S Auth                 October 2024

     4.4.  Comparing the DPoP Inspired Option with Message
           Signatures  . . . . . . . . . . . . . . . . . . . . . . .  17
   5.  Using Mutual TLS for Service To Service Authentication  . . .  18
     5.1.  Server Name Validation  . . . . . . . . . . . . . . . . .  19
     5.2.  Client Authorization Using the WIMSE Identity . . . . . .  19
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
     6.1.  WIMSE Identity  . . . . . . . . . . . . . . . . . . . . .  19
     6.2.  Workload Identity Token and Proof of Possession . . . . .  20
     6.3.  Middle Boxes  . . . . . . . . . . . . . . . . . . . . . .  21
     6.4.  Privacy Considerations  . . . . . . . . . . . . . . . . .  21
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  21
     7.1.  Media Type Registration . . . . . . . . . . . . . . . . .  22
     7.2.  Hypertext Transfer Protocol (HTTP) Field Name
           Registration  . . . . . . . . . . . . . . . . . . . . . .  22
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  22
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  22
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  23
   Appendix A.  Document History . . . . . . . . . . . . . . . . . .  24
     A.1.  draft-ietf-wimse-s2s-protocol-01  . . . . . . . . . . . .  24
     A.2.  draft-ietf-wimse-s2s-protocol-00  . . . . . . . . . . . .  24
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  25
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  25

1.  Introduction

   This document defines authentication and authorization in the context
   of interaction between two workloads.  This is the core component of
   the WIMSE architecture [I-D.ietf-wimse-arch].  For simplicity, this
   document focuses on HTTP-based services, and the service-to-service
   call consists of a single HTTP request and its response.  We define
   the credentials that both services should possess and how they are
   used to protect the HTTP exchange.

   There are multiple deployment styles in use today, and they result in
   different security properties.  We propose to address them
   differently.

   *  Many use cases have various middleboxes inserted between pairs of
      services, resulting in a transport layer that is not end-to-end
      encrypted.  We propose to address these use cases by protecting
      the HTTP messages at the application level (Section 4).

   *  The other commonly deployed architecture has a mutual-TLS
      connection between each pair of services.  This setup can be
      addressed by a simpler solution (Section 5).

Campbell, et al.          Expires 21 April 2025                 [Page 3]
Internet-Draft               WIMSE S2S Auth                 October 2024

   It is an explicit goal of this protocol that a service deployment can
   include both architectures across a multi-chain call.  In other
   words, Service A can call Service B with mutual TLS protection, while
   the next call to Service C is protected at the application level.

   For application-level protection we currently propose two alternative
   solutions, one inspired by DPoP [RFC9449] in Section 4.2 and one
   which is a profile of HTTP Message Signatures [RFC9421] in
   Section 4.3.  The design team believes that we need to pick one of
   these two alternatives for standardization, once we have understood
   their pros and cons.

1.1.  Deployment Architecture and Message Flow

   Regardless of the transport between the workloads, we assume the
   following logical architecture:

   +------------+               +------------+
   |            |               |            |
   |            |               | Workload B |
   | Workload A |==============>|            |
   |            |               |   +--------+
   |            |               |   |  PEP   |
   +------------+               +---+--------+
         ^                        ^     ^
         |                        |     |
         | +----------------------+     |
         | |                            |
         v v                            v
   +------------+               +------------+
   |            |               |            |
   |  Identity  |               |    PDP     |
   |   Server   |               | (optional) |
   |            |               |            |
   +------------+               +------------+

   The Identity Server provisions credentials to each of the workloads.
   At least Workload A (and possibly both) must be provisioned with a
   credential before the call can proceed.  Details of communication
   with the Identity Server are out of scope of this document, however
   we do describe the credential received by the workload.

   PEP is a Policy Enforcement Point, the component that allows the call
   to go through or blocks it.  PDP is an optional Policy Decision
   Point, which may be deployed in architectures where policy management
   is centralized.  All details of policy management and message
   authorization are out of scope of this document.

Campbell, et al.          Expires 21 April 2025                 [Page 4]
Internet-Draft               WIMSE S2S Auth                 October 2024

   The high-level message flow is as follows:

   *  Workload A obtains a credential from the Identity Server.  This
      happens periodically, e.g. once every 24 hours.

   *  Workload A makes an HTTP call into Workload B.  This is a regular
      HTTP request, with the additional protection mechanisms defined
      below.

   *  Workload B now authenticates Workload A and decides whether to
      authorize the call.  In certain architectures, Workload B may need
      to consult with an external server to decide whether to accept the
      call.

   *  Workload B returns a response to Workload A, which may be an error
      response or a regular one.

2.  Conventions and Definitions

   This document uses "service" and "workload" interchangeably.
   Otherwise, all terms are as defined by [I-D.ietf-wimse-arch].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Workload Identity

3.1.  Trust Domain

   A trust domain is a logical grouping of systems that share a common
   set of security controls and policies.  WIMSE certificates and tokens
   are issued under the authority of a trust domain.  Trust domains
   SHOULD be identified by a fully qualified domain name belonging to
   the organization defining the trust domain.  A trust domain maps to
   one or more trust anchors for validating X.509 certificates and a
   mechanism to securely obtain a JWK Set [RFC7517] for validating WIMSE
   WIT tokens.  This mapping MUST be obtained through a secure mechanism
   that ensures the authenticity and integrity of the mapping is fresh
   and not compromised.  This secure mechanism is out of scope for this
   document.

Campbell, et al.          Expires 21 April 2025                 [Page 5]
Internet-Draft               WIMSE S2S Auth                 October 2024

   A single organization may define multiple trust domains for different
   purposes such as different departments or environments.  Each trust
   domain must have a unique identifier.  Workload identifiers are
   scoped within a trust domain.  If two identifiers differ only by
   trust domain they still refer to two different entities.

3.2.  Workload Identifier

   This document defines a workload identifier as a URI [RFC3986].  This
   URI is used in the subject fields in the certificates and tokens
   defined later in this document.  The URI MUST meet the criteria for
   the URI type of Subject Alternative Name defined in Section 4.2.1.6
   of [RFC5280].

      The name MUST NOT be a relative URI, and it MUST follow the URI
      syntax and encoding rules specified in [RFC3986].  The name MUST
      include both a scheme and a scheme-specific-part.

   In addition the URI MUST include an authority that identifies the
   trust domain within which the identifier is scoped.  The trust domain
   SHOULD be a fully qualified domain name belonging to the organization
   defining the trust domain to help provide uniqueness for the trust
   domain identifier.  The scheme and scheme specific part are not
   defined by this specification.  An example of an identifier format
   that conforms to this definition is SPIFFE ID
   (https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE-ID.md).
   While the URI encoding rules allow host names to be specified as IP
   addresses, IP addresses MUST NOT be used to represent trust domains
   except in the case where they are needed for compatibility with
   existing naming schemes.

4.  Application Level Service To Service Authentication

   As noted in the Introduction, for many deployments communication
   between workloads cannot use end-to-end TLS.  For these deployment
   styles, this document proposes application-level protections.

   The current version of the document includes two alternatives, both
   using the newly introduced Workload Identity Token (Section 4.1).
   The first alternative (Section 4.2) is inspired by the OAuth DPoP
   specification.  The second (Section 4.3) is based on the HTTP Message
   Signatures RFC.  We present both alternatives and expect the working
   group to select one of them as this document progresses towards IETF
   consensus.  A comparison of the two alternatives is attempted in
   Section 4.4.

Campbell, et al.          Expires 21 April 2025                 [Page 6]
Internet-Draft               WIMSE S2S Auth                 October 2024

4.1.  The Workload Identity Token

   The Workload Identity Token (WIT) is a JWS [RFC7515] signed JWT
   [RFC7519] that represents the identity of a workload.  It is issued
   by the Identity Server and binds a public key to the workload
   identity.  A WIT MUST contain the following:

   *  in the JOSE header:

      -  alg: An identifier for a JWS asymmetric digital signature
         algorithm (registered algorithm identifiers are listed in the
         IANA JOSE Algorithms registry [IANA.JOSE.ALGS]).  The value
         none MUST NOT be used.

      -  typ: the WIT is explicitly typed, as recommended in
         Section 3.11 of [RFC8725], using the wimse-id+jwt media type.

   *  in the JWT claims:

      -  iss: The issuer of the token, which is the Identity Server,
         represented by a URI.

      -  sub: The subject of the token, which is the identity of the
         workload, represented by a URI.

      -  exp: The expiration time of the token (as defined in
         Section 4.1.4 of [RFC7519]).  WITs should be refreshed
         regularly, e.g. on the order of hours.

      -  jti: A unique identifier for the token.

      -  cnf: A confirmation claim containing the public key of the
         workload using the jwk member as defined in Section 3.2 of
         [RFC7800].  The workload MUST prove possession of the
         corresponding private key when presenting the WIT to another
         party, which can be accomplished by using it in conjunction
         with one of the methods in Section 4.2 or Section 4.3.  As
         such, it MUST NOT be used as a bearer token and is not intended
         for use in the Authorization header.

   An example WIT might look like this (all examples, of course, are
   non-normative and with line breaks and extra space for readability):

Campbell, et al.          Expires 21 April 2025                 [Page 7]
Internet-Draft               WIMSE S2S Auth                 October 2024

   eyJ0eXAiOiJ3aW1zZS1pZCtqd3QiLCJhbGciOiJFUzI1NiIsImtpZCI6Ikp1bmUgNSJ9.
   eyJpc3MiOiJ3aW1zZTovL2V4YW1wbGUuY29tL3RydXN0ZWQtY2VudHJhbC1hdXRob3Jpd
   HkiLCJleHAiOjE3MTc2MTI0NzAsInN1YiI6IndpbXNlOi8vZXhhbXBsZS5jb20vc3BlY2
   lmaWMtd29ya2xvYWQiLCJqdGkiOiJ4LV8xQ1RMMmNjYTNDU0U0Y3diX18iLCJjbmYiOns
   iandrIjp7Imt0eSI6Ik9LUCIsImNydiI6IkVkMjU1MTkiLCJ4IjoiX2FtUkMzWXJZYkho
   SDFSdFlyTDhjU21URE1oWXRPVVRHNzhjR1RSNWV6ayJ9fX0.rOSUMR8I5WhM5C704l3iV
   dY0zFqxhugJ8Jo2xo39G7FqUTbwTzAGdpz2lHp6eL1M486XmRgl3uyjj6R_iuzNOA

             Figure 1: An example Workload Identity Token (WIT)

   The decoded JOSE header of the WIT from the example above is shown
   here:

   {
    "typ": "wimse-id+jwt",
    "alg": "ES256",
    "kid": "June 5"
   }

                     Figure 2: Example WIT JOSE Header

   The decoded JWT claims of the WIT from the example above are shown
   here:

   {
    "iss": "wimse://example.com/trusted-central-authority",
    "exp": 1717612470,
    "sub": "wimse://example.com/specific-workload",
    "jti": "x-_1CTL2cca3CSE4cwb__",
    "cnf": {
     "jwk": {
      "kty": "OKP",
      "crv": "Ed25519",
      "x": "_amRC3YrYbHhH1RtYrL8cSmTDMhYtOUTG78cGTR5ezk"
     }
    }
   }

                        Figure 3: Example WIT Claims

   The claims indicate that the example WIT:

   *  was issued by an Identity Server known as wimse://example.com/
      trusted-central-authority.

   *  is valid until May 15, 2024 3:28:45 PM GMT-06:00 (represented as
      NumericDate Section 2 of [RFC7519] value 1717612470).

Campbell, et al.          Expires 21 April 2025                 [Page 8]
Internet-Draft               WIMSE S2S Auth                 October 2024

   *  identifies the workload to which the token was issued as
      wimse://example.com/specific-workload.

   *  has a unique identifier of x-_1CTL2cca3CSE4cwb__.

   *  binds the public key represented by the jwk confirmation method to
      the workload wimse://example.com/specific-workload.

   For elucidative purposes only, the workload's key, including the
   private part, is shown below in JWK [RFC7517] format:

   {
    "kty":"OKP",
    "crv":"Ed25519",
    "x":"_amRC3YrYbHhH1RtYrL8cSmTDMhYtOUTG78cGTR5ezk",
    "d":"G4lGAYFtFq5rwyjlgSIRznIoCF7MtKDHByyUUZCqLiA"
   }

                      Figure 4: Example Workload's Key

   The afore-exampled WIT is signed with the private key of the Identity
   Server.  The public key(s) of the Identity Server need to be known to
   all workloads in order to verify the signature of the WIT.  The
   Identity Server's public key from this example is shown below in JWK
   [RFC7517] format:

   {
    "kty":"EC",
    "kid":"June 5",
    "x":"kXqnA2Op7hgd4zRMbw0iFcc_hDxUxhojxOFVGjE2gks",
    "y":"n__VndPMR021-59UAs0b9qDTFT-EZtT6xSNs_xFskLo",
    "crv":"P-256"
   }

                   Figure 5: Example Identity Server Key

4.1.1.  The WIT HTTP Header

   A WIT is conveyed in an HTTP header field named Workload-Identity-
   Token.

   For those who celebrate, ABNF [RFC5234] for the value of Workload-
   Identity-Token header field is provided in Figure 6:

   ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
   DIGIT = %x30-39 ; 0-9
   base64url = 1*(ALPHA / DIGIT / "-" / "_")
   WIT =  base64url "." base64url "." base64url

Campbell, et al.          Expires 21 April 2025                 [Page 9]
Internet-Draft               WIMSE S2S Auth                 October 2024

            Figure 6: Workload-Identity-Token Header Field ABNF

   The following shows the WIT from Figure 1 in an example of a
   Workload-Identity-Token header field:

   Workload-Identity-Token: eyJ0eXAiOiJ3aW1zZS1pZCtqd3QiLCJhbGciOiJFUzI1
    NiIsImtpZCI6Ikp1bmUgNSJ9.eyJpc3MiOiJ3aW1zZTovL2V4YW1wbGUuY29tL3RydXN
    0ZWQtY2VudHJhbC1hdXRob3JpdHkiLCJleHAiOjE3MTc2MTI0NzAsInN1YiI6IndpbXN
    lOi8vZXhhbXBsZS5jb20vc3BlY2lmaWMtd29ya2xvYWQiLCJqdGkiOiJ4LV8xQ1RMMmN
    jYTNDU0U0Y3diX18iLCJjbmYiOnsiandrIjp7Imt0eSI6Ik9LUCIsImNydiI6IkVkMjU
    1MTkiLCJ4IjoiX2FtUkMzWXJZYkhoSDFSdFlyTDhjU21URE1oWXRPVVRHNzhjR1RSNWV
    6ayJ9fX0.rOSUMR8I5WhM5C704l3iVdY0zFqxhugJ8Jo2xo39G7FqUTbwTzAGdpz2lHp
    6eL1M486XmRgl3uyjj6R_iuzNOA

       Figure 7: An example Workload Identity Token HTTP Header Field

   Note that per [RFC9110], header field names are case insensitive;
   thus, Workload-Identity-Token, workload-identity-token, WORKLOAD-
   IDENTITY-TOKEN, etc., are all valid and equivalent header field
   names.  However, case is significant in the header field value.

4.2.  Option 1: DPoP-Inspired Authentication

   This option, inspired by the OAuth DPoP specification [RFC9449], uses
   a DPoP-like mechanism to authenticate the calling workload in the
   context of the request.  The WIMSE Identity Token (Section 4.1) is
   sent in the request as described in Section 4.1.1.  An additional
   JWT, the Workload Proof Token (WPT), is signed by the private key
   corresponding to the public key in the WIT.  The WPT is sent in the
   Workload-Proof-Token header field of the request.  A WPT contains the
   following:

   *  in the JOSE header:

      -  alg: An identifier for an appropriate JWS asymmetric digital
         signature algorithm corresponding to the confirmation key in
         the associated WIT.

      -  typ: the WPT is explicitly typed, as recommended in
         Section 3.11 of [RFC8725], using the application/wimse-
         proof+jwt media type.

   *  in the JWT claims:

      -  iss: The issuer of the token, which is the calling workload,
         represented by the same value as the sub claim of the
         associated WIT.

Campbell, et al.          Expires 21 April 2025                [Page 10]
Internet-Draft               WIMSE S2S Auth                 October 2024

      -  aud: The audience of the token contains the HTTP target URI
         (Section 7.1 of [RFC9110]) of the request to which the WPT is
         attached, without query or fragment parts.

      -  exp: The expiration time of the WIT (as defined in
         Section 4.1.4 of [RFC7519]).  WPT lifetimes MUST be short,
         e.g., on the order of minutes or seconds.

      -  jti: A unique identifier for the token.

      -  wth: Hash of the Workload Identity Token, defined in
         Section 4.1.  The value is the base64url encoding of the
         SHA-256 hash of the ASCII encoding of the token's value.

      -  ath: Hash of the OAuth access token, if present in the request,
         which might convey end-user identity and authorization context
         of the request.  The value, as per Section 4.1 of [RFC9449], is
         the base64url encoding of the SHA-256 hash of the ASCII
         encoding of the access token's value.

      -  tth: Hash of the Txn-Token [I-D.ietf-oauth-transaction-tokens],
         if present in the request, which might convey end-user identity
         and authorization context of the request.  The value MUST be
         the result of a base64url encoding (as defined in Section 2 of
         [RFC7515]) of the SHA-256 hash of the ASCII encoding of the
         associated token's value.

      -  oth: Hash of any other token in the request that might convey
         end-user identity and authorization context of the request, if
         such a token exists.  The value MUST be the result of a
         base64url encoding (as defined in Section 2 of [RFC7515]) of
         the SHA-256 hash of the ASCII encoding of the associated
         token's value.  (Note: this is less than ideal but seems we
         need something like this for extensibility.)

   An example WPT might look like the following:

   eyJhbGciOiJFZERTQSIsInR5cCI6IndpbXNlLXByb29mK2p3dCJ9.eyJhdGgiOiJDTDR3
   amZwUm1OZi1iZFlJYllMblY5ZDVyTUFSR3dLWUUxMHdVd3pDMGpJIiwiYXVkIjoiaHR0c
   HM6Ly9zZXJ2aWNlLmV4YW1wbGUuY29tL3BhdGgiLCJleHAiOjE3Mjg2NTg2NzIsImlzcy
   I6IndpbXNlOi8vZXhhbXBsZS5jb20vc3BlY2lmaWMtd29ya2xvYWQiLCJqdGkiOiI0YjQ
   yYzVmNjExZTJiMWNmYTFkMmM0MWIzYTJmYjc4MiIsInd0aCI6Ii1KaThUbE1ORmszcW16
   bXBBeEJPXzdXLVl1dGNIXzJfZnVGQUZGU1YxUmcifQ.jrUBsDjWMG_FpuhLo3lNC-IBei
   PQXZ4UOuttPdNj8fRmIG4ZDFF9B10y7uGbiNIhbRdpgG_KXEPLHXWnvzLmBA

                Figure 8: Example Workload Proof Token (WPT)

Campbell, et al.          Expires 21 April 2025                [Page 11]
Internet-Draft               WIMSE S2S Auth                 October 2024

   The decoded JOSE header of the WPT from the example above is shown
   here:

   {
     "alg": "EdDSA",
     "typ": "wimse-proof+jwt"
   }

                     Figure 9: Example WPT JOSE Header

   The decoded JWT claims of the WPT from the example above are shown
   here:

   {
     "ath": "CL4wjfpRmNf-bdYIbYLnV9d5rMARGwKYE10wUwzC0jI",
     "aud": "https://service.example.com/path",
     "exp": 1728658672,
     "iss": "wimse://example.com/specific-workload",
     "jti": "4b42c5f611e2b1cfa1d2c41b3a2fb782",
     "wth": "-Ji8TlMNFk3qmzmpAxBO_7W-YutcH_2_fuFAFFSV1Rg"
   }

                       Figure 10: Example WPT Claims

   An example of an HTTP request with both the WIT and WPT from prior
   examples is shown below:

Campbell, et al.          Expires 21 April 2025                [Page 12]
Internet-Draft               WIMSE S2S Auth                 October 2024

   POST /path HTTP/1.1
   Host: service.example.com
   Content-Type: application/json
   Authorization: Bearer 16_mAd0GiwaZokU26_0902100
   Workload-Identity-Token: eyJ0eXAiOiJ3aW1zZS1pZCtqd3QiLCJhbGciOiJFUzI1
     NiIsImtpZCI6Ikp1bmUgNSJ9.eyJpc3MiOiJ3aW1zZTovL2V4YW1wbGUuY29tL3RydX
     N0ZWQtY2VudHJhbC1hdXRob3JpdHkiLCJleHAiOjE3MTc2MTI0NzAsInN1YiI6Indpb
     XNlOi8vZXhhbXBsZS5jb20vc3BlY2lmaWMtd29ya2xvYWQiLCJqdGkiOiJ4LV8xQ1RM
     MmNjYTNDU0U0Y3diX18iLCJjbmYiOnsiandrIjp7Imt0eSI6Ik9LUCIsImNydiI6IkV
     kMjU1MTkiLCJ4IjoiX2FtUkMzWXJZYkhoSDFSdFlyTDhjU21URE1oWXRPVVRHNzhjR1
     RSNWV6ayJ9fX0.rOSUMR8I5WhM5C704l3iVdY0zFqxhugJ8Jo2xo39G7FqUTbwTzAGd
     pz2lHp6eL1M486XmRgl3uyjj6R_iuzNOA
   Workload-Proof-Token: eyJhbGciOiJFZERTQSIsInR5cCI6IndpbXNlLXByb29mK2p
     3dCJ9.eyJhdGgiOiJDTDR3amZwUm1OZi1iZFlJYllMblY5ZDVyTUFSR3dLWUUxMHdVd
     3pDMGpJIiwiYXVkIjoiaHR0cHM6Ly9zZXJ2aWNlLmV4YW1wbGUuY29tL3BhdGgiLCJl
     eHAiOjE3Mjg2NTg2NzIsImlzcyI6IndpbXNlOi8vZXhhbXBsZS5jb20vc3BlY2lmaWM
     td29ya2xvYWQiLCJqdGkiOiI0YjQyYzVmNjExZTJiMWNmYTFkMmM0MWIzYTJmYjc4Mi
     IsInd0aCI6Ii1KaThUbE1ORmszcW16bXBBeEJPXzdXLVl1dGNIXzJfZnVGQUZGU1YxU
     mcifQ.jrUBsDjWMG_FpuhLo3lNC-IBeiPQXZ4UOuttPdNj8fRmIG4ZDFF9B10y7uGbi
     NIhbRdpgG_KXEPLHXWnvzLmBA

   {"do stuff":"please"}

              Figure 11: Example HTTP Request with WIT and WPT

   To validate the WPT in the request, the recipient MUST ensure the
   following:

   *  There is exactly one Workload-Proof-Token header field in the
      request.

   *  The Workload-Proof-Token header field value is a single and well-
      formed JWT.

   *  The WPT signature is valid using the public key from the
      confirmation claim of the WIT.

   *  The typ JOSE header parameter of the WPT conveys a media type of
      wimse-proof+jwt.

   *  The iss claim of the WPT matches the sub claim of the WIT.  (Note:
      not sure iss in the WPT is useful or necessary.)

   *  The aud claim of the WPT matches the target URI, or an acceptable
      alias or normalization thereof, of the HTTP request in which the
      WPT was received, ignoring any query and fragment parts.

Campbell, et al.          Expires 21 April 2025                [Page 13]
Internet-Draft               WIMSE S2S Auth                 October 2024

   *  The exp claim is present and conveys a time that has not passed.
      WPTs with an expiration time unreasonably far in the future SHOULD
      be rejected.

   *  The wth claim is present and matches the hash of the token value
      conveyed in the Workload-Identity-Token header.

   *  Optionally, check that the value of the jti claim has not been
      used before in the time window in which the respective WPT would
      be considered valid.

   *  If presented in conjunction with an OAuth access token, the value
      of the ath claim matches the hash of that token's value.

   *  If presented in conjunction with a Txn-Token, the value of the tth
      claim matches the hash of that token's value.

   *  If presented in conjunction with a token conveying end-user
      identity or authorization context, the value of the oth claim
      matches the hash of that token's value.

4.3.  Option 2: Authentication Based on HTTP Message Signatures

   This option uses the WIMSE Identity Token (Section 4.1) to sign the
   request and optionally, the response.  This section defines a profile
   of the Message Signatures specification [RFC9421].

   The request is signed as per [RFC9421].  The following derived
   components MUST be signed:

   *  @method

   *  @request-target

   In addition, the following request headers MUST be signed when they
   exist:

   *  Content-Type

   *  Content-Digest

   *  Authorization

   *  Txn-Token [I-D.ietf-oauth-transaction-tokens]

   *  Workload-Identity-Token

   If the response is signed, the following components MUST be signed:

Campbell, et al.          Expires 21 April 2025                [Page 14]
Internet-Draft               WIMSE S2S Auth                 October 2024

   *  @status

   *  @method;req

   *  @request-target;req

   *  Content-Type if it exists

   *  Content-Digest if it exists

   *  Workload-Identity-Token

   For both requests and responses, the following signature parameters
   MUST be included:

   *  created

   *  expires - expiration MUST be short, e.g. on the order of minutes.
      The WIMSE architecture will provide separate mechanisms in support
      of long-lived compute processes.

   *  nonce

   *  tag - the value for implementations of this specification is
      wimse-service-to-service

   Since the signing key is sent along with the message, the keyid
   parameter SHOULD NOT be used.

   It is RECOMMENDED to include only one signature with the HTTP
   message.  If multiple ones are included, then the signature label
   included in both the Signature-Input and Signature headers SHOULD be
   wimse.

   A sender MUST ensure that each nonce it generates is unique, at least
   among messages sent to the same recipient.  To detect message
   replays, a recipient MAY reject a message (request or response) if a
   nonce is repeated.

   To promote interoperability, the ecdsa-p256-sha256 signing algorithm
   MUST be implemented by general purpose implementations of this
   document.

   // OPEN ISSUE: do we use the Accept-Signature field to signal that
   // the response must be signed?

Campbell, et al.          Expires 21 April 2025                [Page 15]
Internet-Draft               WIMSE S2S Auth                 October 2024

   Following is a non-normative example of a signed request and a signed
   response, where the caller is using the keys specified in Figure 4.

   =============== NOTE: '\' line wrapping per RFC 8792 ================

   GET /gimme-ice-cream?flavor=vanilla HTTP/1.1
   Host: example.com
   Signature: wimse=:K4dfGnguF5f1L4DKBSp5XeFXosLGj8Y9fiUX06rL/wdOF+x3zT\
   WmsvKWiY0B1oFZaOtm2FHru+YLjdkqa2WfCQ==:
   Signature-Input: wimse=("@method" "@request-target" "workload-identi\
   ty-token");created=1718291357;expires=1718291657;nonce="abcd1111";ta\
   g="wimse-service-to-service"
   Workload-Identity-Token: aGVhZGVyCg.VGhpcyBpcyBub3QgYSByZWFsIHRva2Vu\
   Lgo.c2lnbmF0dXJlCg

                         Figure 12: Signed Request

   Assuming that the workload being called has the following keypair:

   {
    "kty":"OKP",
    "crv":"Ed25519",
    "x":"CfaY1XX-aHJpenRP8ATm3yGlbcKA_treqOfwKrilwyg",
    "d":"fycSKS-iHZ6TC1BNwN6cE0sOBP3-4KgR-eqxNpnyhws"
   }

                       Figure 13: Callee Private Key

   A signed response would be:

   =============== NOTE: '\' line wrapping per RFC 8792 ================

   HTTP/1.1 404 Not Found
   Connection: close
   Content-Digest: sha-256=:47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU\
   =:
   Content-Type: text/plain
   Signature: wimse=:NMrMn3xhI6m9PI8mKVfpnH5qFGcEfuFxiCmsB5PJhGjUHT/5J4\
   612EZwRw3V4kU4gGJmO+ER8RC4DM2HKVOYDQ==:
   Signature-Input: wimse=("@status" "workload-identity-token" "content\
   -type" "content-digest" "@method";req "@request-target";req);created\
   =1718295368;expires=1718295670;nonce="abcd2222";tag="wimse-service-t\
   o-service"
   Workload-Identity-Token: aGVhZGVyCg.VGhpcyBhaW4ndCBvbmUsIHRvby4K.c2l\
   nbmF0dXJlCg

   No ice cream today.

Campbell, et al.          Expires 21 April 2025                [Page 16]
Internet-Draft               WIMSE S2S Auth                 October 2024

                         Figure 14: Signed Response

4.4.  Comparing the DPoP Inspired Option with Message Signatures

   // This section is temporarily part of the draft, while we expect the
   // working group to select one of these options.

   The two workload protection options have different strengths and
   weaknesses regarding implementation complexity, extensibility, and
   security.  Here is a summary of the main differences between
   Section 4.2 and Section 4.3.

   *  The DPoP-inspired solution is less HTTP-specific, making it easier
      to adapt for other protocols beyond HTTP.  This flexibility is
      particularly valuable for asynchronous communication scenarios,
      such as event-driven systems.

   *  Message Signatures, on the other hand, benefit from an existing
      HTTP-specific RFC with some established implementations.  This
      existing groundwork means that this option could be simpler to
      deploy, to the extent such implementations are available and
      easily integrated.

   *  Given that the WIT (Workload Identity Token) is a type of JWT, the
      DPoP-inspired approach that also uses JWT is less complex and
      technology-intensive than Message Signatures.  In contrast,
      Message Signatures introduce an additional layer of technology,
      potentially increasing the complexity of the overall system.

   *  Message Signatures offer superior integrity protection,
      particularly by mitigating message modification by middleboxes.
      See also Section 6.3.

   *  A key advantage of Message Signatures is that they support
      response signing.  This opens up the possibility for future
      decisions about whether to make response signing mandatory,
      allowing for flexibility in the specification and/or in specific
      deployment scenarios.

Campbell, et al.          Expires 21 April 2025                [Page 17]
Internet-Draft               WIMSE S2S Auth                 October 2024

   *  In general, Message Signatures provide greater flexibility
      compared to the DPoP-inspired approach.  Future versions of this
      draft (and subsequent implementations) can decide whether specific
      aspects of message signing, such as coverage of particular fields,
      should be mandatory or optional.  Covering more fields will
      constrain the proof so it cannot be easily reused in another
      context, which is often a security improvement.  The DPoP inspired
      approach could be designed to include extensibility to sign other
      fields, but this would make it closer to trying to reinvent
      Message Signatures.

5.  Using Mutual TLS for Service To Service Authentication

   As noted in the introduction, for many deployments, transport-level
   protection of application traffic using TLS is ideal.

   In this solution, the WIMSE workload identity may be carried within
   an X.509 certificate.  The WIMSE workload identity MUST be encoded in
   a SubjectAltName extension of type URI.  There MUST be only one
   SubjectAltName extension of type URI in a WIMSE certificate.  If the
   workload will act as a TLS server for clients that do not understand
   WIMSE workload identities it is RECOMMENDED that the WIMSE
   certificate contain a SubjectAltName of type DNSName with the
   appropriate DNS names for the server.  The certificate may contain
   SubjectAltName extensions of other types.

   WIMSE certificates may be used to authenticate both the server and
   client side of the connections.  When validating a WIMSE certificate,
   the relying party MUST use the trust anchors configured for the trust
   domain in the WIMSE identity to validate the peer's certificate.
   Other PKIX [RFC5280] path validation rules apply.  WIMSE clients and
   servers MUST validate that the trust domain portion of the WIMSE
   certificate matches the expected trust domain for the other side of
   the connection.

   Servers wishing to use the WIMSE certificate for authorizing the
   client MUST require client certificate authentication in the TLS
   handshake.  Other methods of post handshake authentication are not
   specified by this document.

   WIMSE server certificates SHOULD have the id-kp-serverAuth extended
   key usage [RFC5280] field set and WIMSE client certificates SHOULD
   have the id-kp-clientAuth extended key usage field set.  A
   certificate that is used for both client and server connections may
   have both fields set.  This specification does not make any other
   requirements beyond [RFC5280] on the contents of WIMSE certificates
   or on the certification authorities that issue WIMSE certificates.

Campbell, et al.          Expires 21 April 2025                [Page 18]
Internet-Draft               WIMSE S2S Auth                 October 2024

5.1.  Server Name Validation

   If the WIMSE client uses a hostname to connect to the server and the
   server certificate contain a DNS SAN the client MUST perform standard
   host name validation (Section 6.3 of [RFC9525]) unless it is
   configured with the information necessary to validate the peer's
   WIMSE identity.  If the client did not perform standard host name
   validation then the WIMSE client SHOULD further use the WIMSE
   workload identifier to validate the server.  The host portion of the
   WIMSE URI is NOT treated as a host name as specified in section 6.4
   of [RFC9525] but rather as a trust domain.  The server identity is
   encoded in the path portion of the WIMSE workload identifier in a
   deployment specific way.  Validating the WIMSE workload identity
   could be a simple match on the trust domain and path portions of the
   identifier or validation may be based on the specific details on how
   the identifier is constructed.  The path portion of the WIMSE
   identifier MUST always be considered in the scope of the trust
   domain.

5.2.  Client Authorization Using the WIMSE Identity

   The server application retrieves the client certificate WIMSE URI
   subjectAltName from the TLS layer for use in authorization,
   accounting and auditing.  For example, the full WIMSE URI may be
   matched against ACLs to authorize actions requested by the peer and
   the URI may be included in log messages to associate actions to the
   client workload for audit purposes.  A deployment may specify other
   authorization policies based on the specific details of how the WIMSE
   identifier is constructed.  The path portion of the WIMSE identifier
   MUST always be considered in the scope of the trust domain.

6.  Security Considerations

6.1.  WIMSE Identity

   The WIMSE Identifier is scoped within an issuer and therefore any
   sub-components (path portion of Identifier) are only unique within a
   trust domain defined by the issuer.  Using a WIMSE Identifier without
   taking into account the trust domain could allow one domain to issue
   tokens to spoof identities in another domain.  Additionally, the
   trust domain must be tied to an authorized issuer cryptographic trust
   anchor through some mechanism such as a JWKS or X.509 certificate
   chain.  The association of an issuer, trust domain and a
   cryptographic trust anchor MUST be communicated securely out of band.

   // TODO: Should there be a DNS name to trust domain mapping defined
   // or some other discovery mechanism?

Campbell, et al.          Expires 21 April 2025                [Page 19]
Internet-Draft               WIMSE S2S Auth                 October 2024

6.2.  Workload Identity Token and Proof of Possession

   The Workload Identity Token (WIT) is bound to a secret cryptographic
   key and is always presented with a proof of possession as described
   in Section 4.1.  The WIT is a general purpose token that can be
   presented in multiple contexts.  The WIT and its PoP are only used in
   the application-level options, and both are not used in MTLS.  The
   WIT MUST NOT be used as a bearer token.  While this helps reduce the
   sensitivity of the token it is still possible that a token and its
   proof of possession may be captured and replayed within the PoP's
   lifetime.  The following are some mitigations for the capture and
   reuse of the proof of possession (PoP):

   *  Preventing Eavesdropping and Interception with TLS

   An attacker observing or intercepting the communication channel can
   view the token and its proof of possession and attempt to replay it
   to gain an advantage.  In order to prevent this the token and proof
   of possession MUST be sent over a secure, server authenticated TLS
   connection unless a secure channel is provided by some other
   mechanisms.  Host name validation according to Section 5 MUST be
   performed.  The WIT itself is not usable without a proof of
   possession.

   *  Limiting Proof of Possession Lifespan

   The proof of possession MUST be time limited.  A PoP should only be
   valid over the time necessary for it to be successfully used for the
   purpose it is needed.  This will typically be on the order of
   minutes.  PoPs received outside their validity time MUST be rejected.

   *  Limiting Proof of Possession Scope

   In order to reduce the risk of theft and replay the PoP should have a
   limited scope.  For example, a PoP may be targeted for use with a
   specific workload and even a specific transaction to reduce the
   impact of a stolen PoP.  In some cases a workload may wish to reuse a
   PoP for a period of time or have it accepted by multiple target
   workloads.  A careful analysis is warranted to understand the impacts
   to the system if a PoP is disclosed allowing it to be presented by an
   attacker along with a captured WIT.

   *  Binding to a Timestamp or Nonce

   A proof of possession should include information that can be used to
   uniquely identify it such as a unique timestamp or nonce.  This can
   be used by the receiver to perform basic replay protection against
   tokens it has already seen.  Depending upon the design of the system

Campbell, et al.          Expires 21 April 2025                [Page 20]
Internet-Draft               WIMSE S2S Auth                 October 2024

   it may be difficult to synchronize the replay cache across all token
   validators.  In this case, if the PoP is not sufficiently scoped it
   may be usable with another workload.  While a fresh nonce could be
   included in the PoP, a mechanism for distributing a fresh challenge
   nonce from the validator to provide single use properties of a PoP is
   outside the scope of this specification.

   *  Binding to TLS Endpoint

   The POP MAY be bound to a transport layer sender such as the client
   identity of a TLS session or TLS channel binding parameters.  The
   mechanisms for binding are outside the scope of this specification.

6.3.  Middle Boxes

   In some deployments the WIMSE token and proof of possession may pass
   through multiple systems.  The communication between the systems is
   over TLS, but the token and PoP are available in the clear at each
   intermediary.  While the intermediary cannot modify the token or the
   information within the PoP they can attempt to capture and replay the
   token or modify the data not protected by the PoP.  Mitigations
   listed in the previous section can be used to provide some protection
   from middle boxes.  Deployments should perform analysis on their
   situation to determine if it is appropriate to trust and allow
   traffic to pass through a middle box.

6.4.  Privacy Considerations

   WITs and the proofs of possession may contain private information
   such as user names or other identities.  Care should be taken to
   prevent the disclosure of this information.  The use of TLS helps
   protect the privacy of WITs and proofs of possession.

   WITs and certificates with WIMSE identifiers are typically associated
   with a workload and not a specific user, however in some deployments
   the workload may be associated directly to a user.  While these are
   exceptional cases a deployment should evaluate if the disclosure of
   WITs or certificates can be used to track a user.

7.  IANA Considerations

   TODO: maybe a URI Scheme registration of wimse in URI schemes
   (https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml) per
   [RFC7595] but it's only being used in an example right now and might
   not even be appropriate.  Or maybe use an ietf URI scheme a la URN
   Namespace for IETF Use (https://www.iana.org/assignments/params/
   params.xhtml) somehow.  Or maybe nothing.  Or maybe something else.

Campbell, et al.          Expires 21 April 2025                [Page 21]
Internet-Draft               WIMSE S2S Auth                 October 2024

   TODO: tth, wth and maybe oth claim in JSON Web Token Claims Registry
   (https://www.iana.org/assignments/jwt/jwt.xhtml)

7.1.  Media Type Registration

   TODO: application/wimse-id+jwt or appropriately bikeshedded media
   type name (despite my ongoing unease with using media types for
   typing JWTs) in Media Types (https://www.iana.org/assignments/media-
   types/media-types.xhtml).

   TODO: application/wimse-proof+jwt ...

7.2.  Hypertext Transfer Protocol (HTTP) Field Name Registration

   TODO: Workload-Identity-Token from Section 4.1.1

   TODO: Workload-Proof-Token from Section 4.2

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/rfc/rfc3986>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <https://www.rfc-editor.org/rfc/rfc5234>.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/rfc/rfc5280>.

   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
              Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
              2015, <https://www.rfc-editor.org/rfc/rfc7515>.

Campbell, et al.          Expires 21 April 2025                [Page 22]
Internet-Draft               WIMSE S2S Auth                 October 2024

   [RFC7517]  Jones, M., "JSON Web Key (JWK)", RFC 7517,
              DOI 10.17487/RFC7517, May 2015,
              <https://www.rfc-editor.org/rfc/rfc7517>.

   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
              <https://www.rfc-editor.org/rfc/rfc7519>.

   [RFC7800]  Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-
              Possession Key Semantics for JSON Web Tokens (JWTs)",
              RFC 7800, DOI 10.17487/RFC7800, April 2016,
              <https://www.rfc-editor.org/rfc/rfc7800>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC8725]  Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best
              Current Practices", BCP 225, RFC 8725,
              DOI 10.17487/RFC8725, February 2020,
              <https://www.rfc-editor.org/rfc/rfc8725>.

   [RFC9110]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "HTTP Semantics", STD 97, RFC 9110,
              DOI 10.17487/RFC9110, June 2022,
              <https://www.rfc-editor.org/rfc/rfc9110>.

   [RFC9421]  Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP
              Message Signatures", RFC 9421, DOI 10.17487/RFC9421,
              February 2024, <https://www.rfc-editor.org/rfc/rfc9421>.

   [RFC9525]  Saint-Andre, P. and R. Salz, "Service Identity in TLS",
              RFC 9525, DOI 10.17487/RFC9525, November 2023,
              <https://www.rfc-editor.org/rfc/rfc9525>.

8.2.  Informative References

   [I-D.ietf-oauth-transaction-tokens]
              Tulshibagwale, A., Fletcher, G., and P. Kasselman,
              "Transaction Tokens", Work in Progress, Internet-Draft,
              draft-ietf-oauth-transaction-tokens-03, 3 July 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
              transaction-tokens-03>.

   [I-D.ietf-wimse-arch]
              Salowey, J. A., Rosomakho, Y., and H. Tschofenig,
              "Workload Identity in a Multi System Environment (WIMSE)
              Architecture", Work in Progress, Internet-Draft, draft-

Campbell, et al.          Expires 21 April 2025                [Page 23]
Internet-Draft               WIMSE S2S Auth                 October 2024

              ietf-wimse-arch-01, 8 July 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
              arch-01>.

   [IANA.JOSE.ALGS]
              IANA, "JSON Web Signature and Encryption Algorithms",
              <https://www.iana.org/assignments/jose>.

   [RFC7595]  Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines
              and Registration Procedures for URI Schemes", BCP 35,
              RFC 7595, DOI 10.17487/RFC7595, June 2015,
              <https://www.rfc-editor.org/rfc/rfc7595>.

   [RFC9449]  Fett, D., Campbell, B., Bradley, J., Lodderstedt, T.,
              Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of
              Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449,
              September 2023, <https://www.rfc-editor.org/rfc/rfc9449>.

Appendix A.  Document History

   // RFC Editor: please remove before publication.

A.1.  draft-ietf-wimse-s2s-protocol-01

   *  Addressed multiple comments from Pieter.

   *  Clarified WIMSE identity concepts, specifically "trust domain" and
      "workload identifier".

   *  Much more detail around mTLS, including some normative language.

   *  WIT (the identity token) is now included in the WPT proof of
      possession.

   *  Added a section comparing the DPoP-inspired app-level security
      option to the Message Signature-based alternative.

A.2.  draft-ietf-wimse-s2s-protocol-00

   *  Initial WG draft, an exact copy of draft-sheffer-wimse-s2s-
      protocol-00

   *  Added this document history section

Campbell, et al.          Expires 21 April 2025                [Page 24]
Internet-Draft               WIMSE S2S Auth                 October 2024

Acknowledgments

   // TODO acknowledge.

Authors' Addresses

   Brian Campbell
   Ping Identity
   Email: bcampbell@pingidentity.com

   Daniel Feldman
   Independent
   Email: dfeldman.mn@gmail.com

   Joe Salowey
   Venafi
   Email: joe.salowey@gmail.com

   Arndt Schwenkschuster
   SPIRL
   Email: arndts.ietf@gmail.com

   Yaron Sheffer
   Intuit
   Email: yaronf.ietf@gmail.com

Campbell, et al.          Expires 21 April 2025                [Page 25]