



Workload Identity in Multi System Environments   A. Schwenkschuster, Ed.
Internet-Draft                                          Defakto Security
Intended status: Informational                           20 October 2025
Expires: 23 April 2026


                       WIMSE Credential Exchange
           draft-schwenkschuster-wimse-credential-exchange-03

Abstract

   WIMSE defines Workload Identity and its representation through
   credentials.  Typically, a credential is provisioned to the workload,
   allowing it to represent itself.  The credential format is usually
   chosen by the platform.  Common formats are JSON Web Tokens or X.509
   certificates.  However, workloads often encounter situations where a
   different identity or credential is required.

   This document describes various situations where a workload requires
   another credential.  It also outlines different ways this can be
   acchieved and compares them.

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-schwenkschuster-wimse-
   credential-exchange/.

   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/.

   Source for this draft and an issue tracker can be found at
   https://github.com/arndt-s.

Status of This Memo

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






Schwenkschuster           Expires 23 April 2026                 [Page 1]

Internet-Draft          WIMSE Credential Exchange           October 2025


   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 23 April 2026.

Copyright Notice

   Copyright (c) 2025 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.  Status  . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Static secrets  . . . . . . . . . . . . . . . . . . . . .   4
   3.  Mechanisms  . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Rationale . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  Change in format  . . . . . . . . . . . . . . . . . . . .   6
     4.2.  Change in scope . . . . . . . . . . . . . . . . . . . . .   7
     4.3.  Change in identity  . . . . . . . . . . . . . . . . . . .   8
     4.4.  Change in trust domain  . . . . . . . . . . . . . . . . .   9
     4.5.  Change in lifetime  . . . . . . . . . . . . . . . . . . .  10
     4.6.  Missing provisioning support  . . . . . . . . . . . . . .  11
     4.7.  Combinations  . . . . . . . . . . . . . . . . . . . . . .  12
   5.  Exchange patterns . . . . . . . . . . . . . . . . . . . . . .  12
     5.1.  Format-specific exchange  . . . . . . . . . . . . . . . .  12
     5.2.  On-behalf-of exchange . . . . . . . . . . . . . . . . . .  13
   6.  Consideration . . . . . . . . . . . . . . . . . . . . . . . .  14
     6.1.  Credential exchange cannot increase trust . . . . . . . .  15
     6.2.  Credential exchange cannot replace initial or platform
           provisioning  . . . . . . . . . . . . . . . . . . . . . .  15
     6.3.  Initial provisioning comes with over-provisioning risk  .  15



Schwenkschuster           Expires 23 April 2026                 [Page 2]

Internet-Draft          WIMSE Credential Exchange           October 2025


     6.4.  Expanding credential lifetime . . . . . . . . . . . . . .  16
     6.5.  Involvement of human, transactional or other contextual
           credentials . . . . . . . . . . . . . . . . . . . . . . .  16
     6.6.  Credential formats supporting offline attenuation . . . .  17
   7.  Conventions and Definitions . . . . . . . . . . . . . . . . .  17
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  17
     10.2.  Informative References . . . . . . . . . . . . . . . . .  18
   Appendix A.  Document History . . . . . . . . . . . . . . . . . .  18
     A.1.  draft-schwenkschuster-wimse-credential-exchange-03  . . .  18
     A.2.  draft-schwenkschuster-wimse-credential-exchange-02  . . .  18
     A.3.  draft-schwenkschuster-wimse-credential-exchange-01  . . .  18
     A.4.  draft-schwenkschuster-wimse-credential-exchange-00  . . .  19
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  19
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  19
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  19

1.  Status

   This work has been postponed for the time being due to a lack of
   interest on the part of the working group.  The authors and
   contributors believe this work to be more relevant in the future.  If
   you are interested in this work, please contact the contributors of
   this draft.

2.  Introduction

   Workloads operating across various platforms typically receive
   identity credentials in platform-specific formats such as JWT tokens,
   X509 certificates, Kubernetes Service Accounts Tokens, SPIFFE SVIDs,
   or cloud provider metadata documents.  These credentials, including
   their format, issuer, subject, and other attributes are determined by
   the platform infrastructure rather than the workload itself.

   When accessing external resources or other workloads, workloads must
   satisfy different authentication requirements specific to each
   resource they interact with.  Resource access might require OAuth 2.0
   Access Tokens, SPIFFE credentials, mutual TLS client certificates, or
   other authentication mechanisms that the workload cannot control or
   modify.

   This credential mismatch creates a fundamental challenge: workloads
   must bridge the gap between their platform-issued identity and the
   various authentication requirements of the resources they need to
   access.  Solutions typically involve credential exchange mechanisms
   or leveraging platform-specific functionality.



