Align managed-namespace tenant signer with generated VerbAgent ENS#387
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 433ebced93
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const names = agentNames(); | ||
| return (names[0] || state.ens || '').toLowerCase(); | ||
| } | ||
| return (state.ens || '').toLowerCase(); |
There was a problem hiding this comment.
When activation mode is own, this now submits tenantSignerEns as the root state.ens, but buildENSRecords() still tells users to publish TXT records on each generated sub-agent with cl.receipt.signer=${name}. The status verifier resolves the stored claim.tenant_signer_ens and compares the four records there, so a BYO namespace user who follows Step 5 publishes records for e.g. approve.acme.eth while the claim verifies acme.eth, leaving activation stuck at records_unavailable/records_mismatch.
Useful? React with 👍 / 👎.
|
|
||
| function recordsFromAgent(agent) { | ||
| const card = agent && agent.cardJson && typeof agent.cardJson === 'object' ? agent.cardJson : {}; | ||
| const records = agent && agent.records && typeof agent.records === 'object' ? agent.records : card.records; |
There was a problem hiding this comment.
When a managed API client includes an agent.records object that omits cl.receipt.signer, this line stops looking at cardJson.records; the mismatched signer in cardJson is then persisted into claim_agents and can be pinned by api/admin/pin-agent-cards.js. For example, records: {} plus cardJson.records['cl.receipt.signer'] = 'acme.eth' returns 202 instead of managed_agent_signer_mismatch, so the new validation can be bypassed for the card records that downstream publication uses.
Useful? React with 👍 / 👎.
| const names = agentNames(); | ||
| return (names[0] || state.ens || '').toLowerCase(); |
There was a problem hiding this comment.
When a managed namespace is built by selecting/removing canonical parents directly, getEffectiveClVerbs() drives the submitted agents but this path still uses agentNames(), which reads getVerbs() from the pack/cherry state. If no pack is selected, or the canonical parent list no longer matches the pack, tenantSignerEns falls back to the tenant root or a different first agent while the payload's first agent comes from selectedCanonicalParents, and the new server-side managed_signer_mismatch check rejects the activation request.
Useful? React with 👍 / 👎.
| if (tenantSignerEns !== primaryManagedSignerEns) { | ||
| return invalid(res, 'managed_signer_mismatch', 'Managed namespace tenantSignerEns must match the first generated managed agent ENS.'); |
There was a problem hiding this comment.
This only checks that tenantSignerEns equals the first submitted agent ENS, so an API client can still submit a managed-namespace claim with both values set to the tenant root, e.g. tenantSignerEns: 'acme.eth' and agents[0].ens: 'acme.eth'. That passes the new guard, stores managed_ens_parent_namespace as eth, and reintroduces the root-signer managed claim that this change is meant to reject unless the code also verifies the ENS is the expected ${tenant}.${canonicalParent} managed agent.
Useful? React with 👍 / 👎.
1 participant
Motivation
tenant_signer_enscould point at the tenant root (e.g.acme.eth) while generated agent records used managed agent ENS (e.g.acme.attestagent.eth).Description
api/claim/commandlayer-namespace.jsto validate managed-namespace submissions and require that the submittedtenantSignerEnsmatches the first generated managed agent ENS, and to reject agent TXT records whosecl.receipt.signerdoes not match that agent's ENS.primaryTenantSignerEnsvalue in the request JSON for clarity (kept insiderequest_jsonand not adding DB columns), and continued to store the correctedtenant_signer_ensandtenant_signer_txt_recordsintoclaim_requests.public/claim.htmlto derivetenant_signer_ensfrom the first generated agent whenactivation_mode === 'managed_namespace', addprimary_tenant_signer_ensto generated manifests, surface a clear labelSigner ENS: ..., and add helper text:Managed namespace mode signs receipts from the generated VerbAgent ENS, not the tenant root ENS.recordsthroughsafeAgentso agent-levelcl.receipt.signercan be validated; kept per-agent records signing behavior so each agent still uses its own ENS ascl.receipt.signer.tests/claim-activation-pipeline.test.jscovering: managed namespace UI/package signer derivation, claim submission storing generated agent ENS and TXT signer, multi-capability primary signer selection while preserving per-agent signers, BYO/root signer preservation, and rejection cases for managed signer mismatches.Testing
npm testand all tests passed (157 tests currently, no failures).npm run check:linksand link checks passed (all local links resolved).tests/claim-activation-pipeline.test.jsinclude assertions for UI/package behavior, claim persistence oftenant_signer_ensandprimaryTenantSignerEns, BYO behavior, and rejection cases; these tests passed under the test run above.Codex Task