Skip to main content

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

Yes

(Murray Kucherawy)

No Objection


Note: This ballot was opened for revision 00-00 and is now closed.

Ballot question: "Is this charter ready for external review?"

Éric Vyncke
No Objection
Comment (2024-02-12 for -00-01) Sent
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.
Roman Danyliw
(was Block) No Objection
Comment (2024-02-25 for -00-02) Sent
Thank you for the revised 00-02 text.
Murray Kucherawy Former IESG member
Yes
Yes (for -00-00) Not sent

                            
Paul Wouters Former IESG member
Yes
Yes (2024-02-15 for -00-01) Not sent
I do support Roman's discuss on trying to be a bit more specific to constrain the work area where possible
Erik Kline Former IESG member
No Objection
No Objection (2024-02-13 for -00-01) Sent
# 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"
Zaheduzzaman Sarker Former IESG member
No Objection
No Objection (2024-02-15 for -00-01) Sent
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.