📝 Docs / Security threat-model document and advisory process

[docJerem]

Context

ex_saml positions itself as the actively maintained, security-focused successor to Samly. That claim is stronger when the security model is written down: what threats the library defends against, where the trust boundary sits, and how security issues are reported and disclosed.

Goal

Publish a security boundary / threat-model document and a lightweight advisory process.

Proposed scope

• SECURITY.md (or docs/security_boundary.md):
  • Threat model: XXE / entity expansion, signature forgery, signature wrapping, key substitution via document-supplied KeyInfo, protocol violations (destination / audience / issuer / time), replay.
  • Trust boundary: signatures are verified against the configured IdP certificate fingerprints — never document-supplied KeyInfo (link to Core.Xml.Dsig / IdpData).
  • Explicit non-goals (e.g. OIDC/OAuth, IdP role).
  • Algorithm policy: accepted vs rejected signature/digest/encryption algorithms.
  • Coordinated disclosure contact + supported-versions table.
• An advisory template under docs/advisories/ for future CVE-style write-ups (root cause, impact, affected versions, fix).

Why

• Documents and makes auditable the protections already implemented (🔐 Security / Fix XXE, NotBefore validation, algorithm whitelist #12 XXE, RSA-SHA1 rejection, fingerprint-bound verification).
• Gives integrators a clear statement of guarantees and a reporting channel.
• Backs the project's security positioning with a concrete artifact.

Out of scope

• Code changes — this is documentation + process only.