Dispatch to the configured Attesto.DPoP.NonceStore, threading the live
request %AttestoPhoenix.Config{} to stores that need it (RFC 9449 §8).
The Attesto.DPoP.NonceStore behaviour (issue/1, valid?/1) carries no
config, so a persistent store such as AttestoPhoenix.Store.EctoNonceStore
would otherwise have to re-resolve its repo from a guessed :otp_app — which
fails for any host that configures AttestoPhoenix.Config under its own
application. The controllers and the token endpoint already hold the resolved
config, so this hands it straight to the store's config-aware entrypoints
(issue/2, valid?/2) when the store exports them, falling back to the
behaviour callbacks (issue/1, valid?/1) for config-free stores (e.g. the
bundled ETS store).
This is the single seam that keeps a nonce store from ever having to guess an otp_app: the DPoP paths pass the config they already resolved.
Summary
Functions
@spec issue(AttestoPhoenix.Config.t(), module()) :: String.t()
Mint a fresh nonce, passing config to a config-aware store (issue/2) and
falling back to the behaviour callback issue/1.
@spec valid?(AttestoPhoenix.Config.t(), module(), String.t()) :: boolean()
Report whether nonce is currently valid, passing config to a config-aware
store (valid?/2) and falling back to the behaviour's valid?/1.