[Wimse] Runtime costs of multiple signatures?

["McAdams, Darin" <[e-mail]>]

Really appreciate all the work that the design teams have put into the WIMSE proposals.

I’ve been reading the docs in preparation for the IETF meeting and encountered a question I hadn’t seen discussed. The examples in service-to-service tokens<https://www.sheffer.org/wimse-s2s/draft-sheffer-wimse-s2s-protocol.html> appear to require a total of 3 or more tokens to be validated. This includes an OAuth access_token, the workload identity token, and the proof-of-possession token. The proliferation of tokens will have an impact on both the “bloat overhead” of each HTTP request, as well as the CPU and latency cost of running 3 or more asymmetric cryptographic operations. Perhaps it’s because I live in a world where a million requests per seconds is normal, but I found myself asking: “What will this cost?”. Has there been any discussion of the runtime costs of these proposals? It might be OK, or it might not, I simply don’t know and am curious.

If this approach were pursued, audiences with efficiency concerns could raise additional questions such as: Is it acceptable to cache the validation results for a workload identity token so it’s not necessary to re-validate the same token on every HTTP request? Or, if a particular implementation has the means to do so, is it OK to distribute the token out of band so it’s not necessary to pass on every request?

One other thing I noticed is that Figure 12<https://www.sheffer.org/wimse-s2s/draft-sheffer-wimse-s2s-protocol.html#name-signed-request> in the HTTP Message Signature example doesn’t include an Authorization header with a bearer-token, as in the DPoP variation. I wasn’t sure if that’s because it’s unnecessary when using HTTP Message Signatures, or if this was simply a mistake in the example. I was trying to wrap my head around the pros-and-cons of each option, and whether one requires fewer signatures.

-Darin