Goal
Transfer and offer data should only be returned to the address owner, not served publicly by address. This issue covers (a) deciding the authentication mechanism for read access, (b) auditing every transfer/offer and other endpoint to classify whether it needs authentication, and (c) implementing auth on the read endpoints. Write requests continue to use the existing EIP-191 signature path unchanged.
Step 1 — Decide the authentication mechanism (blocker, discuss first)
Conclude this before implementation. Options for read auth:
- EIP-191 signature (reuse authenticateEVM) - would be incompatible with non custodial
- JWT
Decide and record: which mechanism(s), and how the authenticated identity binds to the EVM address / Canton party.
Step 2 — Audit all transfer/offer endpoints
Classify each endpoint and confirm the target auth posture.
Step 3 — Constraints
- All write requests keep using the signature path (authenticateEVM). The auth-mechanism decision in Step 1 is about read access only.
- For reads, derive the address from the authenticated identity; drop ?address= (or reject when it doesn't match the authenticated identity). A caller may only access their own data.
Goal
Transfer and offer data should only be returned to the address owner, not served publicly by address. This issue covers (a) deciding the authentication mechanism for read access, (b) auditing every transfer/offer and other endpoint to classify whether it needs authentication, and (c) implementing auth on the read endpoints. Write requests continue to use the existing EIP-191 signature path unchanged.
Step 1 — Decide the authentication mechanism (blocker, discuss first)
Conclude this before implementation. Options for read auth:
Decide and record: which mechanism(s), and how the authenticated identity binds to the EVM address / Canton party.
Step 2 — Audit all transfer/offer endpoints
Classify each endpoint and confirm the target auth posture.
Step 3 — Constraints