**Session Date/Time:** 14 Jan 2025 16:00

# [WIMSE](../wg/wimse.html)

## Summary

The WIMSE interim meeting on January 2025 focused on the latest revision (01) of the WIMSE Architecture document. Editors presented new content, particularly the "Scenarios" section, designed to bring concrete examples to the architecture. Discussions revolved around defining workload identity, the role of context and token services, cross-domain interactions, and the Gateway service. The meeting also introduced preliminary thoughts on how remote attestation models fit into the WIMSE architecture. Participants provided valuable feedback, leading to several action items for the document editors.

## Key Discussion Points

*   **IETF Note Well:** Participants were reminded of the IETF Note Well regarding contributions.
*   **WIMSE Architecture Draft (Revision 01) Updates:**
    *   The primary new content is the "Scenarios" section, aiming to illustrate common workload interactions and how other WIMSE work items (e.g., service-to-service authentication, token exchange) fit into the architecture.
    *   **Scenario 1: Basic Workload Interaction:**
        *   **Workload Definition:** Discussion on whether a "workload" refers to a single running instance or a logical service composed of multiple instances (Fleming). Joe Salaway suggested distinguishing between an "authorization identity" (for a service) and an "instance identity" (for a single running instance).
        *   **Confidential Computing (CC):** Mark emphasized ensuring compatibility with CC, where both client and server can be attested, and software versions might matter. He noted the role of a Gateway in protecting data transit/trust in CC environments.
        *   **WIMSE Identity Scope:** Yaroslav cautioned against letting CC define the core WIMSE architecture, suggesting Whimsy define one level of identity/identifier with clear properties, avoiding deep dives into CC-specific complexities.
        *   **Terminology:** Peter encouraged using "identifier" or "credential" instead of the broad term "identity" to avoid philosophical debates and focus on concrete artifacts.
    *   **Scenario 2: Context:**
        *   Introduction of a "Context Service" (also referred to as token service or authentication service) that validates external access tokens and generates internal "context tokens" (e.g., transaction tokens as defined in the OAuth working group) for internal application use.
        *   Fleming requested more concrete examples and descriptions of the "Context Service" in the document.
        *   Peter suggested framing the "Context Service" as a general concept, with "Transaction Tokens" as a specific example.
        *   Andrew proposed "posture assessment" as another potential function of a context service, augmenting context passed between workloads.
        *   Joseph raised the question of the lifespan of context tokens vs. transaction tokens, and how WIMSE will address asynchronous processes or autonomous agents that might require long-lived or renewed contexts.
    *   **Scenario 3: Cross-Domain Access:**
        *   Discussed workloads needing to interact with external infrastructure (e.g., cloud services) across different trust boundaries.
        *   A "Token Service" is introduced for obtaining credentials (access tokens) for external services.
        *   The relationship and distinction between this "Token Service" and the "Context Service" need clarification.
        *   Kelly Bergen (co-author of the "identity chaining" draft) noted the relevance of that work.
        *   Michael questioned the security implications of an *internal* token service providing authorization for *external* services, especially if internal tokens are exposed.
        *   Peter suggested leveraging language and concepts from the "identity chaining" draft for consistency.
    *   **Gateway Service:**
        *   Yaroslav introduced the concept of an "Identity Gateway" or "Gateway Service" in the WIMSE architecture.
        *   Its properties include: translation between trust domains, establishing and propagating security context, access control filtering, and identity-aware routing.
        *   Feedback was requested on the definition and properties of this service.
    *   **Remote Attestation (Hannes):**
        *   Hannes presented an overview of remote attestation models, noting this text is not yet in the document and seeking group feedback.
        *   **Model 1 (Agent-based):** A separate agent relays "evidence" (from hardware/software layers) to a "credential issuer," which verifies it and issues credentials back to the agent for the workload.
        *   **Model 2 (Confidential Container approach):** The workload itself (with an internal shim layer) obtains evidence and directly interacts with the credential issuer for verification and credential issuance.
        *   The discussion explored the usefulness of describing these models in the architecture document to provide context without going into excessive detail.

## Decisions and Action Items

*   **Editors (Joe Salaway, Hannes Tschofenig, Yaroslav Pchelintsev):**
    *   Refine the definition of "workload" in the architecture document to explicitly distinguish between service/authorization identity and instance identity.
    *   Enhance the description of the "Context Service" in the document, providing more concrete examples and clarifying its relationship with "Transaction Tokens" (possibly referencing the OAuth Transaction Tokens specification).
    *   Clarify the distinction between the "Context Service" and the "Token Service" used for cross-domain access.
    *   Investigate and potentially incorporate language and concepts from the "identity chaining" draft to enhance the "Cross-Domain Access" scenario.
    *   Seek further feedback on the definition and properties of the "Gateway Service" to ensure consistency in terminology (e.g., "Identity Gateway," "Identity Proxy," "Gateway Service").
    *   Draft text for inclusion in the architecture document describing common remote attestation models (e.g., agent-based vs. confidential container approach) to provide architectural context.
*   **Mark (Confidential Computing Consortium):** Raise specific conflicts or integration points between confidential computing and the WIMSE architecture as GitHub issues for the document.
*   **All Participants:**
    *   Review the current working group documents (WIMSE Architecture, Service-to-Service Authentication, Workload Identity Practices).
    *   File issues and provide comments on GitHub and the mailing list.
    *   Consider contributing new drafts for consideration at IETF 122.
    *   Continue discussions on GitHub and the WIMSE mailing list.

## Next Steps

*   Continued asynchronous discussions on the WIMSE mailing list and GitHub issues.
*   The next scheduled meeting for the WIMSE Working Group will be at IETF 122 in Bangkok.