[Feature]: Credential/auth model (tokens, proxies, delegation) #17

User Story

As a backend implementer and as the WMS consumer,
I want a decided credential model — how tokens and X.509 proxies are supplied to backends, renewed,
and scoped —
So that the ARC and HTCondor-CE backends can land without re-inventing DIRAC's setProxy/setToken
/Tag: Token conventions ad hoc.

Feature Description

A draft IC-ADR-003 now exists (docs/adr/IC-ADR-003_credentials.md, riding in PR #4 with the
other ADRs; this issue's implementation goes in a follow-up PR based on it): typed
immutable credentials (BearerToken/X509Proxy grouped in a CredentialSet), backend-declared
CredentialRequirements (kinds + audience + scopes — replaces Tag: Token[:vo] and
audienceName), and provider-based supply (CredentialProvider.get(requirements) — backend pulls
when near expiry; issuance/renewal policy stays consumer-side). This issue is: review/decide the
draft, then implement the intercede.auth types. The decision space it fixes:

• Supply: static credential objects vs a provider callback (today: caller calls
  setProxy/setToken before each cycle and inspects proxy.getRemainingSecs() itself —
  caller-driven renewal is the incumbent model and probably right for a stateless library).
• Declaration: how a backend/transport declares which credential kinds it accepts — replaces
  DIRAC's Tag: Token[:vo] CS hack as the opt-in signal.
• Audience/scoping: typed replacement for ce.audienceName (ARC: https://<ce>:<port>;
  HTCondor-CE: <ce>:9619) so the caller can mint correctly-scoped tokens.
• Materialisation helpers (Tier C): write-token-to-file, write-proxy-to-file +
  X509_USER_PROXY-style env injection for CLI-driven backends.
• ARC delegation (the hard case): create/sign/renew proxy delegations via CSR — decide whether
  this is ARCBackend-internal (Tier C) or a reusable piece.
• Boundary statement: payload credential renewal (DIRAC _monitorProxy) is pilot-side, out
  of scope — only backend auth is interCEde's.

Definition of Done

• IC-ADR-003 reviewed and merged (draft already written; Draft → Accepted path like
  ADR-001/002); its Open Issues (freshness margin, proxy representation/key material,
  multi-VO, per-operation requirements) dispositioned
• intercede.auth types (Tier A) implemented + unit-tested; consumed by the Transport
  protocol shape from #
• Token-vs-proxy selection expressible in backend config (registry request), no Tag strings
• Integration hook: ADR-002 auth config axis (config/token/ vs config/proxy/ per stack)
  named as the validation path

Alternatives Considered

• Backend-driven renewal (backend holds a refresh callback and renews itself) — moves policy into
  the library and needs long-lived state; contradicts the stateless design.
• Keep DIRAC's Tag: Token opt-in — stringly-typed, CS-coupled; rejected.

Additional Context

Evidence: SiteDirector._setCredentials (caller-driven renewal), WMSUtilities.setPilotCredentials
(same logic duplicated), AREX delegation machinery (_prepareDelegation/_renewDelegation),
HTCondorCE _CONDOR_* env-var token injection.