IMPLEMENTATION SPEC: let a smart contract that owns identity.md NFTs run IMD seats (ERC-1271 pairing)

CONTEXT

• IMD pairs a worker device to a seat when the NFT holder signs the EIP-712 WorkerAuthorization on the pairing page (https://api.imd.fun/pair) and POST /pair/complete accepts the signature (docs: https://imd.fun/docs, section Pairing and agents). IMD's maintainers confirmed that today the holder must be an EOA, and said they would consider supporting contracts if given a clear way to do it. This job produces that way.
• The contract holder: IMDSTR's strategy 0x0000198C940D8cD70Cb9ACeC5E3af8216ac57d2F on Ethereum mainnet (a UUPS proxy; implementation IMDSeatStrategy 0x16d3f65b708883df042d98e1c7a49b32a33e2a14, source verified on Etherscan). It holds identity.md (0x0000eC93127BAA929E58E97dd0095A2BFb38ec1D) tokens 806 and 1533.
• How it already signs: its seat operator calls authorizeWorker(message), which builds the WorkerAuthorization digest on-chain from the same domain and types as the pairing page (name "IdentityMD Worker", version "2", chainId 1, verifyingContract = the collection; deviceKey bytes32, wallet address, tokenId uint256, nonce bytes32, expiresAt uint64, relayOrigin string) and requires wallet == the strategy, the strategy owning tokenId, and an unexpired message. isValidSignature(digest, anything) then returns 0x1626ba7e for that digest while the strategy still owns the token, and 0xffffffff otherwise. It registers ERC-8004 agents itself through IMD's adapter 0xde152AfB7db5373F34876E1499fbD893A82dD336 (registerAgent), since the adapter only checks msg.sender == ownerOf(tokenId).
• IMD's worker CLI is public: https://github.com/Identity-md/worker (pairing starts with POST /pair/start and is completed by the holder on the pairing page). The control plane itself is not public: reason from its documented behaviour and responses.

GOAL

A precise, drop-in specification that IMD's maintainers can implement in an afternoon so a contract holder can pair a device to its seat, without weakening anything for EOA holders.

WHAT TO DELIVER

1. Every place in IMD's documented flow that assumes the holder is an EOA: the pairing page, POST /pair/complete, routes authenticated by a Wallet EIP-712 signature, ownership re-checks, and anything paid to the holder. For each, say whether a contract holder is blocked and why.
2. The change to POST /pair/complete: verify the WorkerAuthorization with ERC-1271 when the wallet has code, keeping every existing check (code single-use, nonce, expiry, ownerOf(tokenId) == wallet). Give it as TypeScript using viem's publicClient.verifyTypedData (which covers EOA, ERC-1271 and ERC-6492), with the exact typed data, the eth_call gas cap and timeout for isValidSignature, and the error returned when a contract says no. Say what the request body looks like for a contract (the strategy sends signature "0x").
3. Test vectors against mainnet: how to compute the digest for a given message, the eth_call to isValidSignature on the strategy that returns 0xffffffff for an unapproved digest today, and how the maintainers can test the approved path on a mainnet fork (impersonating the seat operator to call authorizeWorker).
4. Security review of accepting contract signatures: contracts that return the magic value for everything, replay across tokens or collections, the token being sold after pairing, reentrancy or gas griefing during the view call, RPC failure (fail closed), and anything else that matters. Severity and mitigation for each.
5. The alternative that needs no ERC-1271: accepting a delegate's EOA signature through the delegate.xyz v2 registry (0x00000000000000447e69651d841bD8D104Bed493), where the holder contract delegates the token. Compare effort and risk with option 2 and recommend one.
6. A step-by-step runbook for the strategy once supported: imd pair, authorizeWorker, POST /pair/complete, registerAgent, POST /agents/bind, imd start, and how to check the seat is live (GET /pair/wallet/).
7. A short plain-language summary at the top.

Read-only: use public docs, the public worker repository, public RPCs and explorers. No transactions.

RULES OF ENGAGEMENT (mandatory)

• Read-only, black-box use of public surfaces only. No load testing (max 1 request per second, max 300 requests total), no attempts to access other users' data, no credential guessing, no transactions, no payments, no signatures, no pairing attempts against the live control plane.
• Do not publish anything. Everything goes only into the output files of this job.
• Every factual claim about IMD's current behaviour must cite the doc section, file and line in the worker repository, or the exact request and response (with UTC timestamp) it comes from. Clearly separate VERIFIED (observed) from SUSPECTED (reasoning only).