[Wimse] Re: Request for Agenda Item: Workload identity authenticator levels

[Watson Ladd <[e-mail]>]

I am very confused and not following the conversation here.

The orchestrator definitionally authenticates workloads in the same
way that e.g. a PID on a kernel identifies a process. One cannot talk
about two PIDs being the same process (yes, yes linux threads, etc.)
or two processes having the same PID at the same time, because the
relevant data structures are indexed by PID. Conversely absent the
orchestrator being trusted there's no way to know what a workload
"is": it's just some process executing on a compute environment that
isn't trusted.

When it comes to workload A directly authenticating to workload B, why
not use strong crypto, per transaction? And if you have that, why do
you need differentiation? It's easy to do service auth that's strong!
There might be issues with chaining, but that's what the standards
effort here is to solve.

This is different from human authentication as humans cannot multiply
2048 bit numbers in their heads and thus have to make do with
passwords, ssh keys, etc. each with their own drawbacks and hence need
to talk about confidence in human to machine (and human to human:
medallion signature guarentees are a real thing!) authentication.

What's the usecase for weak auth in service to service?

Sincerely,
Watson Ladd