Schwenkschuster           Expires 23 April 2026                 [Page 3]

Internet-Draft          WIMSE Credential Exchange           October 2025


   This specification:

   *  Defines abstract mechanisms for credential delivery and exchange
      in Section 3

   *  Examines the rationale behind credential exchange requirements in
      Section 4

   *  Documents concrete implementation patterns based on these
      mechanisms in Section 5

2.1.  Static secrets

   Credential exchange is a broad term and can be interpreted in many
   ways.  This document focuses on the exchange of credentials that are
   issued to workloads on demand, such as JWTs, X.509 certificates, or
   other workload identity formats.  It does not cover the exchange of
   static secrets, such as API keys or client secrets, which are
   typically provisioned out-of-band and do not involve a dynamic
   exchange process.  This document rather sees static secrets as a
   special kind of resources that require strong authentication and
   authorization to access, but not as a credential exchange.

   Credentials returned as by this specification are:

   *  short-lived

   *  issued on demand, but potentially cached

   *  are individual based on the credential used to authenticate

   In contrast, static secrets are:

   *  medium to long-lived

   *  provisioned out-of-band, often manually

   *  do not differ based on authentication, different callers get
      access to the same credential

3.  Mechanisms

   Workloads have multiple options to acquire credentials in the way
   they are required.  The following terms divide them into four primary
   mechanisms and outlines their approaches:

   Initial manual provisioning




Schwenkschuster           Expires 23 April 2026                 [Page 4]

Internet-Draft          WIMSE Credential Exchange           October 2025


      Credentials are provisioned manually, often by an administrator.
      This is typically done out-of-band, such as through a
      configuration file, environment variable, or secret management
      system.  This mechanism is not recommended for workload identity
      credentials.  Within the document, this mechanism is not further
      discussed.

   Initial platform provisioning
      Credentials are issued during workload creation by the platform.
      The workload is "born" with them and they are available at
      startup.  The format, scope, lifetime and other attributes are
      configured out of band and cannot be influenced at runtime.  It is
      common that platforms allow only a single credential to be
      provisioned and only allow changes to scope.

   On-demand platform issuance
      Workloads are able to obtain credentials on-demand from the
      platform.  Parameters allow the workload to specify exactly the
      required format, scope, identity, lifetime, and other attributes
      the workload requires.  No authentication is necessary to request
      on-demand credentials.  The platform is able to strongly identify
      the workload so this request is typically unauthenticated from the
      workload's point of view.  Implementations may use the workload's
      initial provisioned credential in the background to authenticate
      the request, but this is not visible to the workload.

   On-demand credential exchange
      Workloads use an existing credential (provisioned manually or by
      the platform) to authenticate and authorize a request for a
      different credential.  Based on parameters, the workload can
      specify the exact attributes of the credential it requires.  The
      significant difference towards the on-demand platform issuance is
      that this is not necessarily within the platform and often an
      *authenticated* action.

   The outlined mechanisms are from the point of view of the workload.
   Specific mechanisms are often implemented by a combination of other
   mechanisms.  For example, a platform on-demand provisioning mechanism
   may use an initial provisioned credential in combination with a
   credential exchange to issue a new credential.  However, from the
   workload's perspective it is a platform on-demand provisioning
   mechanism, as it is not aware of the underlying implementation
   details.








Schwenkschuster           Expires 23 April 2026                 [Page 5]

Internet-Draft          WIMSE Credential Exchange           October 2025


4.  Rationale

   Workloads often require credentials that differ from the ones they
   were initially provisioned with.  This can be due to various reasons,
   such as changes in format, scope, identity, trust domain, or
   lifetime.  The need for credential exchange arises when the workload
   needs to adapt to these changing requirements.  The following
   sections outline the most common reasons for credential exchange,
   gives examples and provides recommendations for the mechanisms to
   use.

