IGUSDIDRegistrationMutation — registers (or refreshes) the device's USDID
binding (usdid_uuid, public key, fdid) server-side and caches the matching
x-meta-usdid HTTP header in MobileSession for byte-identical reuse on
every subsequent request until the next re-register.
Lives outside of simulation/ because this is not just app-mimicry traffic
— it is a load-bearing identity step that other flows depend on. Pre-login,
post-login, idle-session warmup, and any long-running automation should call
this before authenticating real client behavior at scale.
On a fresh device, EnsureUsdidIdentity generates the persistent EC P-256
keypair + USDID UUID and writes them to MobileDevice. Each call re-signs
a fresh JWS with the current iat (the real app does the same on cold start
and roughly every ~5 minutes thereafter).
Whether the request self-stamps depends on whether the device already has a
persisted USDID identity at call time:
Fresh install (no persisted identity — it is generated by this call):
the IGUSDIDRegistrationMutation request carries nox-meta-usdid.
448 fresh evidence: the registration request has the header absent and the
following requests (fdid sync, oauth, …) carry the value cached on success.
Warm start (identity persisted from an earlier registration): the app
builds a fresh header for this request's iat (ts = iat + 3598) and
self-stamps the registration request with it. 448 warm AVD evidence:
IGUSDIDRegistrationMutation is the only request in the dump carrying
x-meta-usdid, with ts = iat + 3598 of the same body. 429-class builds
always self-stamped, which is what that note used to describe.
Either way the cache is (re)filled on success, so follow-up requests carry the
value and a failed mutation never caches an unaccepted signature.
IGUSDIDRegistrationMutation— registers (or refreshes) the device's USDID binding(usdid_uuid, public key, fdid)server-side and caches the matchingx-meta-usdidHTTP header inMobileSessionfor byte-identical reuse on every subsequent request until the next re-register.Lives outside of
simulation/because this is not just app-mimicry traffic — it is a load-bearing identity step that other flows depend on. Pre-login, post-login, idle-session warmup, and any long-running automation should call this before authenticating real client behavior at scale.On a fresh device,
EnsureUsdidIdentitygenerates the persistent EC P-256 keypair + USDID UUID and writes them toMobileDevice. Each call re-signs a fresh JWS with the currentiat(the real app does the same on cold start and roughly every ~5 minutes thereafter).Whether the request self-stamps depends on whether the device already has a persisted USDID identity at call time:
IGUSDIDRegistrationMutationrequest carries nox-meta-usdid. 448 fresh evidence: the registration request has the header absent and the following requests (fdid sync, oauth, …) carry the value cached on success.iat(ts = iat + 3598) and self-stamps the registration request with it. 448 warm AVD evidence:IGUSDIDRegistrationMutationis the only request in the dump carryingx-meta-usdid, withts = iat + 3598of the same body. 429-class builds always self-stamped, which is what that note used to describe.Either way the cache is (re)filled on success, so follow-up requests carry the value and a failed mutation never caches an unaccepted signature.