Workload Identity in Multi System Environments A. Schwenkschuster, Ed.
Internet-Draft SPIRL
Intended status: Informational 3 March 2025
Expires: 4 September 2025

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

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 4 September 2025 [Page 1]

Internet-Draft WIMSE Credential Exchange March 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 4 September 2025.

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
2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Change in format . . . . . . . . . . . . . . . . . . . . 3
2.2. Change in scope . . . . . . . . . . . . . . . . . . . . . 4
2.3. Change in identity . . . . . . . . . . . . . . . . . . . 4
2.4. Change in trust domain . . . . . . . . . . . . . . . . . 5
2.5. Change in lifetime . . . . . . . . . . . . . . . . . . . 5
2.6. Missing provisioning support . . . . . . . . . . . . . . 5
2.7. Combinations . . . . . . . . . . . . . . . . . . . . . . 6
3. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Exchange patterns . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Format-specific exchange . . . . . . . . . . . . . . . . 7
4.2. On-behalf-of exchange . . . . . . . . . . . . . . . . . . 8
5. Consideration . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Credential exchange cannot increase trust . . . . . . . . 9
5.2. Credential exchange cannot replace on-demand or initial
provisioning . . . . . . . . . . . . . . . . . . . . . . 10
5.3. Initial provisioning comes with over-provisioning risk . 10
5.4. Expanding credential lifetime . . . . . . . . . . . . . . 10

Schwenkschuster Expires 4 September 2025 [Page 2]

Internet-Draft WIMSE Credential Exchange March 2025

5.5. Involvement of human, transactional or other contextual
credentials . . . . . . . . . . . . . . . . . . . . . . . 11
5.6. Credential formats supporting offline attenuation . . . . 11
6. Conventions and Definitions . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Document History . . . . . . . . . . . . . . . . . . 13
A.1. draft-schwenkschuster-wimse-credential-exchange-01 . . . 13
A.2. draft-schwenkschuster-wimse-credential-exchange-00 . . . 13
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13

1. Introduction

Workload Identity credentials come in many forms. JSON Web Tokens
are popular but also X.509 certificates are commonly used. When a
workload is provisioned it can be assumed that it gets all of the
following

* an identity in the form of an identifier.

* one or multiple credentials that allow the workload to represent
itself (as that identity). Multiple credentials are often
different types but representing the same identity.

* an indication of trust domain. (TODO not sure)

Identity, credential and trust domain enable the workload to interact
within its environment, communicate to sibling workloads (same trust
domain), access APIs inside that trust domain, or provide an API
itself.

2. Rationale

There are many reasons for a credential exchange. The following list
highlights the most common reasons, and is not complete.

2.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 infrastructure
requires application-level authentication such as JWT or Workload
Identity Tokens as defined in (TODO).

Schwenkschuster Expires 4 September 2025 [Page 3]

Internet-Draft WIMSE Credential Exchange March 2025

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

"Credential format" is dificult to define abstractly. Some formats
are opaque to the workload and should remain that way. For instance,
how an OAuth 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.

2.2. Change in scope

A credential in the same format may represent the same identity,
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
approperately with the workload platform only issuing narrowly scoped
credentials to the workload.

In some situation the platform may only support the provisioning of a
single credential and not support scoping it. If those cannot be
requested by the platform itself an exchange may be necessary.

2.3. Change in identity

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

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

Schwenkschuster Expires 4 September 2025 [Page 4]

Internet-Draft WIMSE Credential Exchange March 2025

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

2.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 other
trust domains or reside in different trust domains. This requires
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.

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

2.6. Missing provisioning support

A workload platform may not support the provisioning of credentials
required by the workload. Technically, any of these 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 4 September 2025 [Page 5]

Internet-Draft WIMSE Credential Exchange March 2025

2.7. Combinations

Reasons for exchange 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.

3. Mechanisms

Workloads have multiple options to aquire credentials in the way they
are required. The following terms divides them into three primary
mechanisms:

Initial provisioning
Credentials are issued during workload creation. The workload is
"born" with them. These credentials are fixed and pre-defined,
often by configuration. The workload cannot influence their shape
during runtime. Configuration may be changed to adjust initial
provisioning.

On-demand provisioning
Workloads are able to obtain credentials on-demand. Parameters
allow the workload to specify exactly the required format, scope,
identity, lifetime, and other customization the workload requires.
No authentication is necessary to request on-demand credentials.
Workloads may choose to request additional on-demand credentials
based on its needs. (TODO may emphasize that this is
unauthenticated here)

Credential exchange
Workloads use a provisioned credential (on-demand or initial) to
authenticate and authorize a request of a different credential.
Based on parameters, the workload can specify the exact attributes
of the credential it requires. This is also on-demand, however,
the significant difference here is that this is an *authenticated*
action, compared to on-demand provisioning, which is
*unauthenticated.* Workloads may leverage credential exchange to
obtain credentials based on its needs.

Based on the exchange need, some mechanisms are more feasible and
better suited than others. The following table gives some guidance
based on the identified need. The security considerations below also
highlight some additional considerations, particularly Section 5.3.

Schwenkschuster Expires 4 September 2025 [Page 6]

Internet-Draft WIMSE Credential Exchange March 2025

Table 1

4. Exchange patterns

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

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

- NOT meant for a change in trust domain.

Schwenkschuster Expires 4 September 2025 [Page 7]

Internet-Draft WIMSE Credential Exchange March 2025

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

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

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.

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.

Schwenkschuster Expires 4 September 2025 [Page 8]

Internet-Draft WIMSE Credential Exchange March 2025

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 infeasable while
remaining(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 specificiation 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.

5. Consideration

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

Schwenkschuster Expires 4 September 2025 [Page 9]

Internet-Draft WIMSE Credential Exchange March 2025

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.

5.2. Credential exchange cannot replace on-demand or initial
provisioning

Because credential exchange is authenticated it cannot replace
provisioning. Without an initial or on-demand requested credential a
workload cannot facilitate credential exchange, as there is no proof
the workload is eligible for the requested credential.

5.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 provisioning, on the other hand, only issues credential
when requested and mitigates this. They are exactly in the scope,
format, identity and lifetime that is requires. This can
significantly decrease the number of unnecessarily issued and
provisioned credentials.

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

Schwenkschuster Expires 4 September 2025 [Page 10]

Internet-Draft WIMSE Credential Exchange March 2025

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

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

Schwenkschuster Expires 4 September 2025 [Page 11]

Internet-Draft WIMSE Credential Exchange March 2025

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

7. Security Considerations

TODO Security

8. IANA Considerations

This document has no IANA actions.

9. References

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

9.2. Informative References

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

Schwenkschuster Expires 4 September 2025 [Page 12]

Internet-Draft WIMSE Credential Exchange March 2025

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

* Add consideration for credential formats supporting offline-
attenuation.

* Describe "Credential Exchanger" pattern.

* Clean up for IETF 122.

A.2. 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.

Author's Address

Arndt Schwenkschuster (editor)
SPIRL

Schwenkschuster Expires 4 September 2025 [Page 13]

Internet-Draft WIMSE Credential Exchange March 2025

Email: arndts.ietf@gmail.com

Schwenkschuster Expires 4 September 2025 [Page 14]