4.1.  Change in format

   Workloads may require a different format representing the same
   identity in the same trust domain.  Some concrete examples are:

   *  The initial credential was an X.509 certificate but resources
      require application-level authentication such as JWT or Workload
      Identity Tokens as defined in (TODO).

   *  The initial credential was a JWT bound to a key to be presented
      along with proof of possession, but the resource does not support
      it and requires a bearer credential.

   "Credential format" is difficult to define abstractly.  Some formats
   are opaque to the workload and should remain that way.  For instance,
   how an OAuth 2.0 Bearer token is constructed, and whether it carries
   claims or not, is not a concern of the workload.  That a bearer token
   is required, however, is known to the workload.  So a change in
   format between a bearer token and an X.509 certificate is certainly a
   change in format the workload can require.  A different encoding of a
   bearer token, on the other hand, is not and this specification does
   not address those cases.


















Schwenkschuster           Expires 23 April 2026                 [Page 6]

Internet-Draft          WIMSE Credential Exchange           October 2025


   +==============+================+===================================+
   | Mechanism    | Recommendation | Reason                            |
   +==============+================+===================================+
   | Initial      | Caution        | Risks preemptively issuing        |
   | platform     |                | credentials that aren't used.     |
   | provisioning |                | See security considerations       |
   |              |                | (Section 6.3) for details.        |
   +--------------+----------------+-----------------------------------+
   | On-demand    | Prefer         | Credentials are issued on a need  |
   | platform     |                | basis, allowing the workload to   |
   | issuance     |                | specify the format it requires &  |
   |              |                | keep lifetime short.              |
   +--------------+----------------+-----------------------------------+
   | On-demand    | Caution        | Requires an additional            |
   | credential   |                | credential to authenticate the    |
   | exchange     |                | exchange.  See security           |
   |              |                | considerations (Section 6.2) for  |
   |              |                | details.                          |
   +--------------+----------------+-----------------------------------+

                                  Table 1

4.2.  Change in scope

   A credential in the same format may represent the same identity, but
   is scoped differently.  Examples are:

   *  A JWT credential with an audience set to interact with the
      workload platform, but access to other workloads are required.
      The workload is in need of JWTs with different, dedicated
      audiences.

   *  An X.509 credential is constrained to a certain key usage, but the
      workload requires difference usage bits set.  For instance, the
      existing certificate allows for digitalSignature but
      keyEncipherment or dataEncipherment is required.

   Generally, scope should already be present and configured
   appropriately with the workload platform only issuing narrowly scoped
   credentials to the workload.  However, the platform may only support
   the provisioning of a single credential and doesn't allow custom
   scoping.









Schwenkschuster           Expires 23 April 2026                 [Page 7]

Internet-Draft          WIMSE Credential Exchange           October 2025


   +==============+================+==================================+
   | Mechanism    | Recommendation | Reason                           |
   +==============+================+==================================+
   | Initial      | Caution        | Risk of over-provisioning and    |
   | platform     |                | over-scoping.  Particularly when |
   | provisioning |                | different scopes are required    |
   |              |                | but initial provisioning only    |
   |              |                | allows a single credential.  See |
   |              |                | security considerations          |
   |              |                | (Section 6.3) for details.       |
   +--------------+----------------+----------------------------------+
   | On-demand    | Prefer         | Credentials are issued on a need |
   | platform     |                | basis and can be scoped to the   |
   | issuance     |                | exact requirements of the        |
   |              |                | workload.                        |
   +--------------+----------------+----------------------------------+
   | On-demand    | Caution        | Requires an additional           |
   | credential   |                | credential to authenticate the   |
   | exchange     |                | exchange.  See security          |
   |              |                | considerations (Section 6.2) for |
   |              |                | details.                         |
   +--------------+----------------+----------------------------------+

                                 Table 2

4.3.  Change in identity

   A workload may be known under multiple identities.  For example:

   *  A workload identity representing an exact physical instance of the
      workload may be eligible for a workload identity representing a
      logical unit that groups many physical instances together.
      Another example is a workload running in a specific region being
      eligible for a broader, geographically scoped identity.

   *  A workload that can act on behalf of other workloads.  These
      workloads often are part of infrastructure such as API gateways,
      proxies, or service meshes in container environments.













Schwenkschuster           Expires 23 April 2026                 [Page 8]

