Integrate MIAF and WFM identity profile SUPs

[matlec]

Description

Integrates the two voted MIAF SUPs into the normative specification:

• Margo Identity and Authorization Framework (Margo Identity and Authorization Framework (MIAF) specification-enhancements#38)
• WFM Identity Profile and Management Interface update (WFM Identity Profile specification-enhancements#58)

What changes

• Adds an Identity and Authorization section: the framework, the X.509-SVID profile, TLS/mTLS requirements, the trust bundle and discovery endpoints (with OpenAPI), the identity lifecycle and operator playbooks, the WFM Identity Profile, and security considerations.
• Reworks the Management Interface security model. mTLS with X.509-SVIDs replaces server-side TLS plus RFC 9421 payload signatures. The onboarding and certificate-download endpoints and the PayloadSignature scheme are removed.
• Drops {clientId} from every route. Caller identity now comes from the authenticated SPIFFE ID. Retained endpoints gain a 403 for local-policy denial and Cache-Control: private.
• Bumps the Workload Management OpenAPI to 3.1.0, which the mutualTLS scheme and nullable typing require.

Deliberate deviations from the SUPs

• Cryptography is broader and built for agility. ECDSA P-256 is the only mandatory-to-implement algorithm; ECDSA P-384 and Ed25519 are optional; RSA PKCS#1 v1.5 is allowed only for certificate and CSR signatures, for CA compatibility. The SUP fixed ECDSA P-256 plus RSA-PSS and banned PKCS#1 v1.5.
• TLS is pinned to RFC 9852 (TLS 1.3 default, TLS 1.2 only as a non-default fallback), and the spec spells out that the TLS 1.2 fallback exposes the client SPIFFE ID in the cleartext handshake. The SUP only required TLS 1.3 support.
• A WFM Client derives the WFM it expects from its own SVID path rather than from a separately configured target wfm-id, so there is no separate target-identifier config item (which simplifies configuration and operations).
• Adds hardening the SUPs left open: a trust-anchor rotation playbook, Bundle Map rollback protection via spiffe_sequence with fail-closed on an empty bundle, refresh driven by spiffe_refresh_hint, and RFC 9440 section 4 spoof-proofing for the forwarded Client-Cert header.
• Expands the security-considerations catalog past the SUP tables: MIS compromise, central key-custody concentration, Bundle substitution and rollback, an unreliable validator clock, TLS 1.2 handshake disclosure, forwarded-header injection, and profile-specific threats.

Issues Addressed

• Define Margo strategy for ecosystem identity and authorization #127
• Complete WFM client onboarding strategy following the MIAF SUP finalization #146

Change Type

Please select the relevant options:

• Fix (change that resolves an issue)
• New enhancement (change that adds specification content)
• Content edits (change that edits existing content)

Checklist

• I have read the CONTRIBUTING document.
• My changes adhere to the established patterns, and best practices.

[phil-abb]

Here's some preliminary feedback.

[FHatCSW]

Maybe would be good to mention if it pinned to a specific version. And how future versions are handled

[matlec]

Good point, this is already covered here.

[FHatCSW]

"Because a principal presents a single SVID bound to one signature algorithm" is technically imprecise. An SVID has:

• a subject public-key algorithm
• a CA certificate-signature algorithm

A MIAF profile could require the issuing CA to use the same algorithm family and parameters as the principal.

[matlec]

Agreed, the wording was imprecise and could mislead people reading the spec. I have reworded that paragraph so that it now covers the signature algorithm of each certificate in the chain and the public-key algorithm of the leaf key.

A MIAF profile could require the issuing CA to use the same algorithm family and parameters as the principal.

I'd rather not add this requirement. An enterprise root CA using RSA with leaf certificates using EC is a common enough pattern, so I'd be concerned to over-constrain here. We'll also need mixed chains for post quantum transition. The updated wording puts the responsibility on the operator. So if an operator wants to be on the safe side, they can always choose ECDSA P-256 with SHA-256 throughout the chain.

[FHatCSW]

Maybe not the complete chain but at least the Issuing CA of the SVID?

[matlec]

Mh, I'm not sure what that would buy us. Suppose we have an RSA root with an EC intermediate issuing EC leaf certificates. The verifier still needs RSA because the intermediate's certificate is signed with the root's RSA key. The set of algorithms the verifier must implement doesn't shrink. Meanwhile the constraint would tie the issuing CA's key to the leaf's algorithm family. So I'd leave this as operator guidance.