| Internet-Draft | draft-lombardo-wimse-workload-identity-a | July 2025 |
| Lombardo, et al. | Expires 2 January 2026 | [Page] |
This document defines a framework for Machine Identity Assurance Levels (MIAL) and Machine Authentication Assurance Levels (MAAL) to establish consistent, verifiable trust in machine-to-machine communications.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://identitymonk.github.io/draft-lombardo-wimse-workload-identity-authentication-levels/draft-lombardo-wimse-workload-identity-authentication-levels.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-lombardo-wimse-workload-identity-authentication-levels/.¶
Discussion of this document takes place on the WIMSE 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/identitymonk/draft-lombardo-wimse-workload-identity-authentication-levels.¶
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 2 January 2026.¶
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.¶
With the increasing complexity of distributed systems, containerization, and cloud-native architectures, machine and workload identity has become a critical security cornerstone. While for human identity standards guidance such as [NIST.SP.800-63] provides comprehensive frameworks for human identity assurance and authentication, there is no equivalent standard for machine and workload identities.¶
This document defines a framework for Machine Identity Assurance Levels (MIAL) and Machine Authentication Assurance Levels (MAAL) to establish consistent, verifiable trust in machine-to-machine communications.¶
This standard addresses: - Machine identity proofing and verification requirements - Machine authentication mechanisms and protocols - Hardware-based security integration - Supply chain validation requirements - Runtime attestation and continuous verification - Cross-environment identity federation - Workload identity lifecycle management¶
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.¶
The following terms are defined for use in this document:¶
Machine Identity: A set of unique metadata and identifier associated with a hardware device, virtual machine, container, or workload.¶
Workload: A discrete computing task or application running in a distributed environment.¶
Attestation: The process of providing evidence about the state of a machine or workload.¶
Identity Proofing: The process of verifying the claimed identity of a machine or workload.¶
Authentication: The process of verifying the authenticity of a machine or workload identity.¶
The Machine Identity Assurance and Authentication Framework consists of two primary components:¶
MIAL defines the degree of confidence in the claimed identity of a machine or workload. This includes:¶
Identity attestation and proofing¶
Deployment environment (e.g. virtual machine, Kubernetes) verification¶
Software integrity verification¶
Configuration validation¶
Supply chain validation¶
Note that these levels do not require hardware security integration, but see Section 4.¶
There is no requirement to link a given machine or workload to an identity. Although an identity may be optionally provided, there is no process for identity attestation or proofing. Different machines or workloads cannot be definitively distinguished from each other.¶
Machines or workloads are authenticated solely by credential (e.g., API key). Credentials or keys are provided without any attestation. Different machines or workloads that present the same credential cannot be definitively distinguished from each other.¶
Machines or workloads are provided with identities via an attestation and proofing process that is rooted in the underlying deployment environment. These identities can be cryptographically authenticated by relying parties. Different machines or workloads can be definitively distinguished from each other via these identities.¶
In addition to the conditions in MIAL-3, the machines or workloads undergo software integrity verification, and configuration validation. This necessarily includes supply chain validation.¶
In addition to the conditions in MIAL-4, the underlying deployment environment undergoes some form of verification, appropriate to its implementation.¶
MAAL defines the strength of an authentication nechanism used by workload to authenticate. This includes:¶
This represents the level of trust in the authenticator.¶
This represents the requirements for the credential to exist.¶
This represents the constraints on how and where the credential can be stored.¶
This represents how the credential can be accessed for authentication purposes.¶
This represents the constraints on where the credential can be used.¶
This represents if and how one credential exist for more than one resource.¶
This represents the constraints on how the credential can be recoevered if somthing goes wrong.¶
This represents the rules that govern the credential lifecycle.¶
The workloads and machines in the Machine Identity Assurance Levels (MIAL) ultimately rely on the underlying deployment environment. In the case of deployment environment verification defined in MIAL-4, this is ideally rooted in hardware integrity techniques and devices, including but not limited to:¶
Public key infrastructure (PKI) using Hardware Security Modules (HSMs)¶
Trusted Platform Modules (TPMs)¶
Secure Enclaves¶
However, these techniques are not feasible across the range of deployment environments in common usage. Therefore, none of the MIALs require their use.¶
TODO Security¶
This document has no IANA actions.¶
The authors wants to acknowledge the support and work of the following indivisuals: Ryan Hurst (Peculiar Ventures), Pamela Dingle (Microsoft).¶
The authors wants also to recognize the trail blazers and thought leaders that created the ecosystem without which this draft proposal would not be able to solve customer pain points and secure usage of digital services, especially without being limited to: Vittorio Bertocci†, Brian Campbell (Ping Identity), Justin Richer (MongoDB), Aaron Parecki (Okta), Pieter Kasselman (SPIRL), Dr Mike Jones (Self-Issued Consulting, LLC), Dr Daniel Fett (Authlete).¶