# `AttestoPhoenix.Store.NonceStore`
[🔗](https://github.com/XukuLLC/attesto_phoenix/blob/v0.19.0/lib/attesto_phoenix/store/nonce_store.ex#L1)

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.

# `issue`

```elixir
@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`.

# `valid?`

```elixir
@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`.

---

*Consult [api-reference.md](api-reference.md) for complete listing*