[Wimse] Re: Fwd: New Version Notification for draft-schwenkschuster-s2s-protocol-00.txt

[Dag Sneeggen <[e-mail]>]

In my opinion we should consider taking a step back and a moment to pause. I feel that we might be losing sight of our goals: Strong trusted workload identity.

  1.
Workload authentication. IMO the best working implementation is SPIFFE SVIDs as either jwt or x509 certs. For instance, popular service meshes provides this, as does of course a SPIFFE/SPIRE implementation.
  2.
Workload authorization. The authorization context needs to be conveyed. Could be a bearer/access token, maybe a transaction token, or something similar. IMO the biggest win here is binding tokens to workload identity either with certificates using rfc8705, or some dpop-like (WPT) mechanism.
  3.
Secret sprawl is a huge problem that I think WIMSE should address in one way or another. The proliferation of long-lived and poorly managed secrets. There's many interesting drafts in the making now related to client authentication using various forms of token or attestation. I'm sure we're all quite aware of these.

Everything else for me is tangential at best, irrelevant at worst. We need to further sharpen the message of this document to make it more impactful.
For instance, for me the inclusion of HTTP message signing doesn't belong in a document declaring "the simplest, atomic unit of this architecture". Perhaps this could fit in a BCP-style document.

I think we need to be much clearer about what is the "simplest, atomic unit of WIMSE (s2s) architecture". Everything else that is useful and/or interesting can be placed in other documents.
In many ways I feel that the main "WIMSE architecture" document is much clearer in describing s2s communication, than the actual s2s document itself, which is probably not the best sign.

Regards,
Dag Sneeggen.
________________________________
From: Arndt Schwenkschuster <[e-mail]>
Sent: Tuesday, September 23, 2025 1:24:28 PM
To: [e-mail] <[e-mail]>
Subject: [Wimse] Fwd: New Version Notification for draft-schwenkschuster-s2s-protocol-00.txt

You don't often get email from [e-mail]. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
Dear Working Group,

as discussed in the last interim here is also an alternative proposal to give the presentation of Workload Identity a dedicated document (s2s-protocol) and create specific documents for protocol-level proof of key possession:

Workload Identity Presentation (Workload Identity Certificate & Workload Identity Token): https://datatracker.ietf.org/doc/draft-schwenkschuster-s2s-protocol/
Workload Proof Token Profile: https://datatracker.ietf.org/doc/draft-schwenkschuster-s2s-jwt-pop/
HTTP Message Signatures Profile: https://datatracker.ietf.org/doc/draft-schwenkschuster-s2s-http-sig/

I believe this creates a good level and focus on specific topics and allows for other protocols we don't anticipate at the moment. After thinking about it for a while I don't think that multiple options are a disadvantage as long as they don't overlap. This creates clear paths for implementers and SDK developers which profile to pick.

Curious to hear your thoughts.

Kind regards,
Arndt

---------- Forwarded message ---------
From: <[e-mail]<mailto:[e-mail]>>
Date: Tue, Sep 23, 2025 at 1:18 PM
Subject: New Version Notification for draft-schwenkschuster-s2s-protocol-00.txt
To: Arndt Schwenkschuster <[e-mail]<mailto:[e-mail]>>


A new version of Internet-Draft draft-schwenkschuster-s2s-protocol-00.txt has
been successfully submitted by Arndt Schwenkschuster and posted to the
IETF repository.

Name:     draft-schwenkschuster-s2s-protocol
Revision: 00
Title:    WIMSE Workload-to-Workload Authentication
Date:     2025-09-23
Group:    Individual Submission
Pages:    25
URL:      https://www.ietf.org/archive/id/draft-schwenkschuster-s2s-protocol-00.txt
Status:   https://datatracker.ietf.org/doc/draft-schwenkschuster-s2s-protocol/
HTML:     https://www.ietf.org/archive/id/draft-schwenkschuster-s2s-protocol-00.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-schwenkschuster-s2s-protocol


Abstract:

   The WIMSE architecture defines authentication and authorization for
   software workloads in a variety of runtime environments, from the
   most basic ones up to complex multi-service, multi-cloud, multi-
   tenant deployments.  This document defines the simplest, atomic unit
   of this architecture: the protocol between two workloads that need to
   verify each other's identity in order to communicate securely.  The
   scope of this protocol is a single HTTP request-and-response pair.
   To address the needs of different setups, we propose two protocols,
   one at the application level and one that makes use of trusted TLS
   transport.  These two protocols are compatible, in the sense that a
   single call chain can have some calls use one protocol and some use
   the other.  Workload A can call Workload B with mutual TLS
   authentication, while the next call from Workload B to Workload C
   would be authenticated at the application level.



The IETF Secretariat