Threat Model

Email as Public Input

The user's email is entered at the SP to trigger DNS discovery. This is inherently visible to the SP — an accepted, unclosable information surface.

Why it's OK: The email is needed for DNS resolution (_ddisa.{domain}). Passkeys ensure that knowing someone's email is insufficient to impersonate them. This is the same model as email itself — knowing an address doesn't give you access.

Minimal AuthN-JWT

The identity token contains only:

• sub — email (consistent from input to token)
• act — human or agent
• iss, aud, exp, nonce

Explicitly not in the AuthN-JWT:

• Name, display name → IdP-internal
• Owner, approver → AuthZ layer (grants)

Rationale: AuthN says who. AuthZ says what may they do. Mixing them increases token size and leaks information the SP doesn't need.

Grant Security

Command Hash Binding

For apes and similar tools, grants are bound to the exact command via SHA-256:

cmd_hash = sha256("apt-get upgrade")

The target system computes the hash locally and compares. If it doesn't match, execution is aborted. This prevents:

• Substitution attacks — approving "whoami" but executing "rm -rf /"
• Replay with different commands — the hash won't match

Dual Accountability

Grants track both the agent's identity and the approver's identity separately. In many setups, the agent owner and the approver are different people:

• Agent owner: the person responsible for the agent
• Approver: the person who approved this specific action

Both are recorded in the AuthZ-JWT (sub + decided_by).

Default Deny

No grant = no access. Agents start with zero permissions and must request each one. There is no "admin agent" concept — every privileged action requires explicit human approval (or a standing grant).