CimdPolicy.php
Table of Contents
Classes
- CimdPolicy
- Whether, and on what terms, a `client_id` that is a URL is resolved by fetching the document
it names (T21.5, `draft-ietf-oauth-client-id-metadata-document`). # Why this is one nested
policy rather than nine fields Every field here is a term of a single decision — *do we
fetch a stranger's URL and make a client out of what comes back* — and none of them means
anything without [`Self::enabled`]. A tenant that states a CIMD posture states all of it; a
tenant that states none inherits its organization's whole posture rather than half of one,
which is the only merge that cannot produce a combination neither party wrote. # The two
fields that can widen, and the seven that cannot [`Self::enabled`] and [`Self::allow_http`]
are **ordered**: a tenant may turn either off but never on, exactly as
`dynamic_registration` may only move down its ladder. Everything else names *this tenant's*
domains or *this tenant's* bounds, and there is no sense in which one tenant's list of
trusted publishers is stricter than another's — the same argument [`OidcPolicy`] already
makes for `dcr_allowed_redirect_hosts`. # Every bound here is a security control
[`Self::max_metadata_bytes`], [`Self::min_cache_secs`] and [`Self::max_cache_secs`] are not
tuning knobs. They are, respectively, the ceiling on a read from an attacker-chosen URL, the
floor under how often that read may be repeated, and the ceiling on how long its result may
be trusted. Each is clamped again in code against the three constants above, so a settings
row written by hand cannot lift them.