Internet-Draft          WIMSE Credential Exchange           October 2025


    +==============+================+================================+
    | Mechanism    | Recommendation | Reason                         |
    +==============+================+================================+
    | Initial      | Neutral.       | The authors believe that on-   |
    | platform     | Avoid for on-  | behalf-of should be an         |
    | provisioning | behalf-of      | explicit operation and not by  |
    |              | situations.    | default to avoid ambiguity and |
    |              |                | keep trust boundaries clear.   |
    +--------------+----------------+--------------------------------+
    | On-demand    | Prefer         | Credentials are issued on a    |
    | platform     |                | need basis and can be scoped   |
    | issuance     |                | to the exact requirements of   |
    |              |                | the workload.                  |
    +--------------+----------------+--------------------------------+
    | On-demand    | Prefer for on- | Requires an additional         |
    | credential   | behalf-of      | credential to authenticate the |
    | exchange     | situations.    | exchange.  See security        |
    |              |                | considerations (Section 6.2)   |
    |              |                | for details.                   |
    +--------------+----------------+--------------------------------+

                                 Table 3

4.4.  Change in trust domain

   A provisioned workload identity is often part of a trust domain that
   is coupled to infrastructure or deployment.  Workloads often interact
   with other workloads or access outside resources located in different
   trust domains.  This may require the client workload to retrieve an
   identity of the other trust domain.  Examples here include:

   *  Federation (a workload identity federates to a identity in a
      different trust domain).  In existing workload identity
      environment OAuth2 with Token Exchange (TODO) and Assertion
      framework (TODO) are popular.

   *  A workload requires a credential of "higher trust" to interact
      with other workloads.  This "higher trust" is facilitated by
      another trust domain.  For instance, a workload may require a
      WebPKI certificate to offer a service to clients with "default"
      trust stores.










Schwenkschuster           Expires 23 April 2026                 [Page 9]

Internet-Draft          WIMSE Credential Exchange           October 2025


    +==============+================+=================================+
    | Mechanism    | Recommendation | Reason                          |
    +==============+================+=================================+
    | Initial      | Avoid          | Initial provisioning is limited |
    | platform     |                | to the issuer of the workload   |
    | provisioning |                | platform.  Making initial       |
    |              |                | provisioned credentials multi-  |
    |              |                | issuer creates ambiguity.       |
    +--------------+----------------+---------------------------------+
    | On-demand    | Neutral        | See On-behalf-of exchange       |
    | platform     |                | pattern (Section 5.2) for a     |
    | issuance     |                | combination of on-demand        |
    |              |                | provisioning and exchange.      |
    +--------------+----------------+---------------------------------+
    | On-demand    | Prefer         | A change in trust domain        |
    | credential   |                | indicates a different issuer.   |
    | exchange     |                |                                 |
    +--------------+----------------+---------------------------------+

                                  Table 4

4.5.  Change in lifetime

   Credentials often come with time restrictions, or usage may be
   restricted based on token lifetime.  For instance:

   *  A resource denies the long-lived workload credential based on a
      maximum lifetime policy.

   *  An initial provisioned credentials has expired and renewal is
      unsupported.

   *  A credential with shorter lifetime would reduce replay risk.


















Schwenkschuster           Expires 23 April 2026                [Page 10]

Internet-Draft          WIMSE Credential Exchange           October 2025


    +==============+================+=================================+
    | Mechanism    | Recommendation | Reason                          |
    +==============+================+=================================+
    | Initial      | Caution        | Creates unnecessary long-lived  |
    | platform     |                | credentials that are difficult  |
    | provisioning |                | to protect.                     |
    +--------------+----------------+---------------------------------+
    | On-demand    | Prefer         | Individual lifetimes that fit   |
    | platform     |                | the exact need are possible.    |
    | issuance     |                |                                 |
    +--------------+----------------+---------------------------------+
    | On-demand    | Neutral        | May be used to reduce lifetime, |
    | credential   |                | but should be avoided to        |
    | exchange     |                | increase or expand lifetime as  |
    |              |                | a credential that expires later |
    |              |                | is effectively a higher trust.  |
    |              |                | See security considerations     |
    |              |                | (Section 6.1) for details.      |
    +--------------+----------------+---------------------------------+

                                  Table 5

