issueChallenge

Issues a new attestation challenge using a nonce generated by nonceGenerator, valid for nonceValidity, and expecting an attestation proof to be HTTP POSTed to postEndpoint. The response is a signed CSR or unsigned TBS CSR according to dataAuth. It is possible, to pass a timeZone, but this is purely informational and is not fed into validity checks.

Specify keyConstraints to communicate to the type of key and its properties to the client, for automatic key creation. Defaults to defaultKeyConstraints. toBeAttestedAttributes requests ordered client-provided values; dataAuth determines how the resulting TBS CSR is authenticated. Both default to the verifier-wide settings and may be overridden per challenge.

Note that the inverse of Makoto.verificationTimeOffset is added to the nonce validity period to account for clock drift between clients and server. Why the inverse? Because clients check validity against their local clocks, reversing their relative view of the server time offset.

Note that the challengeValidator needs to account for this inverse view! The default InMemoryChallengeCache already does that.

The issued challenge nonce is sensitive replay-protection material. Treat it as a bearer value for the lifetime of the challenge: do not log it, do not expose it across sessions or callers, serve it only over protected transport, and keep caller/session binding and rate limiting in the surrounding HTTP layer if your service needs it.

Throws