WIMSE Interim

September 16, 2025

Workload to Workload Authentication

Arndt Presenting

Discussion of Application Layer Proof of Possession Choices - HTTP
Message Signatures vs. Workload Proof Token (WPT)

Brian Campbell Present WPT (pronounced Whip-It)

Yaron Presents HTTP message signatures

Yaron: the has been discussed by the working group, but the editors feel
we shoudl reopen it.

Arndt Presents trade-off slide

Justin: has anyone deployed WPT to other protocols?

Arndt: Unknown

Brian: Deployability to other protocols is believed to be true for WPT,
but it is conjecture because no implementations exist.

Brian: We've had both mechanisms from the beginning, the feedback from
WG to keep both groups, editors think that having one option would be
preferable. THat is why we are asking now.

Flemming: Desireable to only have one method, which one to prefer. Hold
off on deciding, get consensus on if we need only one.

Yaron: Supportive that developers should only have one option. Options
of extending WPT is risky in that it would increase document and code
complexity

Yaroslav: Thinks that there is room for all three.Extract one method for
later on when we do non-http. From application devleoper perspective
things are complex. Having an abstraction layer in implementation to
make multiple mechanisms easier. regarding TLS certificate, with TLS
certificates only once, other mechanisms require per-request.

Justin: As chair: Currently chartered ony for HTTP, other can be
considered focus http.
as participant: adding integrity protection is dififuclt and complex,
may not be best use of time attention and resournces

Pieter: Chair hat off: we will have use cases for both. Unusual to
specify that a credential can be used with only one protocol. (certs as
an example). which one you want is more about deployment environments
maybe this is a flase choice. Will have multiple adoptions inhibit or
promote adoption.

Arndt: Worry that pick http message signatures than people who use GRPC
orother mehcnaism will need to do something else. MTLS can provide
integrity protection.

Joe: If we go with WPT, we will have feature creep and need to have more
requirements that we need to add to that token, concerns me we'd be
going that way anyway. Yaroslav proposed: do HTTPSig with HTTP Now and
move WPT to another draft to work on other protocols.

Noah: vendor in this space, a lot of excitement about the WPT for the
additional use cases: GRPC and Messaging. Good to have WPT, SPIFFE
community would be interested in WPT for these cases and may progress it
separately

Pieter: What is keeping customers fromd oing WPT implementations?

Noah: Maturity thing, mismatched technology stacks, want to migrate to
something new if it's standardized

Justin: CHair note: we can publish deliverables in as many documents as
we choose.

Flemming: CLear distinction between the identity and the identity formal
vs. getting away from bearer token. One mechanism is good, if you go
with WPT you will have to address more concerns. The WPT may not salve
all problems either.

Pieter: Workload identity credential is what binds the key to the
workload. The WPT is one way to use that token

FLemming: the proof token is addressint he bearer token issue. THe WIT
will is the same in either case.

Pieter [participant]: like with x509, we don't prohibit which protocls
it will be used with; you're likely to pick one or the other

Flemming: Whether we have multiple mechanisms, the WIT stays the same

Pieter [participant]: yes

Yaron: more specific proposal in the table - HTTP message singatures in
this document. WPT in appendix as a possible solution for future
protocols. May be out of scope for charter, but we know it is important.
WPT as a proposal for other protocols.

Justin [participant]: having a normative WG opinion in appendix is
weird. We need to be careful about what it is that we are recommending.

Arndt: There is no implementaiton of WPT for non-HTTP protocols.
RFC7521, RFC7522, RFC7523 etc in OAUTH is an example of
different profiles for different protoocls (with a generic version in
one doc).

Pierter [partiicpant]: approach makes sense to me

Yaroslav: HTTP signature could apply to more than rest (graphql, etc)

Yaron: using "rest" loosely, to refer to synchronous HTTP

Joe: we have more experience with HTTP than with other protocols, WPT
looks like a good generic mechanism, but it could be that there's some
construct native to that protocol that we might extend other than WPT.
is this the cart before the horse?

Pieter [participant]: question for Yaron, if you'd keep everything in
one doc, why in appendix vs. content?

Yaron: Today we have 2 options for implementers. that is not ideal, the
point is to have only one choice for devleoper, but keep WPT around

JUstin: [participant]: we did not use JOSE for HTTP SIG because there
were mechanism in HTTP SIG because there were mechanisms in HTTP that
might be better. GRPC, KAFKA, might have a way to fufill the need better
than WPT.

Yaroslav: Agrees with Justin. another exmaple SSH, its has its own
certificate, key format, etc. May be more native way for SSH to embed
the use of hte WIT and POP

Brian: The design goal of the WPT was for HTTP and to provide sufficient
proof of possession for the request. It was and is intended to be
applied to HTTP.

Justin: [Chair] the authors and working group have a decision to make.
We can slice this as we wish, there is no one way to do this.

Pieter [Chair] heard cases for both mechanisms, desire to preserve
both mechanisms. different choices for documents. Single documents, two
document, three document(WIT, WPT, HTTPSig, and others (MTLS))

Justin: Please submit individual draft with the changes. Authors to show
what the SPlit looks like. Running code. Perhaps Hackathon topic.