Liability and ToS

A verified human signs one master delegation agreement with the broker. Each agent acts under that delegation, and a brokered signup carries a specific acceptance of the provider's terms. The provider gets an attributable event, not an anonymous click.

This page explains the model and the operational consequences. It is not legal advice, and it does not replace your own terms or counsel. The normative rules are ToS binding and Contract E.

The two agreements

The provider does not receive the master agreement text and does not need it. It receives evidence that the human is verified and that the agent was delegated the scope to accept the provider terms.

What the acceptance proves

• The assertion was signed by a broker in your issuer_allowlist.
• The agent is bound to a human owner whose email address is verified.
• The delegated scopes cover your required_scopes, including tos:accept.
• The agent accepted the exact bytes whose SHA-256 equals delegation.accepted_rp_tos_hash.
• At the time the assertion was minted, the human had accepted the master agreement version in the claim.

It does not prove that the human read your terms, that the service is lawful, or that the agent will behave. It is an attribution and consent record, not a guarantee.

Enforce the hash

Your signup endpoint must compare the verified delegation.accepted_rp_tos_hash with the terms.sha256 you currently advertise:

• Equal: proceed.
• Different: return 409 with error: "tos_hash_mismatch". The agent must re-discover, re-read and re-accept. Do not accept the old hash silently.

When you change the terms, publish the new text, version and hash atomically. A bounded grace period for assertions already in flight is a policy you document outside discovery; the document advertises only the current version. The recommended bound is 24 hours, but the protocol does not require a grace period.

A fresh assertion that references an existing acceptance is not new consent. Do not send a second welcome or legal email because an agent called signup twice; resolve the account instead.

What to log and retain

Keep enough to answer "who signed up, for whom, under which terms, when":

• jti of the assertion, plus the account it was applied to;
• iss, agent.id, human.id and the opaque service.account_id;
• tos.version, tos.sha256, delegation.accepted_at and signed_up_at;
• the receipt jti if you issue one;
• the outcome: created or resolved.

Do not retain:

• provider credentials in logs, receipts or analytics;
• the raw assertion beyond the verification window and your audit need;
• the full human email in logs where an id is enough; store contact data in your account system, not in request logs;
• the terms text in every log line. The hash and version identify it.

Retention periods are your policy and may be constrained by law. The protocol does not set them.

Re-acceptance and revocation

• Terms change: new version, new text, new hash, fresh acceptance. Never edit the text in place under the same version.
• Human revokes the agent: the broker stops minting assertions for it. Your existing account remains until you act on it; revocation does not delete accounts a provider already created. Report abuse if the account is being misused.
• Human unverified: human.verified is false, and you return 403 human_unverified. Do not create the account.

What to tell the human

Your own terms and welcome flow should say what the human is accountable for and how to reach you. The broker forwards the acceptance receipt to the human owner's verified email; your provider receipt and context guide should not duplicate the master agreement.

The canonical description of the delegation claims is the specification; the master agreement itself is what the human accepted at the broker.

Next

• Receipt and context: the claims to return.
• Production checklist: retention, keys and incidents.
• Abuse reporting: what to do when attribution is not enough.