**Session Date/Time:** 07 Nov 2023 12:00

# wimse

## Summary

This "Birds of a Feather" (BoF) session explored the potential for IETF work on workload identity in multi-tenant environments (WIMSE).  The session included presentations on use cases, existing technologies like SPIFFE, and proposed solutions. A key focus was on identifying gaps in current standards and exploring potential new work items.  The discussion highlighted the need for a well-defined scope to prevent the BoF from becoming an unfocused collection of disparate ideas. The group took a poll about interest in the topic and contributing to the draft. There was not a clear consensus as to whether this effort should be AR or SEC area.

## Key Discussion Points

*   **The Challenge:**  Customers struggle to manage workload identities and implement zero-trust architectures across multiple cloud and service environments due to a lack of standardized identity systems.
*   **Leveraging Existing Standards:**  While many relevant standards and community projects (SPIFFE, MTLS, OAuth, OpenID Connect, RATS, Cedar) exist, gaps remain in connecting these ecosystems for workload identity.
*   **Request Binding:**  Challenges exist in securely retaining the original identity as requests are passed between workloads within a compute environment. Existing mechanisms like Depop do not fully cover the relevant threat model.
*   **Workload Definition:** Clear discussion that a workload is a specific piece of software fulfilling a particular purpose and may involve multiple copies of the same software.
*   **Use Cases:** Various use cases were presented including constrained credential security, cross-workload access, chain of custody of requests, localized authentication and authorization decisions, disconnected audit logs, and general requirements around observability and manageability.
*   **SPIFFE:** SPIFFE (Secure Production Identity Framework For Everyone) is a workload identity specification living in the CNCF, widely adopted for workload-to-workload authentication and identity. It does not however create new token types.
*   **Container Technologies:** Container technologies like Kubernetes and Docker employ specific mechanisms (e.g., "service account volume projection") for workload identity. Standardizing the usage and configuration of these mechanisms could improve interoperability.
*   **Token Containers:** A token container approach, treating the request as a graph rather than a linear flow, was proposed to accommodate multiple statements from different systems along the request path.
*   **Transparency Services:** Transparency logs, which are often found in supply chain contexts, can be used to further improve the security of nested token flows.
*   **Charter Scope:** Concern was raised that the proposed charter was too open-ended, potentially attracting irrelevant or previously rejected work. It was proposed that the charter be more tightly focused on specific initial work items.

## Decisions and Action Items

*   **Action Item:** Refine the charter to have a much more limited scope and list the specific deliverables, rather than being generally focused on all workload identity.
*   **Action Item:** Prioritize initial efforts on documenting existing architectures and developing best practices using existing technologies.
*   **Action Item:** Revisit the need for new standards work based on identified gaps, after a period of analysis and documentation.

## Next Steps

*   Continue discussions on the mailing list to refine the charter scope and initial work items.
*   Clarify the proposed architecture document's objective, focusing on documenting current deployment practices of technologies like Kubernetes and Docker.
*   Consider whether the initial focus should be on existing protocols vs. developing new mechanisms, which will help guide what IETF area is the most relevant.