4.6.  Missing provisioning support

   A workload platform may not support the provisioning of credentials
   required by the workload. would likely fall under the reasons above,
   but it's a very common reason and often falls into multiple
   categories.  As an example:

   *  Workload platform provisions identity and credential in the form
      of a simple signed document that carries the attributes attested
      by the platform, but gives not access in any way.



















Schwenkschuster           Expires 23 April 2026                [Page 11]

Internet-Draft          WIMSE Credential Exchange           October 2025


     +==============+================+==============================+
     | Mechanism    | Recommendation | Reason                       |
     +==============+================+==============================+
     | Initial      | -              | This section applies when    |
     | platform     |                | initial provisioning is not  |
     | provisioning |                | supported.                   |
     +--------------+----------------+------------------------------+
     | On-demand    | -              | This section applies when    |
     | platform     |                | on-demand provisioning is    |
     | issuance     |                | not supported.               |
     +--------------+----------------+------------------------------+
     | On-demand    | Neutral        | Credential exchange may be   |
     | credential   |                | used when no other mechanism |
     | exchange     |                | is supported or supports the |
     |              |                | desired outcome.  However,   |
     |              |                | credential exchange still    |
     |              |                | requires authentication.     |
     |              |                | See security considerations  |
     |              |                | (Section 6.2) for details.   |
     +--------------+----------------+------------------------------+

                                 Table 6

4.7.  Combinations

   Reasons for requesting or exchanging credentials are often not
   binary.  A change in trust domain is effectively a change in identity
   as well.  A change in format can require a change in trust domain,
   because formats come with different trust structures and security
   promises.  For example, a trust domain issuing JSON Web Tokens may
   not be able to issue WebPKI certificates.

5.  Exchange patterns

5.1.  Format-specific exchange

   The existing trust and identity framework often consist of a protocol
   or framework to exchange credentials.  Leveraging this makes use of
   existing adoption and specific guidelines.

   The following bullets give an overview of the existing patterns and
   when to use them based on the needs given above:

   *  OAuth Token Exchange [RFC8693] is:

      -  meant for a change in scope.

      -  meant for a change in identity.



Schwenkschuster           Expires 23 April 2026                [Page 12]

Internet-Draft          WIMSE Credential Exchange           October 2025


      -  to a certain extend meant for a change in format (limited).

      -  NOT meant for a change in trust domain.

   *  OAuth Assertion Framework [RFC7521] is:

      -  meant for a change in trust domain.  As a result of the change
         in trust domain, a change in identity, scope and, potentially,
         format is unavoidable but not the primary use case.

      -  NOT meant for exchanges within a trust domain.

5.2.  On-behalf-of exchange

   Workload environments can be highly dynamic and connected with a high
   variety of resources protected by different identity frameworks and
   formats.  A format-agnostic component that exchanges credentials on
   behalf of the workload may be desired to remain control of credential
   issuance.  For instance, it might enforce policy, collect audit
   trails, or aid management.

+-----------------+ 2)request     +------------------------+  4)request      +---------------------+
|                 |   credential  |                        |    credential   |                     |
|  Workload       +-------------->|  Credential Exchanger  +---------------->|  Credential issuer  |
|                 |               |                        |                 |                     |
+-------^---------+               +----------+-------------+                 +---------------------+
        |                                    |
  1) Provisioning                            |
        |                              3) validate
+-------v-----------------+                  |
|                         |                  |
|  Workload Platform      |<-----------------+
|                         |
+-------------------------+

   1.  The Workload Platform issues credential to the workload.  This
       can be either "initial", during workload startup or "on-demand",
       once the workload requires it.  See Section 3 for more details.

   2.  The Workload requests a new credential from the Credential
       Exchanger by specifying at least the issuer, format, and
       identity.  Potentially, it also specifies lifetime and scope.  It
       authenticates itself with the credential it has received from the
       Workload Platform.







Schwenkschuster           Expires 23 April 2026                [Page 13]

