Requirements Discussion

used primarily for authorization, maybe also for audit/accounting (not trying to solve complex audit problems)
Identity primarily identifies workload "type" within a domain/namespace
May also provide instance identifier, but this is not a primary focus
"string" with hierachy (at least including namespace) over "object" for now
URI over JSON
structure of namespace is out-of-scope (up to local deployment), may provide recommendations
focus on within trust domain, federation out-of-scope for now

Binding to a cryptographic key (not bearer tokens)
Binding to key over binding to identity bound to a key
Decision point: cnf claim in token carry key vs. claim that points to a key - start with key in token and add other later
Binding is not forgeable (cryptographically signed by authority) - probably public key based
Binding credential is issued by central authority, does not necessarily issue a key (we don't define all the details)
Key is at least scoped to workload identity (type), key may be more narrowly scoped (per instance) - deployment specific
Decision point: symmetric vs. asymmetric (choose one approach - asymmetric - to begin with, leave door open for symmetric in the future)

Accepting/verification credential require some proof of possession
Resilience to replay of verification(?) - replay of an observed exchange by an attacker to gain advantage
Resilience to loss of key
Decision Point - what is signed - HTTP Request/message signing vs. JWT/DPOPish - -- http message signing not widely implemented -- needs profiling
who needs to verify the pop - one downstream service? -
"message bus" mostly out of scope (message bus adapter will verify identity, how it propagates etc. is out of scope for now)

Identity cliam - URI
Key claim - cnf
Expiry claims
claims to restrict the "applicability" of the token - less necessary with key binding - but may still be useful

Protocol for getting binding credential is out of scope (this is handled by something like SPIFFE)

Provide feedback