]> Alibaba Cloud

Building 9, Block 4, Wangjing East Park Beijing Bejing 100102 China max.ldp@alibaba-inc.com

Alibaba Cloud

Building 9, Block 4, Wangjing East Park Beijing Bejing 100102 China xining.wxn@alibaba-inc.com

Alibaba Cloud

Building 9, Block 4, Wangjing East Park Beijing Bejing 100102 China weiyuan.yl@alibaba-inc.com

art WIMSE keyword This document specifies the system architecture, related processes, token structures, etc., for secure protection of Service-to-Service traffic using WIMSE tokens.

Introduction This document specifies the architecture, token format and related mechanism that uses wimse token for securing service-to-service traffic.

Requirements Language 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 when, and only when, they appear in all capitals, as shown here.

Use Cases and Scenario In cloud computing, there exists a type of scenario where one workload invokes another workload, forming a chain of invocation for the workload. In such a scenario, for the next workload, it is necessary to authenticate the identity of the previous invoker workload and the associated software and hardware runtime environment. A specific example is when an AI-enhanced application invokes a Large Language Model instance deployed on a public cloud, it needs to verify the software and hardware runtime environment of the Large Language Model instance. At the same time, this Large Language Model instance needs to further call and use the industry-specific data running on another workload. It then needs to authenticate the invoked Large Language Model instance and the workload of the AI-enhanced application. This forms an authentication chain with the workload invocation chain. This document specifies the system architecture, related processes, token structures, etc., for secure protection of Service-to-Service traffic using WIMSE tokens.

Overview As shown in Figure 1, the overall architecture is depicted. There are several roles in this scenario. * Cloud Service Provider The cloud service provider that provides cloud computing services to users, for example, public cloud service provider * Workload A running instance of software executing for a specific purpose. [reference: draft-salowey-wimse-arch-01] * Workload caller The entity that invokes a workload, could be another workload. * Attestation Service provider A provider that provide remote attestation services by executing remote attestation protocols, providing evidence of the hardware and software environment on which the cloud service provider runs workloads. * WIMSE Token Token that used for the authentication and securing service-to-service traffic in this workload chain invoking scenario.

Overview architecture

WIMSE Token Format

Token Format The WIMSE token has the following format: It includes several nested JWT structures. As defined by , the (Content Type) Header Parameter of a nested JWT should be set to "JWT". In a chained workload invocation scenario, the method for generating the JWT Token of the workload being called is: sign and encrypt the JWT Token of the calling workload and use it as the payload for the JWT Token of the workload that is being called.

Token Content The token includes the following claims:

• iss (Issuer Claim): The identity of the issuer.
• sub (Subject Claim): The subject of the token.
• aud (Audience Claim): The intended recipients of the token, which can be the identifier of the workload.
• exp (Expiration Time Claim): The expiration time, defining the validity period of the token.
• nbf (Not Before Claim): The time before which the token is not valid.
• iat (Issued At Claim): The time at which the token was issued.
• jti (JWT ID Claim): The unique identifier of the JWT.
• transaction_id: The transaction identifier, used to bind the token to a specific transaction.
• context: Context information, which can include user identity, platform attestation information etc.

The context field can contain various types of information, such as:

• User Identity: Information about the user performing the current operation, which can be a user ID, username, or other unique identifiers.
• Platform Attestation: Attestation information of the platform or system, such as runtime integrity check results. This may include the information of the Operating System/Hardware Software and also may include the service-account bound to the Pod, the version/source information of the container image used by the Pod.

To achieve interoperability across trust domains, it may be necessary to standardize the context field in different systems so that different service providers and consumers can understand and process this information.

Example of wimse token

Support for Cross-Trust Domains Federation: If working across multiple trust domains is required, SPIFFE federation or similar mechanisms can be implemented to securely share and verify tokens across domains.

Security Considerations TBD

IANA Considerations TBD

Security Considerations TBD

References Normative References Informative References

Acknowledgements TBD

Contributors TBD