Internet-Draft          WIMSE Credential Exchange           October 2025


   3.  The Credential Exchanger validates the credential it receives.
       For simplicity, the diagram shows this as a interaction with the
       Workload Platform, but other means of validations are also
       possible.

   4.  The Credential Exchanger requests a credential from the
       Credential Issuer.  Also, for simplicity this step shows the
       interaction with a third party.  However, this may also be the
       Workload Platform itself.  Authentication and other step details
       depend on the scenario, format, and trust framework.

   The author believes that a specific protocol that fits all credential
   formats and trust frameworks is infeasible while maintaining the
   existing security promises.  He rather believes that a profile for
   each scenario is the best way forward and welcomes everyone to
   profile this document for their concrete use cases.  As a general
   guidance it is recommended to:

   *  narrowly scope the scenarios, instead of building a one-fits-all
      exchange for a specific format.

   *  decouple authentication and access control from the actual
      exchange as best as possible.  For example, a credential of one
      profile should be allowed as a means of authentication to exchange
      to a credential of a different profile, whether or not the
      profiles are aware of each other.

   *  allow the workload to specify at least issuer, identity and format
      when requesting a credential.  Lifetime and scope could be
      optionally specified, based on the need and support for it.

   *  keep multi-stepped issuance in mind.  Some formats and trust
      frameworks may require the workload to perform challenges, like
      responding to a nonce or providing a signature.

   The "Credential Exchanger" shown in the figure MAY be the Workload
   Platform itself that offers this capability.  It MAY be offered
   during a "re-provisioning" without authentication.

6.  Consideration











Schwenkschuster           Expires 23 April 2026                [Page 14]

Internet-Draft          WIMSE Credential Exchange           October 2025


6.1.  Credential exchange cannot increase trust

   A credential exchange is an authenticated method to retrieve
   credential(s).  Thus, the issued credential cannot be given a higher
   trust level than the credential that was used to authenticate the
   request.  This is particularly relevant when a required credential,
   due to its format and framework, is of a higher trust than the one
   that was used to authenticate the request.  This includes exchanging
   credentials without proof of key possession for credentials that do
   carry proof of possession.

   These situations are not recommended.  Workloads SHOULD be
   provisioned with the credential of the highest trust and only
   retrieve less-trusted credentials via credential exchange.

   Alternatively, the authentication request should be enriched with
   additional identification that increases the level of authentication.
   For example, along with authentication, the workload would provide
   additional proof of platform attestation.

6.2.  Credential exchange cannot replace initial or platform
      provisioning

   Because credential exchange is authenticated it cannot be the first
   credential that is issued.  Without an initial credential or a
   platform on-demand requested credential a workload cannot facilitate
   credential exchange, as there is no proof the workload is eligible
   for the requested credential.

6.3.  Initial provisioning comes with over-provisioning risk

   Provisioning credentials preemptively risks being exposed to
   overprovisioning credentials that are not required.  For example,
   with initial provisioning, every workload is provisioned with a
   default credential, even though some don't require it.  This
   unnecessarily increases the risk of those credentials being exposed.

   On-demand-based provisioning, on the other hand, only issues
   credential when requested and mitigates this.  They are exactly in
   the scope, format, identity and lifetime that are required.  This can
   significantly decrease the number of unnecessarily issued and
   provisioned credentials.









Schwenkschuster           Expires 23 April 2026                [Page 15]

Internet-Draft          WIMSE Credential Exchange           October 2025


6.4.  Expanding credential lifetime

   A change in lifetime of a credential can be critical if it can be
   used to effectively keep a credential alive.  One example is an
   issued short-lived bearer credential that can be used to exchange for
   a new, longer-lived credentials.  Thus, it is highly recommended to
   only use on-demand provisioning to re-request a new credential.

   On the other hand, it is valid to leverage token exchange to request
   a shorter-lived credential whose lifetime is within the bound of the
   credential used for authenticating the request.

   If an exchange to a longer-lived credential is required, it is
   recommended to prevent this from re-occurring and deploy policy to
   not allow a continuous exchange to longer-lived credentials.

6.5.  Involvement of human, transactional or other contextual
      credentials

   Although this document focuses heavily on workload identity,
   workloads often deal with other credentials carrying caller,
   transactional, or contextual information.  This could include an
   access token of the caller used to authorize the request. or an OAuth
   Transaction Token that was part of the request coming from another
   workload carrying transactional data.

   These credentials and their formats, lifetime, scope, etc. are not
   covered by this document.  However, they may be used as parameters or
   authentication to request additional credentials that combine
   multiple identities into a single credential.

   Some concrete examples are:

   *  An access token and a workload identity credentials are used to
      request an OAuth Transaction Token.

   *  An on-behalf-of scenario where a workload identity is used as
      actor, and a different, contextual credential unrepresentative of
      the workload is used as a subject in an OAuth Token Exchange.

   On-demand platform provisioning or credential exchange MAY be used to
   issue any of those contextual credentials to the workload.  Existing
   contextual credentials MAY be supplied as parameters.  Initial-based
   provisioning is not suitable with existing contextual credentials as
   it does not support parameters.  In situations where the workload's
   identity does not play a role and only the contextual credentials are
   used as authentication, credential exchange is the preferred
   mechanism.



