Initiate Cross-DUID Re-identification by MPxN
Initiates a re-identification flow against an existing Identity Record for the given MPxN, without exposing the ir key. Used when a Data User wants to create an Access Record linked to an Identity Record originally created by another Data User.
The register resolves the ir internally. The Data User never sees it. The customer is challenged via magic link or passkey — the challenge displays the initiating Data User’s name so the customer knows who is requesting access.
On successful customer completion, the returned token-ref is passed as reidentification-token in POST /access-records. The register validates the token is confirmed, single-use, and was initiated by the same Data User before linking the new Access Record to the existing Identity Record.
Security: Without customer completion of the re-identification ceremony, the token cannot be used. A Data User cannot manufacture a valid token or re-use one after consumption.
Authorizations
JWT from GET /auth/token. Pass as Authorization: Bearer <token>. Expires after 7200s.
Body
Meter Point Administration Number (MPAN) or Meter Point Reference Number (MPRN).
^(?:[0-9A-HJ-NPR-Z]{2}[0-9]{8,10}|[0-9]{10})$"1234567890123"
The re-identification method to use.
magic-link — single-step. The register dispatches a signed link to
the stored email address. Optionally supply redirect-url to send the
customer back to the Data User's app after clicking; otherwise the customer
lands on central.consent. Poll or check
GET /identity-records/{ir}/re-identify/{token-ref} to confirm.
passkey-assert — two-step redirect. The response contains a
passkey-redirect with a short-lived URL to id.central.consent. Redirect
the customer there; the register runs the WebAuthn assertion against the
stored public key on its own origin, then redirects back with
?dar-passkey-token={token-ref}. Call
GET /identity-records/{ir}/re-identify/{token-ref} once to confirm.
passkey-register — two-step redirect for new device enrolment. Same
flow as passkey-assert but runs a registration ceremony instead of
assertion. Stores a new public key credential on the Identity Record and
confirms re-identification on success.
magic-link, passkey-assert, passkey-register Response
Re-identification flow initiated. Customer has been challenged.
The re-identification method to use.
magic-link — single-step. The register dispatches a signed link to
the stored email address. Optionally supply redirect-url to send the
customer back to the Data User's app after clicking; otherwise the customer
lands on central.consent. Poll or check
GET /identity-records/{ir}/re-identify/{token-ref} to confirm.
passkey-assert — two-step redirect. The response contains a
passkey-redirect with a short-lived URL to id.central.consent. Redirect
the customer there; the register runs the WebAuthn assertion against the
stored public key on its own origin, then redirects back with
?dar-passkey-token={token-ref}. Call
GET /identity-records/{ir}/re-identify/{token-ref} once to confirm.
passkey-register — two-step redirect for new device enrolment. Same
flow as passkey-assert but runs a registration ceremony instead of
assertion. Stores a new public key credential on the Identity Record and
confirms re-identification on success.
magic-link, passkey-assert, passkey-register Populated for magic-link method; null otherwise.
Populated for passkey-assert and passkey-register methods; null for magic-link. Contains the redirect URL to id.central.consent where the WebAuthn ceremony takes place.