Agent Attribution Header Fields

Introduction Recent autonomous computer agent users have gained the capability to communicate with human users through such means such as emails (). Human users should be able to identify that communication as coming from computer agents. They should also be able to identify which humans are responsible for the agent, that is the human owner of the agent. For example when the agent misbehaves and sends unwanted email, the recipient may want to communicate with the responsible human to stop the behavior. This document specifies email header fields () that an email sender can use to transmit agent user attribution information to email receivers. The first header field Agent-of specifies the agent's responsible human's email address, and is human and machine readable. The second header field Agent-attribution is specified in JSON attribution information, and is meant to be machine readable only.

Terminology and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

Header Fields This specification defines two header field-names () agent-of and agent-attribution. When the agent-of header field is attached to an email, it defines that a computer agent sent the message. The field value is an address-list () of the responsible humans of the agent that sent an email. This is meant to be human and machine readable. With this header field, the responsible human information here is simplified for readability. If there are multiple responsible humans of an agent, multiple addresses may be specified or an email address alias may be used to represent many users that control that agent. In other scenarios, when an agent triggers the creation of another agent, the responsible human information SHOULD be propagated so that it is always available to the newly created agent. Alternatively when the sender wishes to represent a more complex responsibility relationship, they can use the agent-attribution header field. The field value is a base64string () of JSON (). The JSON key-value of attributes about the identity of the responsible humans that allows arbitrary definition of responsibility and delegation relationship of computer agents. We expect that there will be an IANA registry for these values as well as future updates to this document to represent those relationships. It is meant to be only machine readable. When the agent-attribution header field is attached to an email, it also defines that a computer agent sent the message. If both header fields are present in a message, the receiver SHOULD take a union of the sender identities of both header fields.

Authentication Senders SHOULD sign these header fields with DKIM (). Receivers that use these headers MUST DKIM authenticate them, i.e the signature passes and the header fields are covered by the header hash. If DKIM2 (draft-ietf-dkim-dkim2-spec) authentication is available, then DKIM2 results SHOULD be used for authentication instead of DKIM. To prevent spoofing of the responsible humans, receivers that use those identities MUST check for DMARC relaxed () alignment with a passing DKIM or DKIM2 signature domain.

Security Considerations These headers MUST be DKIM authenticated before they can be used as defined in . Similarly the responsible humans' email addresses domains MUST be DKIM aligned as defined in . Presence of this header field does not infer any trustworthiness. It is simply a claim by the sender that the creator of the email is an agent and a second claim of who are the responsible humans of an agent. Receivers MUST make their own judgement of the utility of this information.

IANA Considerations This document has no IANA actions yet. --