Schwenkschuster           Expires 23 April 2026                [Page 16]

Internet-Draft          WIMSE Credential Exchange           October 2025


6.6.  Credential formats supporting offline attenuation

   Some credential formats allow the scope of the credential to be
   reduced offline, without interaction to an issuing party ("offline
   attenuation").  In these situations no exchange or on-demand
   provisioning is required and workloads can "act on their own."
   Examples of these formats are [Macaroons] or [Biscuit] tokens.  The
   provisioning of a credential that supports offline attenuation is
   still required in the first place.

7.  Conventions and Definitions

   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.

8.  Security Considerations

   TODO Security

9.  IANA Considerations

   This document has no IANA actions.

10.  References

10.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>.

   [RFC7521]  Campbell, B., Mortimore, C., Jones, M., and Y. Goland,
              "Assertion Framework for OAuth 2.0 Client Authentication
              and Authorization Grants", RFC 7521, DOI 10.17487/RFC7521,
              May 2015, <https://www.rfc-editor.org/rfc/rfc7521>.

   [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>.

   [RFC8693]  Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
              and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
              DOI 10.17487/RFC8693, January 2020,
              <https://www.rfc-editor.org/rfc/rfc8693>.



Schwenkschuster           Expires 23 April 2026                [Page 17]

Internet-Draft          WIMSE Credential Exchange           October 2025


10.2.  Informative References

   [Biscuit]  "Biscuit, a bearer token with offline attenuation and
              decentralized verification", n.d.,
              <https://doc.biscuitsec.org/reference/specifications>.

   [Macaroons]
              Birgisson, A., Politz, J. G., Erlingsson, U., Vrable, M.,
              and M. Lentczner, "Cookies with Contextual Caveats for
              Decentralized Authorization in the Cloud", 2014,
              <https://theory.stanford.edu/~ataly/Papers/macaroons.pdf>.

Appendix A.  Document History


   // RFC Editor: please remove before publication.

A.1.  draft-schwenkschuster-wimse-credential-exchange-03

   *  Add wording that this work is postponed

   *  Update affiliation

A.2.  draft-schwenkschuster-wimse-credential-exchange-02

   *  Rephrased introduction

   *  Added scope consideration for static secrets

   *  Moved to a 4-level mechanism classification, added manual,
      rephrased existing ones to make it more clear what is platform-
      based.

A.3.  draft-schwenkschuster-wimse-credential-exchange-01

   *  Fix typo that wrongly said OAuth2 assertion flow is not meant for
      inter-trust domain exchanges (meant was "intra").

   *  Rephrased X509 change of scope example to be more clear.

   *  Sharpened ways of provisioning, renamed "provisioning" to "initial
      provisioning" and "re-provisioning" to "on-demand provisioning".

   *  Add "Change in lifetime" need.

   *  Add considerations for the involvement of contextual,
      transactional and human credentials




Schwenkschuster           Expires 23 April 2026                [Page 18]

Internet-Draft          WIMSE Credential Exchange           October 2025


   *  Add consideration for credential formats supporting offline-
      attenuation.

   *  Describe "Credential Exchanger" pattern.

   *  Clean up for IETF 122.

A.4.  draft-schwenkschuster-wimse-credential-exchange-00

   *  Initial individual draft & write up.

Acknowledgments

   Big shoutout to the WIMSE token exchange design team (Dean Saxe,
   Yaroslav Rosomakho, Andrii Deinega, Dmitry Izumskiy, Ken McCracken
   and George Fletcher) that have done amazing groundlaying work in this
   area.

Contributors

   Ken McCracken
   Google


   Marcel Levy
   Defakto Security


   Andrew McCormick
   Aembit


Author's Address

   Arndt Schwenkschuster (editor)
   Defakto Security
   Email: arndts.ietf@gmail.com














Schwenkschuster           Expires 23 April 2026                [Page 19]
