Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Propose to add one use case of security context establishment and propagation #35

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
35 changes: 35 additions & 0 deletions draft-ietf-wimse-arch.md
Original file line number Diff line number Diff line change
Expand Up @@ -200,6 +200,41 @@ take place across intermediate workloads (in an end-to-end style).

In a typical system of workloads additional information is needed in order for the workload to perform its function. For example, it is common for a workload to require information about a user or other entity that originated the request. Other types of information may include information about the hardware or software that the workload is running or information about what processing and validation has already been done to the request. This type of information is part of the security context that the workload uses during authorization, accounting and auditing. This context is propagated and possibly augmented from workload to workload using tokens. Workload identity comes into play to ensure that the information in the context can only be used by an authorized workload and that the context information originated from an authorized workload.

One example of security context establishment and propagation is as follows:

~~~aasvg
┌───────────────────────────────────────────────────────────┐
│ │
│ ┌───────────────────┐ ┌──────────────────┐ │
│ │ -Identity 1 │ │ -Identity 1 + 2 │ │
│ │ -Security Context│ │ -Security Context│ │
│ └──────────┬────────┘ └────┬─────────────┘ │
│ │ │ │
│ ┌──────────┐ ▼ ┌──────────┐ ▼ ┌──────────┐ │
│ │ Workload1├──────► Workload2├──────► Workload3│ │
│ └─────▲────┘ └──────────┘ └──────────┘ │
│ │ │
│ │Attestation │
│ │ │
├──────────▼────────────────────────────────────────────────┤
│ │
│ Platform: Host Operating System/Hardware Software │
└───────────────────────────────────────────────────────────┘
~~~~
{: #arch-chain title="Security Context Establishment and Propagation"}

1. Workload 1 requests to load a service function within Workload 2. For example, the service function may be a LLM(Large Language Model) or a function to process PII information; Workload 2 requires that Workload 1 has hardware-based security (confidential computing) to prevent model or PII information leakage. The hardware-based security context information of Workload 1 can be obtained by running a remote attestation protocol. Workload 1 provides its Identity and the security context information to Workload 2 to apply for loading the service function.

3. Workload 2 verifies the Identity and corresponding security context information provided by Workload 1 to confirm whether the service function can be provided to Workload 1.

4. Workload 1 also requires the service function on Workload 2 to use the service function or data on Workload 3. For example, in the case of LLM, Workload 2 may required to load the vertical industry domain-specific data on Workload 3 for model fine-tuning.

6. Workload 2 provides its Identity, Workload 1’s Identity, and its hardware-based security context information to Workload 3.

7. Workload 3 uses this information for authentication and, upon passing, provides the required service function or data to Workload 2.



### Delegation and Impersonation

TBD.
Expand Down