ilpanich / axiam-kotlin-sdk / 34778539575

94%

push

github

feat(pki,webauthn): sign-csr certificates and passkey-first-login setup (F-1) (#63)

Kotlin's share of F-1 (mfa-first-login-and-csr-issuance-plan.md §9): the
mechanical half of C-1 and the mirrored half of M-3, against contract 1.45.

Re-vendors CONTRACT.md, openapi.json, management-registry.json and proto/
from ilpanich/axiam@3d5b279 (proto/ unchanged).

C-1 — certificates().signCsr(...). Regenerated by scripts/gen_management.py,
which already emits SignCertificateCsrRequest, so nothing was hand-written
there. Its response is the existing Certificate model, never
GeneratedCertificate, per §27.5's new sentence; a reflection-based
round-trip test in ManagementSemanticsTest asserts the decoded type carries
no private-key field at all, contrasted against GeneratedCertificate's
mandatory one. Management surface 159 -> 160 operations, picked up
automatically by the generated surface test.

M-3 — webauthnSetupRegisterStart/Finish, the WebAuthn twin of
mfaSetupEnroll/mfaSetupConfirm: a passkey or security key as the first
factor at forced first-login enrolment, from the same setup_token a login()
answering mfaSetupRequired hands back. Per §24.1, this pair takes no
session at all, and unlike webauthnRegisterStart/Finish the SDK must
actively withhold its own session credentials even when one is configured.

That turned out to need two interceptors, not one, and the first attempt
was wrong: AuthHeaderInterceptor's existing per-request marker skips the
bearer token cleanly, but OkHttp's BridgeInterceptor applies the shared
cookie jar to a request's Cookie header unconditionally whenever the jar
holds any for the URL, overwriting anything set upstream -- including an
explicit empty value. The WebauthnTest asserting this on the transport
caught it immediately: the first, request-only version leaked the prior
session's cookies straight through. The fix is a second interceptor,
NoSessionCredentialsNetworkInterceptor, registered as an OkHttp *network*
interceptor so... (continued)

1847 of 2219 branches covered (83.24%)

Branch coverage included in aggregate %.

5183 of 5271 relevant lines covered (98.33%)

6.52 hits per line