IGUSDIDRegistrationMutation — registers 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. It returns nothing: the result is the cache and the
process's registration fact, not a value a caller acts on.
The device is registered at most once per process. This brick is the one
place that enforces it: it claims the process's registration slot before it
sends, so a call after an accepted answer sends nothing, a concurrent call
waits for the one in flight instead of sending a second request, and a
refused answer releases the slot for a later retry. The pre-login flow, the
cold start, the registration flow and the warm launch of a stored session all
call this brick, so no caller can register twice. A session a login created
here without the pre-login calls none of them and stays unregistered for the
process; that start is not observed.
Lives outside of simulation/ because this is not just app-mimicry traffic
— it is a load-bearing identity step that other flows depend on.
On a fresh device, EnsureUsdidIdentity generates the persistent EC P-256
keypair + USDID UUID and writes them to MobileDevice. The call that sends
re-signs a fresh JWS with the current iat; a call after this process
accepted a registration sends nothing.
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 request carries nox-meta-usdid, and the requests after an
accepted answer carry the value cached then.
Warm start (identity persisted from an earlier registration): the app
signs the request's value with the request's iat (ts = iat + 3598) and
self-stamps the registration with it, then signs again once the answer
is accepted, at that moment. The three values of one warm start — the
cached one, the self-stamp and the post-answer one — share the identity's
uuid and differ in their signature and ts.
The self-stamped value stays in the cache whatever the answer (the app signs
before sending); the process's registration fact is set only by an accepted
answer, so a refused registration is retried by the next caller. A fresh
install caches nothing until an answer is accepted. What the app does with a
refused self-stamp is not modelled.
IGUSDIDRegistrationMutation— registers 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. It returns nothing: the result is the cache and the process's registration fact, not a value a caller acts on.The device is registered at most once per process. This brick is the one place that enforces it: it claims the process's registration slot before it sends, so a call after an accepted answer sends nothing, a concurrent call waits for the one in flight instead of sending a second request, and a refused answer releases the slot for a later retry. The pre-login flow, the cold start, the registration flow and the warm launch of a stored session all call this brick, so no caller can register twice. A session a login created here without the pre-login calls none of them and stays unregistered for the process; that start is not observed.
Lives outside of
simulation/because this is not just app-mimicry traffic — it is a load-bearing identity step that other flows depend on.On a fresh device,
EnsureUsdidIdentitygenerates the persistent EC P-256 keypair + USDID UUID and writes them toMobileDevice. The call that sends re-signs a fresh JWS with the currentiat; a call after this process accepted a registration sends nothing.Whether the request self-stamps depends on whether the device already has a persisted USDID identity at call time:
x-meta-usdid, and the requests after an accepted answer carry the value cached then.iat(ts = iat + 3598) and self-stamps the registration with it, then signs again once the answer is accepted, at that moment. The three values of one warm start — the cached one, the self-stamp and the post-answer one — share the identity's uuid and differ in their signature andts.The self-stamped value stays in the cache whatever the answer (the app signs before sending); the process's registration fact is set only by an accepted answer, so a refused registration is retried by the next caller. A fresh install caches nothing until an answer is accepted. What the app does with a refused self-stamp is not modelled.