Workload Identity in Multi System Environments
charter-ietf-wimse-01

[Ballot comment]
I take it that it's not accidental that the architecture document is to be delivered only *after* all the protocol documents that instantiate the architecture. It's a bold choice, but I can see it.

Added charter milestone "Submit a protocol as proposed standard for exchanging an incoming token of one format for a workload-specific token at security boundaries to the IESG", due November 2025

Added charter milestone "Submit a proposed standard for a token exchange profile mapping the JWT BCP [RFC9068] to the JOSE-based WIMSE token to the IESG", due March 2025

Added charter milestone "Submit proposed standard document specifying a token exchange profile that maps claims from SPIFFE-identified services to OAuth-protected resources, and vice versa to the IESG", due March 2025

Added charter milestone "Submit proposed standard for a JOSE-based WIMSE token solution to protect a chain of HTTP/REST calls for workloads to the IESG", due March 2025

[Ballot comment]
This charter is taking on very complex tasks - kudos. Looking at wider deployment of Kafka and gRPC, I am wondering if we can really put them aside from the beginning and hope a wide deployment of wimse protocol. The interoperability aspects are very crucial here, as both HTTP based and non-HTTP based technologies are in the goal of this charter. Has there been a concrete gap and feasibility analysis with existing non-http based technologies in use? If, yes then perhaps it is wiser to focus on the issues (and spelled out in the charter) that would be solved by the wimse protocol, giving a better chance for wimse to get deployed.
 
I am supporting Romans block. I also have similar comments as Romans {(3),(4),(5),(8)}, I think those should be addressed before going for external review.

[Ballot block]
** The text in the goals section appears to be extremely open ended.  How will the WG know it is done?  Is it possible to describe to describe a narrower initial tranche of work and recharter later?  Is the intent to have a long standing WG?  More specific are in the comments.

** If “non-HTTP transport protocols that are found in workload deployments, such as GraphQL, gRPC, and Kafka” is in scope, can the deliverables please be described.

[Ballot comment]
(3) Per the goal of “Identify and Advocate for Gap-filling Work: Engage with other relevant working groups to pinpoint and address gaps in current standards. This will involve thorough collaboration, ensuring that emerging standards are consistent, holistic, and interoperable.” Does this bullet imply new standardization activity?  What is the deliverable for "advocacy of gap-filling work"?

(4) Per “Engage with other relevant working groups to pinpoint and address gaps in current standards”, if this is in scope, what are the relevant WG and the gaps?  As the initial deliverables are currently described, no existing IETF WG appears to be built upon beyond JOSE and HTTP.  I observe that the charter says to coordinate with OAuth, SCIM and RATS.  What gaps in what standards of those WG is WIMSE focused on?

(5) Per the goal of “Initiate and develop new standards that provide the needed functionality and ensure their widespread adoption to address propagating, representing, and processing of workload identity”:

** what will the WG do to “ensure … widespread adoption”?  What’s the deliverable?

** what is “processing of workload identity”?

(6) Per the entire list of deliverables, there seems to be an implicit architecture of the solution but that isn’t sketched out anywhere.  See a few example of that below.

(7) Per the initial deliverable of “Securing service-to-service traffic”:
** Editorial. Expand “authn/authz”

** What is “strong identification of microservices …”?

** Is "within and across trust domains" effectively the internet then?

(8) Per the initial deliverable of “Token Issuance”:
** What is a “workload component”?

** Is this work describing a new protocol (i.e., what is a “method for issuance”)?  Does that protocol build on anything (e.g., is it HTTP-based?)?

** Is this the protocol for issuing the “JOSE-based token solution” described in the previous bullet?

** What’s the different between local and generic token issuance?

(9) Per the initial deliverable of a “Token exchange”
** What is the relationship between an incoming token and workload-specific tokens?

** Is the workload-specific token the "JOSE-based token solution" described earlier?

** Can the token formats which will be exchanged be described now?

(10) Per the initial deliverable of “Document existing local token distribution practices for workloads: An Informational deliverable describing the considerations and best practices for filesystem-based token delivery in Kubernetes.

** In my cursory review, the contents of draft-hofmann-wimse-workload-identity-bcp-00 don’t seem to match the description of this task.  The don’t seem to talk much about file-based token delivery.  It sketches protocol interaction (Figure 1) relying on OAuth. 

** This deliverable is framed as being “informational” status.  However, publishing informational status documents isn’t an obvious scope from the text is the goals section.

[Ballot comment]
# Internet AD comments for charter-ietf-wimse-00-01
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

* "will also consider deliverables that use non-HTTP transport protocols..."

  "... where such work shall not include authoring changes to non-IETF
  protocols" or something?

## Nits

* perhaps "least privilege" -> "least-privilege"

[Ballot comment]
Suggestion: provide references for `OAuth, JWT and SPIFFE` as well as `such as GraphQL, gRPC, and Kafka`.

It is unclear to me where this work will happen, in WIMSE or the other WGs ? `Engage with other relevant working groups to pinpoint and address gaps in current standards`.

Please indicate the intended status for "Securing service-to-service traffic" and token-related document(s); the other documents are clearly marked as informational.