# Trust Protocol | | | | ----------- | ------ | | **Version** | 0.3.0 | | **Status** | Posted | The **Trust Protocol** defines the normative procedures a counterparty performs to establish trust in an ADL agent: verifying a passport, binding a request to a presentation proof, and authorizing agent-to-agent calls. It is the *protocol* layer that sits on top of the *description* layer defined by the [ADL Core specification](/spec/.md). ADL Core declares what an agent is and which credential schemes and scopes it advertises; ADL Trust defines what a verifier **MUST** do with those declarations. The Trust Protocol is numbered independently as a standalone document: Authentication is §1 and Authorization is §2. Section references outside this range — for example §6.4, §9, §10.1, or §10.2 — refer to the [ADL Core specification](/spec/.md). Conformance test vectors and verification-outcome step identifiers track these Trust Protocol section numbers (e.g., §1.1.5, §1.2.6.6). The declarative members these procedures operate on — `security.attestation` (Core §10.2), the credential schemes (Core §10.3.3), and the scope declarations (Core §10.4.1–§10.4.2) — are defined in [ADL Core](/spec/.md). This document references them but does not redefine them. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 \[RFC2119] \[RFC8174] when, and only when, they appear in all capitals, as shown here. ## The Passport[​](#the-passport "Direct link to The Passport") A **passport** is a compact **identity document** for an agent — smaller than the agent's full [ADL Core](/spec/.md) document — that the agent presents to establish trust with other agents. Where the full ADL document describes everything about an agent (identity, capabilities, tools, resources, model configuration, permissions, and runtime behavior), the passport carries only what a counterparty needs to answer two questions: *who is this agent?* and *can I trust this document?* The members it carries are defined by [ADL Core](/spec/.md), which is authoritative for their syntax and constraints. ![Left-to-right class diagram of passport distillation. On the left, the full ADL Document lists all its member groups; the identity-and-trust members (adl\_spec, id and provider, cryptographic\_identity, security attestation and scopes, lifecycle status, permissions, and data\_classification) are highlighted as the distilled subset, while the operational members (capabilities, tools, resources, model, runtime behaviour and degradation, human\_oversight, anomaly\_baseline) are greyed as staying behind. A derive arrow crosses to the middle column, the Agent Passport — a compact signed box carrying only that subset, the members a counterparty needs to answer who is this agent and can I trust this document. A present arrow then carries the passport to a counterparty on the right, attached to a request or dereferenced by URL. The passport is a typed projection of the document: identity and trust travel; capabilities and runtime stay behind, resolved separately when needed.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHZpZXdCb3g9IjAgMCA5MDAgNjQwIiB3aWR0aD0iOTAwIiBoZWlnaHQ9IjY0MCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsbGVkYnk9InBkLXRpdGxlIHBkLWRlc2MiIGZvbnQtZmFtaWx5PSItYXBwbGUtc3lzdGVtLCBCbGlua01hY1N5c3RlbUZvbnQsICdTZWdvZSBVSScsIEhlbHZldGljYSwgQXJpYWwsIHNhbnMtc2VyaWYiPgogIDx0aXRsZSBpZD0icGQtdGl0bGUiPlBhc3Nwb3J0IGRpc3RpbGxhdGlvbjogYSBjb21wYWN0LCBzZXBhcmF0ZWx5LXZlcmlmaWFibGUgY3JlZGVudGlhbCBkZXJpdmVkIGZyb20gdGhlIGZ1bGwgQURMIGRvY3VtZW50PC90aXRsZT4KICA8ZGVzYyBpZD0icGQtZGVzYyI+QSBsZWZ0LXRvLXJpZ2h0IGNsYXNzL29iamVjdCBkaWFncmFtIGluIHRocmVlIGNvbHVtbnMuIE9uIHRoZSBsZWZ0LCB0aGUgZnVsbCBBREwgRG9jdW1lbnQgbGlzdHMgYWxsIG9mIGl0cyBtZW1iZXIgZ3JvdXBzOyB0aGUgaWRlbnRpdHktYW5kLXRydXN0IG1lbWJlcnMgKGFkbF9zcGVjLCBpZCBhbmQgcHJvdmlkZXIsIGNyeXB0b2dyYXBoaWNfaWRlbnRpdHksIHNlY3VyaXR5IGF0dGVzdGF0aW9uIGFuZCBzY29wZXMsIGxpZmVjeWNsZSBzdGF0dXMsIHBlcm1pc3Npb25zLCBhbmQgZGF0YV9jbGFzc2lmaWNhdGlvbikgYXJlIGhpZ2hsaWdodGVkIGFzIHRoZSBkaXN0aWxsZWQgc3Vic2V0LCB3aGlsZSB0aGUgb3BlcmF0aW9uYWwgbWVtYmVycyAoY2FwYWJpbGl0aWVzLCB0b29scywgcmVzb3VyY2VzLCBtb2RlbCwgcnVudGltZSBiZWhhdmlvdXIgYW5kIGRlZ3JhZGF0aW9uLCBodW1hbl9vdmVyc2lnaHQsIGFub21hbHlfYmFzZWxpbmUpIGFyZSBncmV5ZWQgYXMgc3RheWluZyBiZWhpbmQgaW4gdGhlIGZ1bGwgZG9jdW1lbnQuIEEgc2luZ2xlIGRlcml2ZSBhcnJvdyBjcm9zc2VzIHRvIHRoZSBtaWRkbGUgY29sdW1uLCB0aGUgQWdlbnQgUGFzc3BvcnQsIGEgY29tcGFjdCBib3ggY2Fycnlpbmcgb25seSB0aGF0IGRpc3RpbGxlZCBzdWJzZXQg4oCUIHRoZSBtZW1iZXJzIGEgY291bnRlcnBhcnR5IG5lZWRzIHRvIGFuc3dlciB3aG8gaXMgdGhpcyBhZ2VudCBhbmQgY2FuIEkgdHJ1c3QgdGhpcyBkb2N1bWVudC4gQSBwcmVzZW50IGFycm93IHRoZW4gY2FycmllcyB0aGUgcGFzc3BvcnQgdG8gdGhlIHJpZ2h0IGNvbHVtbiwgYSBjb3VudGVycGFydHksIGF0dGFjaGVkIHRvIGEgcmVxdWVzdCBvciBkZXJlZmVyZW5jZWQgYnkgVVJMLiBBIG5vdGUgc3RhdGVzIHRoZSBwYXNzcG9ydCBpcyBhIHR5cGVkIHByb2plY3Rpb24gb2YgdGhlIGRvY3VtZW50OiBpZGVudGl0eSBhbmQgdHJ1c3QgdHJhdmVsOyBjYXBhYmlsaXRpZXMgYW5kIHJ1bnRpbWUgc3RheSBiZWhpbmQsIGFuZCB0aGUgZnVsbCBkb2N1bWVudCBpcyByZXNvbHZlZCBzZXBhcmF0ZWx5IHdoZW4gbmVlZGVkLjwvZGVzYz4KCiAgPGRlZnM+CiAgICA8bWFya2VyIGlkPSJwZC1hcnJvdyIgdmlld0JveD0iMCAwIDEwIDEwIiByZWZYPSI5IiByZWZZPSI1IiBtYXJrZXJXaWR0aD0iNyIgbWFya2VySGVpZ2h0PSI3IiBvcmllbnQ9ImF1dG8tc3RhcnQtcmV2ZXJzZSI+CiAgICAgIDxwYXRoIGQ9Ik0wLDAgTDEwLDUgTDAsMTAgeiIgZmlsbD0iIzMzNDE1NSIvPgogICAgPC9tYXJrZXI+CiAgPC9kZWZzPgoKICA8cmVjdCB4PSIwIiB5PSIwIiB3aWR0aD0iOTAwIiBoZWlnaHQ9IjY0MCIgZmlsbD0iI2ZmZmZmZiIvPgoKICA8IS0tIFRpdGxlIC0tPgogIDx0ZXh0IHg9IjQ1MCIgeT0iMzQiIHRleHQtYW5jaG9yPSJtaWRkbGUiIGZvbnQtc2l6ZT0iMjAiIGZvbnQtd2VpZ2h0PSI3MDAiIGZpbGw9IiMwZjE3MmEiPlBhc3Nwb3J0IERpc3RpbGxhdGlvbjwvdGV4dD4KICA8dGV4dCB4PSI0NTAiIHk9IjU2IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBmb250LXNpemU9IjEzIiBmb250LXN0eWxlPSJpdGFsaWMiIGZpbGw9IiM0NzU1NjkiPkEgY29tcGFjdCwgc2VwYXJhdGVseS12ZXJpZmlhYmxlIGNyZWRlbnRpYWwgZGVyaXZlZCBmcm9tIHRoZSBmdWxsIEFETCBkb2N1bWVudDwvdGV4dD4KCiAgPCEtLSA9PT09PT09PT09PT09PT09PT09PT0gTEVGVDogZnVsbCBBREwgZG9jdW1lbnQgPT09PT09PT09PT09PT09PT09PT09IC0tPgogIDxyZWN0IHg9IjQwIiB5PSI5MiIgd2lkdGg9IjMwMCIgaGVpZ2h0PSI0NzYiIHJ4PSIxMCIgZmlsbD0iI2Y4ZmFmYyIgc3Ryb2tlPSIjMWE3M2U4IiBzdHJva2Utd2lkdGg9IjEuNSIvPgogIDx0ZXh0IHg9IjE5MCIgeT0iMTE2IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBmb250LXNpemU9IjE0IiBmb250LXdlaWdodD0iNzAwIiBmaWxsPSIjMGI1N2QwIj5BREwgRG9jdW1lbnQ8L3RleHQ+CiAgPHRleHQgeD0iMTkwIiB5PSIxMzIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIGZvbnQtc2l6ZT0iMTAiIGZvbnQtc3R5bGU9Iml0YWxpYyIgZmlsbD0iIzY0NzQ4YiI+dGhlIGZ1bGwgYWdlbnQgZGVmaW5pdGlvbiAoQ29yZSk8L3RleHQ+CgogIDwhLS0gZGlzdGlsbGVkIHN1YnNldCBoZWFkZXIgLS0+CiAgPHRleHQgeD0iNjAiIHk9IjE1OCIgZm9udC1zaXplPSI5LjUiIGZvbnQtd2VpZ2h0PSI3MDAiIGZpbGw9IiMwYjU3ZDAiIGxldHRlci1zcGFjaW5nPSIwLjYiPkRJU1RJTExFRCBJTlRPIFRIRSBQQVNTUE9SVDwvdGV4dD4KICA8IS0tIElOIHJvd3MgLS0+CiAgPGcgZm9udC1zaXplPSIxMSIgZmlsbD0iIzBmMTcyYSI+CiAgICA8cmVjdCB4PSI1NiIgeT0iMTY0IiB3aWR0aD0iMjY4IiBoZWlnaHQ9IjIyIiByeD0iNCIgZmlsbD0iI2U4ZjBmZSIvPgogICAgPHRleHQgeD0iNjYiIHk9IjE3OSI+YWRsX3NwZWMgJiM4MjEyOyBzcGVjIHZlcnNpb248L3RleHQ+CiAgICA8cmVjdCB4PSI1NiIgeT0iMTkwIiB3aWR0aD0iMjY4IiBoZWlnaHQ9IjIyIiByeD0iNCIgZmlsbD0iI2U4ZjBmZSIvPgogICAgPHRleHQgeD0iNjYiIHk9IjIwNSI+aWQgJiMxODM7IHByb3ZpZGVyICYjODIxMjsgaWRlbnRpdHk8L3RleHQ+CiAgICA8cmVjdCB4PSI1NiIgeT0iMjE2IiB3aWR0aD0iMjY4IiBoZWlnaHQ9IjIyIiByeD0iNCIgZmlsbD0iI2U4ZjBmZSIvPgogICAgPHRleHQgeD0iNjYiIHk9IjIzMSI+Y3J5cHRvZ3JhcGhpY19pZGVudGl0eTwvdGV4dD4KICAgIDxyZWN0IHg9IjU2IiB5PSIyNDIiIHdpZHRoPSIyNjgiIGhlaWdodD0iMjIiIHJ4PSI0IiBmaWxsPSIjZThmMGZlIi8+CiAgICA8dGV4dCB4PSI2NiIgeT0iMjU3Ij5zZWN1cml0eSAmIzgyMTI7IGF0dGVzdGF0aW9uICYjMTgzOyBzY29wZXM8L3RleHQ+CiAgICA8cmVjdCB4PSI1NiIgeT0iMjY4IiB3aWR0aD0iMjY4IiBoZWlnaHQ9IjIyIiByeD0iNCIgZmlsbD0iI2U4ZjBmZSIvPgogICAgPHRleHQgeD0iNjYiIHk9IjI4MyI+bGlmZWN5Y2xlLnN0YXR1czwvdGV4dD4KICAgIDxyZWN0IHg9IjU2IiB5PSIyOTQiIHdpZHRoPSIyNjgiIGhlaWdodD0iMjIiIHJ4PSI0IiBmaWxsPSIjZThmMGZlIi8+CiAgICA8dGV4dCB4PSI2NiIgeT0iMzA5Ij5wZXJtaXNzaW9uczwvdGV4dD4KICAgIDxyZWN0IHg9IjU2IiB5PSIzMjAiIHdpZHRoPSIyNjgiIGhlaWdodD0iMjIiIHJ4PSI0IiBmaWxsPSIjZThmMGZlIi8+CiAgICA8dGV4dCB4PSI2NiIgeT0iMzM1Ij5kYXRhX2NsYXNzaWZpY2F0aW9uPC90ZXh0PgogIDwvZz4KCiAgPCEtLSBzdGF5cy1iZWhpbmQgaGVhZGVyIC0tPgogIDx0ZXh0IHg9IjYwIiB5PSIzNjQiIGZvbnQtc2l6ZT0iOS41IiBmb250LXdlaWdodD0iNzAwIiBmaWxsPSIjOTRhM2I4IiBsZXR0ZXItc3BhY2luZz0iMC42Ij5TVEFZUyBJTiBUSEUgRlVMTCBET0NVTUVOVDwvdGV4dD4KICA8IS0tIE9VVCByb3dzIC0tPgogIDxnIGZvbnQtc2l6ZT0iMTEiIGZpbGw9IiM5NGEzYjgiPgogICAgPHJlY3QgeD0iNTYiIHk9IjM3MCIgd2lkdGg9IjI2OCIgaGVpZ2h0PSIyMCIgcng9IjQiIGZpbGw9IiNmMWY1ZjkiLz4KICAgIDx0ZXh0IHg9IjY2IiB5PSIzODQiPmNhcGFiaWxpdGllczwvdGV4dD4KICAgIDxyZWN0IHg9IjU2IiB5PSIzOTQiIHdpZHRoPSIyNjgiIGhlaWdodD0iMjAiIHJ4PSI0IiBmaWxsPSIjZjFmNWY5Ii8+CiAgICA8dGV4dCB4PSI2NiIgeT0iNDA4Ij50b29sczwvdGV4dD4KICAgIDxyZWN0IHg9IjU2IiB5PSI0MTgiIHdpZHRoPSIyNjgiIGhlaWdodD0iMjAiIHJ4PSI0IiBmaWxsPSIjZjFmNWY5Ii8+CiAgICA8dGV4dCB4PSI2NiIgeT0iNDMyIj5yZXNvdXJjZXM8L3RleHQ+CiAgICA8cmVjdCB4PSI1NiIgeT0iNDQyIiB3aWR0aD0iMjY4IiBoZWlnaHQ9IjIwIiByeD0iNCIgZmlsbD0iI2YxZjVmOSIvPgogICAgPHRleHQgeD0iNjYiIHk9IjQ1NiI+bW9kZWw8L3RleHQ+CiAgICA8cmVjdCB4PSI1NiIgeT0iNDY2IiB3aWR0aD0iMjY4IiBoZWlnaHQ9IjIwIiByeD0iNCIgZmlsbD0iI2YxZjVmOSIvPgogICAgPHRleHQgeD0iNjYiIHk9IjQ4MCI+cnVudGltZSAmIzgyMTI7IGJlaGF2aW91ciAmIzE4MzsgZGVncmFkYXRpb248L3RleHQ+CiAgICA8cmVjdCB4PSI1NiIgeT0iNDkwIiB3aWR0aD0iMjY4IiBoZWlnaHQ9IjIwIiByeD0iNCIgZmlsbD0iI2YxZjVmOSIvPgogICAgPHRleHQgeD0iNjYiIHk9IjUwNCI+aHVtYW5fb3ZlcnNpZ2h0PC90ZXh0PgogICAgPHJlY3QgeD0iNTYiIHk9IjUxNCIgd2lkdGg9IjI2OCIgaGVpZ2h0PSIyMCIgcng9IjQiIGZpbGw9IiNmMWY1ZjkiLz4KICAgIDx0ZXh0IHg9IjY2IiB5PSI1MjgiPmFub21hbHlfYmFzZWxpbmU8L3RleHQ+CiAgPC9nPgoKICA8IS0tID09PT09PT09PT09PT09PT09PT09PSBkZXJpdmUgYXJyb3cgKGZyb20gSU4gZ3JvdXAgdG8gcGFzc3BvcnQpID09PT09PT09PT09PT09PT09PT09PSAtLT4KICA8bGluZSB4MT0iMzQwIiB5MT0iMjQ5IiB4Mj0iNDQ4IiB5Mj0iMjQ5IiBzdHJva2U9IiMzMzQxNTUiIHN0cm9rZS13aWR0aD0iMS41IiBzdHJva2UtZGFzaGFycmF5PSI1IDQiIG1hcmtlci1lbmQ9InVybCgjcGQtYXJyb3cpIi8+CiAgPHJlY3QgeD0iMzU2IiB5PSIyMjciIHdpZHRoPSI3NiIgaGVpZ2h0PSIxNiIgZmlsbD0iI2ZmZmZmZiIvPgogIDx0ZXh0IHg9IjM5NCIgeT0iMjM5IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBmb250LXNpemU9IjEwLjUiIGZvbnQtc3R5bGU9Iml0YWxpYyIgZmlsbD0iIzQ3NTU2OSI+JiMxNzE7ZGVyaXZlJiMxODc7PC90ZXh0PgogIDx0ZXh0IHg9IjM5NCIgeT0iMjYzIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBmb250LXNpemU9IjkiIGZpbGw9IiM2NDc0OGIiPnR5cGVkIHByb2plY3Rpb248L3RleHQ+CgogIDwhLS0gPT09PT09PT09PT09PT09PT09PT09IE1JRERMRTogdGhlIHBhc3Nwb3J0ID09PT09PT09PT09PT09PT09PT09PSAtLT4KICA8cmVjdCB4PSI0NTAiIHk9IjE1MCIgd2lkdGg9IjI1MCIgaGVpZ2h0PSIyOTAiIHJ4PSIxMCIgZmlsbD0iI2ZmZjdlNiIgc3Ryb2tlPSIjZjU5ZTBiIiBzdHJva2Utd2lkdGg9IjEuNzUiLz4KICA8dGV4dCB4PSI1NzUiIHk9IjE3NiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgZm9udC1zaXplPSIxNCIgZm9udC13ZWlnaHQ9IjcwMCIgZmlsbD0iI2I0NTMwOSI+QWdlbnQgUGFzc3BvcnQ8L3RleHQ+CiAgPHRleHQgeD0iNTc1IiB5PSIxOTIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIGZvbnQtc2l6ZT0iOS41IiBmb250LXN0eWxlPSJpdGFsaWMiIGZpbGw9IiM5MjcyMmYiPmNvbXBhY3QgJiMxODM7IHNpZ25lZCAmIzE4MzsgcmUtdmVyaWZpZWQgZWFjaCBleGNoYW5nZTwvdGV4dD4KCiAgPGcgZm9udC1zaXplPSIxMSIgZmlsbD0iIzBmMTcyYSI+CiAgICA8dGV4dCB4PSI0NzAiIHk9IjIxOCI+YWRsX3NwZWM8L3RleHQ+CiAgICA8dGV4dCB4PSI0NzAiIHk9IjI0MCI+aWQ8L3RleHQ+CiAgICA8dGV4dCB4PSI0NzAiIHk9IjI2MiI+Y3J5cHRvZ3JhcGhpY19pZGVudGl0eTwvdGV4dD4KICAgIDx0ZXh0IHg9IjQ3MCIgeT0iMjg0Ij5zZWN1cml0eS5hdHRlc3RhdGlvbiAoKyBzaWduYXR1cmUpPC90ZXh0PgogICAgPHRleHQgeD0iNDcwIiB5PSIzMDYiPmxpZmVjeWNsZS5zdGF0dXM8L3RleHQ+CiAgICA8dGV4dCB4PSI0NzAiIHk9IjMyOCI+cHJvdmlkZXI8L3RleHQ+CiAgICA8dGV4dCB4PSI0NzAiIHk9IjM1MCI+cGVybWlzc2lvbnMgJiMxODM7IGRhdGFfY2xhc3NpZmljYXRpb248L3RleHQ+CiAgICA8dGV4dCB4PSI0NzAiIHk9IjM3MiI+c2VjdXJpdHkuc2NvcGVzPC90ZXh0PgogIDwvZz4KICA8bGluZSB4MT0iNDY2IiB5MT0iMzg2IiB4Mj0iNjg0IiB5Mj0iMzg2IiBzdHJva2U9IiNmM2Q4YTgiIHN0cm9rZS13aWR0aD0iMSIvPgogIDx0ZXh0IHg9IjU3NSIgeT0iNDA2IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBmb250LXNpemU9IjkuNSIgZmlsbD0iIzkyNzIyZiI+YW5zd2Vyczogd2hvIGlzIHRoaXMgYWdlbnQ/PC90ZXh0PgogIDx0ZXh0IHg9IjU3NSIgeT0iNDIxIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBmb250LXNpemU9IjkuNSIgZmlsbD0iIzkyNzIyZiI+YW5kIGNhbiBJIHRydXN0IHRoaXMgZG9jdW1lbnQ/PC90ZXh0PgoKICA8IS0tID09PT09PT09PT09PT09PT09PT09PSBwcmVzZW50IGFycm93IChwYXNzcG9ydCB0byBjb3VudGVycGFydHkpID09PT09PT09PT09PT09PT09PT09PSAtLT4KICA8bGluZSB4MT0iNzAwIiB5MT0iMjQ5IiB4Mj0iNzg4IiB5Mj0iMjQ5IiBzdHJva2U9IiMzMzQxNTUiIHN0cm9rZS13aWR0aD0iMS41IiBtYXJrZXItZW5kPSJ1cmwoI3BkLWFycm93KSIvPgogIDxyZWN0IHg9IjcxMiIgeT0iMjI3IiB3aWR0aD0iNjQiIGhlaWdodD0iMTYiIGZpbGw9IiNmZmZmZmYiLz4KICA8dGV4dCB4PSI3NDQiIHk9IjIzOSIgdGV4dC1hbmNob3I9Im1pZGRsZSIgZm9udC1zaXplPSIxMC41IiBmb250LXN0eWxlPSJpdGFsaWMiIGZpbGw9IiM0NzU1NjkiPiYjMTcxO3ByZXNlbnQmIzE4Nzs8L3RleHQ+CiAgPHRleHQgeD0iNzQ0IiB5PSIyNjMiIHRleHQtYW5jaG9yPSJtaWRkbGUiIGZvbnQtc2l6ZT0iOSIgZmlsbD0iIzY0NzQ4YiI+YXR0YWNoZWQgb3I8L3RleHQ+CiAgPHRleHQgeD0iNzQ0IiB5PSIyNzUiIHRleHQtYW5jaG9yPSJtaWRkbGUiIGZvbnQtc2l6ZT0iOSIgZmlsbD0iIzY0NzQ4YiI+ZGVyZWZlcmVuY2VkPC90ZXh0PgoKICA8IS0tID09PT09PT09PT09PT09PT09PT09PSBSSUdIVDogY291bnRlcnBhcnR5ID09PT09PT09PT09PT09PT09PT09PSAtLT4KICA8cmVjdCB4PSI3OTAiIHk9IjIwNiIgd2lkdGg9IjkyIiBoZWlnaHQ9Ijg2IiByeD0iMTAiIGZpbGw9IiNlNmY0ZWEiIHN0cm9rZT0iIzEzNzMzMyIgc3Ryb2tlLXdpZHRoPSIxLjUiLz4KICA8dGV4dCB4PSI4MzYiIHk9IjI0NCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgZm9udC1zaXplPSIxMiIgZm9udC13ZWlnaHQ9IjcwMCIgZmlsbD0iIzBkNjUyZCI+Y291bnRlci08L3RleHQ+CiAgPHRleHQgeD0iODM2IiB5PSIyNjAiIHRleHQtYW5jaG9yPSJtaWRkbGUiIGZvbnQtc2l6ZT0iMTIiIGZvbnQtd2VpZ2h0PSI3MDAiIGZpbGw9IiMwZDY1MmQiPnBhcnR5PC90ZXh0PgoKICA8IS0tID09PT09PT09PT09PT09PT09PT09PSBmb290bm90ZSA9PT09PT09PT09PT09PT09PT09PT0gLS0+CiAgPHRleHQgeD0iNDUwIiB5PSI2MDAiIHRleHQtYW5jaG9yPSJtaWRkbGUiIGZvbnQtc2l6ZT0iMTEiIGZvbnQtc3R5bGU9Iml0YWxpYyIgZmlsbD0iIzQ3NTU2OSI+VGhlIHBhc3Nwb3J0IGlzIGEgdHlwZWQgcHJvamVjdGlvbiBvZiB0aGUgZG9jdW1lbnQ6IGlkZW50aXR5IGFuZCB0cnVzdCB0cmF2ZWw7IGNhcGFiaWxpdGllcyBhbmQgcnVudGltZSBzdGF5IGJlaGluZC48L3RleHQ+CiAgPHRleHQgeD0iNDUwIiB5PSI2MTciIHRleHQtYW5jaG9yPSJtaWRkbGUiIGZvbnQtc2l6ZT0iMTEiIGZvbnQtc3R5bGU9Iml0YWxpYyIgZmlsbD0iIzQ3NTU2OSI+QSBjb3VudGVycGFydHkgdGhhdCBuZWVkcyB0aGUgYWdlbnQncyBjb21wbGV0ZSBkZWZpbml0aW9uIHJlc29sdmVzIHRoZSBmdWxsIEFETCBkb2N1bWVudCBzZXBhcmF0ZWx5LjwvdGV4dD4KPC9zdmc+Cg==) *Figure 1 (informative): The passport is a typed projection of the full ADL document — the identity-and-trust subset a counterparty needs, distilled into a compact signed credential, while the operational members stay in the full document and are resolved separately. This figure is illustrative; the member list below is authoritative.* Keeping the passport small matters because it travels on agent-to-agent interactions — attached to a request or dereferenced by URL (§1.2.5) — and is verified on every exchange. A counterparty that needs the agent's complete definition resolves the full ADL document separately. Note that `permissions` and `data_classification` are carried in full rather than as a digest; an agent with large permission sets (up to the Core §18.5 limits) therefore trades passport compactness for self-containment, which implementers sizing a passport header (e.g., `ADL-Passport`) should anticipate. The passport carries the following members: | Member | ADL Core | Role in trust | | ------------------------------------ | --------- | ---------------------------------------------------------------------------------------------------------------------------------- | | `adl_spec` | §4 | Spec version; selects the JSON Schema used for validation (§1.1.2). | | `id` | §6 | The agent's stable identifier — an HTTPS URI or URN — resolved to an authoritative key (§1.1.3). | | `cryptographic_identity.did` | §6.3 | A `did:web` identifier resolved to a DID Document that supplies the verification key (§1.1.3). | | `cryptographic_identity.public_key` | §6.3 | Inline public key (`algorithm`, `value`), cross-checked against the resolved key (§1.1.4). | | `security.attestation` | §10.2 | Attestation envelope (`type`, `issuer`, `issued_at`, `expires_at`) carrying the signature and its validity window (§1.1.5–§1.1.6). | | `security.attestation.signature` | §10.2 | The cryptographic signature over the JCS-canonical document, verified in §1.1.5 (`algorithm`, `value`, `signed_content`). | | `lifecycle.status` | §5.6 | `active` / `deprecated` / `retired` / `draft`; gates whether the agent may be provisioned (§1.1.7). | | `provider` | §6 | The publisher's identity, checked for coherence with the signing authority (§1.1.8). | | `permissions`, `data_classification` | §9, §10.1 | The agent's declared access surface and sensitivity, applied when it is invoked (§1.1.9). | | `security.scopes` | §10.4.1 | The agent's standing authorization ceiling for agent-to-agent calls (§2.2). | A passport is **verifiable** when it carries a resolvable `id` (or `cryptographic_identity.did`) together with a `security.attestation.signature`. An ADL document that lacks these can still be consumed as a description, but cannot be cryptographically verified as a passport — §1.1.3 treats a URN-only, unsigned document as Trust-On-First-Use. ## 1 Authentication (Agent-to-Agent)[​](#1-authentication-agent-to-agent "Direct link to 1 Authentication (Agent-to-Agent)") This section defines the agent-to-agent authentication path: how a counterparty verifies an ADL passport (§1.1) and binds it to a specific request via a presentation proof (§1.2). The complementary human/external-service path — the declarative credential schemes carried in `security.authentication` — is defined in [ADL Core §10.3.3](/spec/next#1033-credential-schemes). The procedures in §1.1 and §1.2 are procedural rather than declarative: they describe what counterparties **MUST** do when receiving an ADL passport, and apply regardless of whether the passport declares `security.authentication`. ### 1.1 Passport Verification Procedure[​](#11-passport-verification-procedure "Direct link to 1.1 Passport Verification Procedure") When a counterparty receives an ADL document — whether through peer exchange, a discovery endpoint (§6.4), a registry, or any other channel — and intends to act on its declarations (provision the agent, route requests to it, grant access, or treat it as authoritative), the counterparty **MUST** perform the verification procedure defined in this section before relying on any declaration in the document. The procedure is layered: each step gates the next. An implementation **MUST NOT** skip earlier steps to reach later ones, and **MUST NOT** treat a partial verification as sufficient unless this section explicitly allows it. ![Top-to-bottom activity diagram of the ten-gate passport verification procedure. An incoming ADL passport enters a vertical sequence of gates, each of which must pass before the next runs: retrieval integrity, schema validation, identity resolution, public-key cross-check, signature verification, temporal validity, lifecycle gating, provider-identity coherence, and permission and classification compatibility, ending in the verification outcome. A reject rail down the right side catches any gate that fails and sends the document to a single rejected outcome whose declarations must not be acted upon. Two branch callouts on the left show that a URN-only or unsigned document drops to Trust-On-First-Use rather than failing, and a deprecated lifecycle status warns but may continue. Passing all ten gates yields a verified outcome at the bottom.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHZpZXdCb3g9IjAgMCA5MDAgNzIwIiB3aWR0aD0iOTAwIiBoZWlnaHQ9IjcyMCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsbGVkYnk9InZwLXRpdGxlIHZwLWRlc2MiIGZvbnQtZmFtaWx5PSItYXBwbGUtc3lzdGVtLCBCbGlua01hY1N5c3RlbUZvbnQsICdTZWdvZSBVSScsIEhlbHZldGljYSwgQXJpYWwsIHNhbnMtc2VyaWYiPgogIDx0aXRsZSBpZD0idnAtdGl0bGUiPlBhc3Nwb3J0IHZlcmlmaWNhdGlvbiBwaXBlbGluZTogdGVuIGdhdGVkIHN0ZXBzLCBlYWNoIGdhdGluZyB0aGUgbmV4dDwvdGl0bGU+CiAgPGRlc2MgaWQ9InZwLWRlc2MiPkEgdG9wLXRvLWJvdHRvbSBhY3Rpdml0eSBkaWFncmFtIG9mIHRoZSBwYXNzcG9ydCB2ZXJpZmljYXRpb24gcHJvY2VkdXJlLiBBbiBpbmNvbWluZyBBREwgcGFzc3BvcnQgZW50ZXJzIGEgdmVydGljYWwgc2VxdWVuY2Ugb2YgdGVuIGdhdGVzLCBlYWNoIG9mIHdoaWNoIG11c3QgcGFzcyBiZWZvcmUgdGhlIG5leHQgcnVuczogcmV0cmlldmFsIGludGVncml0eSwgc2NoZW1hIHZhbGlkYXRpb24sIGlkZW50aXR5IHJlc29sdXRpb24sIHB1YmxpYy1rZXkgY3Jvc3MtY2hlY2ssIHNpZ25hdHVyZSB2ZXJpZmljYXRpb24sIHRlbXBvcmFsIHZhbGlkaXR5LCBsaWZlY3ljbGUgZ2F0aW5nLCBwcm92aWRlci1pZGVudGl0eSBjb2hlcmVuY2UsIGFuZCBwZXJtaXNzaW9uIGFuZCBjbGFzc2lmaWNhdGlvbiBjb21wYXRpYmlsaXR5LCBlbmRpbmcgaW4gdGhlIHZlcmlmaWNhdGlvbiBvdXRjb21lLiBUaGUgcHJvY2VkdXJlIGlzIGxheWVyZWQ6IGFuIGltcGxlbWVudGF0aW9uIG11c3Qgbm90IHNraXAgYW4gZWFybGllciBzdGVwIHRvIHJlYWNoIGEgbGF0ZXIgb25lLiBUd28gYnJhbmNoIHBvaW50cyBhcmUgc2hvd246IGF0IGlkZW50aXR5IHJlc29sdXRpb24sIGEgVVJOLW9ubHkgb3IgdW5zaWduZWQgZG9jdW1lbnQgZHJvcHMgdG8gVHJ1c3QtT24tRmlyc3QtVXNlIHJhdGhlciB0aGFuIGZhaWxpbmc7IGF0IGxpZmVjeWNsZSBnYXRpbmcsIGEgZGVwcmVjYXRlZCBzdGF0dXMgd2FybnMgYnV0IG1heSBjb250aW51ZSB3aGlsZSByZXRpcmVkIG9yIGRyYWZ0IGlzIHJlamVjdGVkLiBBIHJlamVjdCByYWlsIHJ1bnMgZG93biB0aGUgcmlnaHQgc2lkZTogYW55IGdhdGUgdGhhdCBmYWlscyBzZW5kcyB0aGUgZG9jdW1lbnQgdG8gYSBzaW5nbGUgcmVqZWN0ZWQgb3V0Y29tZSBvbiB0aGUgcmlnaHQsIGFuZCBpdHMgZGVjbGFyYXRpb25zIG11c3Qgbm90IGJlIGFjdGVkIHVwb24uIFBhc3NpbmcgYWxsIHRlbiBnYXRlcyB5aWVsZHMgYSB2ZXJpZmllZCBvdXRjb21lIGF0IHRoZSBib3R0b20uPC9kZXNjPgoKICA8ZGVmcz4KICAgIDxtYXJrZXIgaWQ9InZwLWFyIiB2aWV3Qm94PSIwIDAgMTAgMTAiIHJlZlg9IjkiIHJlZlk9IjUiIG1hcmtlcldpZHRoPSI3IiBtYXJrZXJIZWlnaHQ9IjciIG9yaWVudD0iYXV0by1zdGFydC1yZXZlcnNlIj4KICAgICAgPHBhdGggZD0iTTAsMCBMMTAsNSBMMCwxMCB6IiBmaWxsPSIjMzM0MTU1Ii8+CiAgICA8L21hcmtlcj4KICAgIDxtYXJrZXIgaWQ9InZwLWFyLXJlZCIgdmlld0JveD0iMCAwIDEwIDEwIiByZWZYPSI5IiByZWZZPSI1IiBtYXJrZXJXaWR0aD0iNyIgbWFya2VySGVpZ2h0PSI3IiBvcmllbnQ9ImF1dG8tc3RhcnQtcmV2ZXJzZSI+CiAgICAgIDxwYXRoIGQ9Ik0wLDAgTDEwLDUgTDAsMTAgeiIgZmlsbD0iI2M1MjIxZiIvPgogICAgPC9tYXJrZXI+CiAgICA8bWFya2VyIGlkPSJ2cC1hci1hbWJlciIgdmlld0JveD0iMCAwIDEwIDEwIiByZWZYPSI5IiByZWZZPSI1IiBtYXJrZXJXaWR0aD0iNyIgbWFya2VySGVpZ2h0PSI3IiBvcmllbnQ9ImF1dG8tc3RhcnQtcmV2ZXJzZSI+CiAgICAgIDxwYXRoIGQ9Ik0wLDAgTDEwLDUgTDAsMTAgeiIgZmlsbD0iI2Y1OWUwYiIvPgogICAgPC9tYXJrZXI+CiAgPC9kZWZzPgoKICA8cmVjdCB4PSIwIiB5PSIwIiB3aWR0aD0iOTAwIiBoZWlnaHQ9IjcyMCIgZmlsbD0iI2ZmZmZmZiIvPgoKICA8IS0tIFRpdGxlIC0tPgogIDx0ZXh0IHg9IjQ1MCIgeT0iMzQiIHRleHQtYW5jaG9yPSJtaWRkbGUiIGZvbnQtc2l6ZT0iMjAiIGZvbnQtd2VpZ2h0PSI3MDAiIGZpbGw9IiMwZjE3MmEiPlBhc3Nwb3J0IFZlcmlmaWNhdGlvbiBQaXBlbGluZTwvdGV4dD4KICA8dGV4dCB4PSI0NTAiIHk9IjU2IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBmb250LXNpemU9IjEzIiBmb250LXN0eWxlPSJpdGFsaWMiIGZpbGw9IiM0NzU1NjkiPlRlbiBnYXRlZCBzdGVwcyAoJiMxNjc7MS4xLjEmIzgyMTE7JiMxNjc7MS4xLjEwKSAmIzgyMTI7IGVhY2ggZ2F0ZSBnYXRlcyB0aGUgbmV4dDsgbm8gc3RlcCBtYXkgYmUgc2tpcHBlZDwvdGV4dD4KCiAgPCEtLSBpbmNvbWluZyAtLT4KICA8cmVjdCB4PSIyNTAiIHk9Ijc4IiB3aWR0aD0iMjAwIiBoZWlnaHQ9IjM0IiByeD0iMTciIGZpbGw9IiNlOGYwZmUiIHN0cm9rZT0iIzFhNzNlOCIgc3Ryb2tlLXdpZHRoPSIxLjUiLz4KICA8dGV4dCB4PSIzNTAiIHk9IjEwMCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgZm9udC1zaXplPSIxMiIgZm9udC13ZWlnaHQ9IjcwMCIgZmlsbD0iIzBiNTdkMCI+aW5jb21pbmcgQURMIHBhc3Nwb3J0PC90ZXh0PgoKICA8IS0tIHJlamVjdCByYWlsIHRhcmdldCAocmlnaHQpIC0tPgogIDxyZWN0IHg9IjY5MCIgeT0iMzMyIiB3aWR0aD0iMTUwIiBoZWlnaHQ9IjU2IiByeD0iMTAiIGZpbGw9IiNmY2U4ZTYiIHN0cm9rZT0iI2M1MjIxZiIgc3Ryb2tlLXdpZHRoPSIxLjc1Ii8+CiAgPHRleHQgeD0iNzY1IiB5PSIzNTYiIHRleHQtYW5jaG9yPSJtaWRkbGUiIGZvbnQtc2l6ZT0iMTMiIGZvbnQtd2VpZ2h0PSI3MDAiIGZpbGw9IiNhNTBlMGUiPlJFSkVDVEVEPC90ZXh0PgogIDx0ZXh0IHg9Ijc2NSIgeT0iMzc0IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBmb250LXNpemU9IjkuNSIgZmlsbD0iIzFmMjkzNyI+ZGVjbGFyYXRpb25zIG5vdCBhY3RlZCB1cG9uPC90ZXh0PgoKICA8IS0tIHZlcnRpY2FsIGdhdGVzOiB4IGNlbnRlciAzNTAsIGVhY2ggMjAwIHdpZGUsIDQwIHRhbGwsIHNwYWNlZCA1NCAtLT4KICA8IS0tIGhlbHBlcjogZ2F0ZSByb3dzIC0tPgogIDwhLS0gMSAtLT4KICA8cmVjdCB4PSIyNTAiIHk9IjEyNCIgd2lkdGg9IjIwMCIgaGVpZ2h0PSI0MCIgcng9IjgiIGZpbGw9IiNmOGZhZmMiIHN0cm9rZT0iIzY0NzQ4YiIgc3Ryb2tlLXdpZHRoPSIxLjQiLz4KICA8dGV4dCB4PSIzNTAiIHk9IjE0MyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgZm9udC1zaXplPSIxMS41IiBmb250LXdlaWdodD0iNzAwIiBmaWxsPSIjMGYxNzJhIj4xICYjMTgzOyBSZXRyaWV2YWwgaW50ZWdyaXR5PC90ZXh0PgogIDx0ZXh0IHg9IjM1MCIgeT0iMTU3IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBmb250LXNpemU9IjkiIGZpbGw9IiM0NzU1NjkiPkhUVFBTICsgVExTICYjMTgzOyBwcm92ZW5hbmNlPC90ZXh0PgoKICA8cmVjdCB4PSIyNTAiIHk9IjE3OCIgd2lkdGg9IjIwMCIgaGVpZ2h0PSI0MCIgcng9IjgiIGZpbGw9IiNmOGZhZmMiIHN0cm9rZT0iIzY0NzQ4YiIgc3Ryb2tlLXdpZHRoPSIxLjQiLz4KICA8dGV4dCB4PSIzNTAiIHk9IjE5NyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgZm9udC1zaXplPSIxMS41IiBmb250LXdlaWdodD0iNzAwIiBmaWxsPSIjMGYxNzJhIj4yICYjMTgzOyBTY2hlbWEgdmFsaWRhdGlvbjwvdGV4dD4KICA8dGV4dCB4PSIzNTAiIHk9IjIxMSIgdGV4dC1hbmNob3I9Im1pZGRsZSIgZm9udC1zaXplPSI5IiBmaWxsPSIjNDc1NTY5Ij5hZ2FpbnN0IHRoZSBhZGxfc3BlYyBzY2hlbWE8L3RleHQ+CgogIDxyZWN0IHg9IjI1MCIgeT0iMjMyIiB3aWR0aD0iMjAwIiBoZWlnaHQ9IjQwIiByeD0iOCIgZmlsbD0iI2Y4ZmFmYyIgc3Ryb2tlPSIjNjQ3NDhiIiBzdHJva2Utd2lkdGg9IjEuNCIvPgogIDx0ZXh0IHg9IjM1MCIgeT0iMjUxIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBmb250LXNpemU9IjExLjUiIGZvbnQtd2VpZ2h0PSI3MDAiIGZpbGw9IiMwZjE3MmEiPjMgJiMxODM7IElkZW50aXR5IHJlc29sdXRpb248L3RleHQ+CiAgPHRleHQgeD0iMzUwIiB5PSIyNjUiIHRleHQtYW5jaG9yPSJtaWRkbGUiIGZvbnQtc2l6ZT0iOSIgZmlsbD0iIzQ3NTU2OSI+aWQgLyBkaWQ6d2ViICYjODU5NDsgYXV0aG9yaXRhdGl2ZSBrZXk8L3RleHQ+CgogIDxyZWN0IHg9IjI1MCIgeT0iMjg2IiB3aWR0aD0iMjAwIiBoZWlnaHQ9IjQwIiByeD0iOCIgZmlsbD0iI2Y4ZmFmYyIgc3Ryb2tlPSIjNjQ3NDhiIiBzdHJva2Utd2lkdGg9IjEuNCIvPgogIDx0ZXh0IHg9IjM1MCIgeT0iMzA1IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBmb250LXNpemU9IjExLjUiIGZvbnQtd2VpZ2h0PSI3MDAiIGZpbGw9IiMwZjE3MmEiPjQgJiMxODM7IFB1YmxpYy1rZXkgY3Jvc3MtY2hlY2s8L3RleHQ+CiAgPHRleHQgeD0iMzUwIiB5PSIzMTkiIHRleHQtYW5jaG9yPSJtaWRkbGUiIGZvbnQtc2l6ZT0iOSIgZmlsbD0iIzQ3NTU2OSI+aW5saW5lIGtleSA9PSByZXNvbHZlZCBrZXk8L3RleHQ+CgogIDxyZWN0IHg9IjI1MCIgeT0iMzQwIiB3aWR0aD0iMjAwIiBoZWlnaHQ9IjQwIiByeD0iOCIgZmlsbD0iI2Y4ZmFmYyIgc3Ryb2tlPSIjNjQ3NDhiIiBzdHJva2Utd2lkdGg9IjEuNCIvPgogIDx0ZXh0IHg9IjM1MCIgeT0iMzU5IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBmb250LXNpemU9IjExLjUiIGZvbnQtd2VpZ2h0PSI3MDAiIGZpbGw9IiMwZjE3MmEiPjUgJiMxODM7IFNpZ25hdHVyZSB2ZXJpZmljYXRpb248L3RleHQ+CiAgPHRleHQgeD0iMzUwIiB5PSIzNzMiIHRleHQtYW5jaG9yPSJtaWRkbGUiIGZvbnQtc2l6ZT0iOSIgZmlsbD0iIzQ3NTU2OSI+SkNTLWNhbm9uaWNhbCAmIzE4MzsgJiMxNjc7MTAuMjwvdGV4dD4KCiAgPHJlY3QgeD0iMjUwIiB5PSIzOTQiIHdpZHRoPSIyMDAiIGhlaWdodD0iNDAiIHJ4PSI4IiBmaWxsPSIjZjhmYWZjIiBzdHJva2U9IiM2NDc0OGIiIHN0cm9rZS13aWR0aD0iMS40Ii8+CiAgPHRleHQgeD0iMzUwIiB5PSI0MTMiIHRleHQtYW5jaG9yPSJtaWRkbGUiIGZvbnQtc2l6ZT0iMTEuNSIgZm9udC13ZWlnaHQ9IjcwMCIgZmlsbD0iIzBmMTcyYSI+NiAmIzE4MzsgVGVtcG9yYWwgdmFsaWRpdHk8L3RleHQ+CiAgPHRleHQgeD0iMzUwIiB5PSI0MjciIHRleHQtYW5jaG9yPSJtaWRkbGUiIGZvbnQtc2l6ZT0iOSIgZmlsbD0iIzQ3NTU2OSI+YXR0ZXN0YXRpb24gbm90IGV4cGlyZWQ8L3RleHQ+CgogIDxyZWN0IHg9IjI1MCIgeT0iNDQ4IiB3aWR0aD0iMjAwIiBoZWlnaHQ9IjQwIiByeD0iOCIgZmlsbD0iI2Y4ZmFmYyIgc3Ryb2tlPSIjNjQ3NDhiIiBzdHJva2Utd2lkdGg9IjEuNCIvPgogIDx0ZXh0IHg9IjM1MCIgeT0iNDY3IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBmb250LXNpemU9IjExLjUiIGZvbnQtd2VpZ2h0PSI3MDAiIGZpbGw9IiMwZjE3MmEiPjcgJiMxODM7IExpZmVjeWNsZSBnYXRpbmc8L3RleHQ+CiAgPHRleHQgeD0iMzUwIiB5PSI0ODEiIHRleHQtYW5jaG9yPSJtaWRkbGUiIGZvbnQtc2l6ZT0iOSIgZmlsbD0iIzQ3NTU2OSI+YWN0aXZlIC8gZGVwcmVjYXRlZCAvIHJldGlyZWQgLyBkcmFmdDwvdGV4dD4KCiAgPHJlY3QgeD0iMjUwIiB5PSI1MDIiIHdpZHRoPSIyMDAiIGhlaWdodD0iNDAiIHJ4PSI4IiBmaWxsPSIjZjhmYWZjIiBzdHJva2U9IiM2NDc0OGIiIHN0cm9rZS13aWR0aD0iMS40Ii8+CiAgPHRleHQgeD0iMzUwIiB5PSI1MjEiIHRleHQtYW5jaG9yPSJtaWRkbGUiIGZvbnQtc2l6ZT0iMTEuNSIgZm9udC13ZWlnaHQ9IjcwMCIgZmlsbD0iIzBmMTcyYSI+OCAmIzE4MzsgUHJvdmlkZXIgY29oZXJlbmNlPC90ZXh0PgogIDx0ZXh0IHg9IjM1MCIgeT0iNTM1IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBmb250LXNpemU9IjkiIGZpbGw9IiM0NzU1NjkiPnNpZ25lciBhbGlnbnMgd2l0aCBwcm92aWRlcjwvdGV4dD4KCiAgPHJlY3QgeD0iMjUwIiB5PSI1NTYiIHdpZHRoPSIyMDAiIGhlaWdodD0iNDAiIHJ4PSI4IiBmaWxsPSIjZjhmYWZjIiBzdHJva2U9IiM2NDc0OGIiIHN0cm9rZS13aWR0aD0iMS40Ii8+CiAgPHRleHQgeD0iMzUwIiB5PSI1NzUiIHRleHQtYW5jaG9yPSJtaWRkbGUiIGZvbnQtc2l6ZT0iMTEuNSIgZm9udC13ZWlnaHQ9IjcwMCIgZmlsbD0iIzBmMTcyYSI+OSAmIzE4MzsgUGVybWlzc2lvbiAmYW1wOyBjbGFzcy48L3RleHQ+CiAgPHRleHQgeD0iMzUwIiB5PSI1ODkiIHRleHQtYW5jaG9yPSJtaWRkbGUiIGZvbnQtc2l6ZT0iOSIgZmlsbD0iIzQ3NTU2OSI+ZGVueS1ieS1kZWZhdWx0ICYjMTgzOyBkYXRhIGNsYXNzPC90ZXh0PgoKICA8IS0tIDEwIG91dGNvbWUgLS0+CiAgPHJlY3QgeD0iMjUwIiB5PSI2MjQiIHdpZHRoPSIyMDAiIGhlaWdodD0iNDQiIHJ4PSIxMCIgZmlsbD0iI2U2ZjRlYSIgc3Ryb2tlPSIjMTM3MzMzIiBzdHJva2Utd2lkdGg9IjEuNzUiLz4KICA8dGV4dCB4PSIzNTAiIHk9IjY0MyIgdGV4dC1hbmNob3I9Im1pZGRsZSIgZm9udC1zaXplPSIxMi41IiBmb250LXdlaWdodD0iNzAwIiBmaWxsPSIjMGQ2NTJkIj4xMCAmIzE4MzsgVkVSSUZJRUQ8L3RleHQ+CiAgPHRleHQgeD0iMzUwIiB5PSI2NTkiIHRleHQtYW5jaG9yPSJtaWRkbGUiIGZvbnQtc2l6ZT0iOSIgZmlsbD0iIzFmMjkzNyI+b3V0Y29tZSByZWNvcmRlZDsgZGVjbGFyYXRpb25zIHRydXN0ZWQ8L3RleHQ+CgogIDwhLS0gdmVydGljYWwgZ2F0aW5nIGFycm93cyBiZXR3ZWVuIHN0ZXBzICh4PTM1MCkgLS0+CiAgPGxpbmUgeDE9IjM1MCIgeTE9IjExMiIgeDI9IjM1MCIgeTI9IjEyNCIgc3Ryb2tlPSIjMzM0MTU1IiBzdHJva2Utd2lkdGg9IjEuNCIgbWFya2VyLWVuZD0idXJsKCN2cC1hcikiLz4KICA8bGluZSB4MT0iMzUwIiB5MT0iMTY0IiB4Mj0iMzUwIiB5Mj0iMTc4IiBzdHJva2U9IiMzMzQxNTUiIHN0cm9rZS13aWR0aD0iMS40IiBtYXJrZXItZW5kPSJ1cmwoI3ZwLWFyKSIvPgogIDxsaW5lIHgxPSIzNTAiIHkxPSIyMTgiIHgyPSIzNTAiIHkyPSIyMzIiIHN0cm9rZT0iIzMzNDE1NSIgc3Ryb2tlLXdpZHRoPSIxLjQiIG1hcmtlci1lbmQ9InVybCgjdnAtYXIpIi8+CiAgPGxpbmUgeDE9IjM1MCIgeTE9IjI3MiIgeDI9IjM1MCIgeTI9IjI4NiIgc3Ryb2tlPSIjMzM0MTU1IiBzdHJva2Utd2lkdGg9IjEuNCIgbWFya2VyLWVuZD0idXJsKCN2cC1hcikiLz4KICA8bGluZSB4MT0iMzUwIiB5MT0iMzI2IiB4Mj0iMzUwIiB5Mj0iMzQwIiBzdHJva2U9IiMzMzQxNTUiIHN0cm9rZS13aWR0aD0iMS40IiBtYXJrZXItZW5kPSJ1cmwoI3ZwLWFyKSIvPgogIDxsaW5lIHgxPSIzNTAiIHkxPSIzODAiIHgyPSIzNTAiIHkyPSIzOTQiIHN0cm9rZT0iIzMzNDE1NSIgc3Ryb2tlLXdpZHRoPSIxLjQiIG1hcmtlci1lbmQ9InVybCgjdnAtYXIpIi8+CiAgPGxpbmUgeDE9IjM1MCIgeTE9IjQzNCIgeDI9IjM1MCIgeTI9IjQ0OCIgc3Ryb2tlPSIjMzM0MTU1IiBzdHJva2Utd2lkdGg9IjEuNCIgbWFya2VyLWVuZD0idXJsKCN2cC1hcikiLz4KICA8bGluZSB4MT0iMzUwIiB5MT0iNDg4IiB4Mj0iMzUwIiB5Mj0iNTAyIiBzdHJva2U9IiMzMzQxNTUiIHN0cm9rZS13aWR0aD0iMS40IiBtYXJrZXItZW5kPSJ1cmwoI3ZwLWFyKSIvPgogIDxsaW5lIHgxPSIzNTAiIHkxPSI1NDIiIHgyPSIzNTAiIHkyPSI1NTYiIHN0cm9rZT0iIzMzNDE1NSIgc3Ryb2tlLXdpZHRoPSIxLjQiIG1hcmtlci1lbmQ9InVybCgjdnAtYXIpIi8+CiAgPGxpbmUgeDE9IjM1MCIgeTE9IjU5NiIgeDI9IjM1MCIgeTI9IjYyNCIgc3Ryb2tlPSIjMzM0MTU1IiBzdHJva2Utd2lkdGg9IjEuNCIgbWFya2VyLWVuZD0idXJsKCN2cC1hcikiLz4KICA8dGV4dCB4PSIzNTgiIHk9IjYxMyIgdGV4dC1hbmNob3I9InN0YXJ0IiBmb250LXNpemU9IjkiIGZpbGw9IiMxMzczMzMiPmFsbCBnYXRlcyBwYXNzPC90ZXh0PgoKICA8IS0tIHJlamVjdCByYWlsOiBvbmUgY29udGludW91cyBzb2xpZCBicmFja2V0IGVtYnJhY2luZyBhbGwgbmluZSBnYXRlcyAtPiBhbnkgZ2F0ZSBmYWlscyAtPiBSRUpFQ1RFRCAtLT4KICA8bGluZSB4MT0iNDU1IiB5MT0iMTQ0IiB4Mj0iNjAwIiB5Mj0iMTQ0IiBzdHJva2U9IiNjNTIyMWYiIHN0cm9rZS13aWR0aD0iMS41Ii8+CiAgPGxpbmUgeDE9IjYwMCIgeTE9IjE0NCIgeDI9IjYwMCIgeTI9IjU3NiIgc3Ryb2tlPSIjYzUyMjFmIiBzdHJva2Utd2lkdGg9IjEuNSIvPgogIDxsaW5lIHgxPSI0NTUiIHkxPSI1NzYiIHgyPSI2MDAiIHkyPSI1NzYiIHN0cm9rZT0iI2M1MjIxZiIgc3Ryb2tlLXdpZHRoPSIxLjUiLz4KICA8bGluZSB4MT0iNjAwIiB5MT0iMzYwIiB4Mj0iNjg4IiB5Mj0iMzYwIiBzdHJva2U9IiNjNTIyMWYiIHN0cm9rZS13aWR0aD0iMS42IiBtYXJrZXItZW5kPSJ1cmwoI3ZwLWFyLXJlZCkiLz4KICA8cmVjdCB4PSI2MDYiIHk9IjM0MCIgd2lkdGg9Ijc2IiBoZWlnaHQ9IjE0IiBmaWxsPSIjZmZmZmZmIi8+CiAgPHRleHQgeD0iNjQ0IiB5PSIzNTEiIHRleHQtYW5jaG9yPSJtaWRkbGUiIGZvbnQtc2l6ZT0iOS41IiBmb250LXdlaWdodD0iNzAwIiBmaWxsPSIjYTUwZTBlIj5hbnkgZ2F0ZSBmYWlsczwvdGV4dD4KCiAgPCEtLSBicmFuY2ggY2FsbG91dHMgKGxlZnQgc2lkZSkgLS0+CiAgPCEtLSBVUk4tb25seSAtPiBUT0ZVIGF0IHN0ZXAgMyAtLT4KICA8cmVjdCB4PSI0MCIgeT0iMjM1IiB3aWR0aD0iMTkwIiBoZWlnaHQ9IjM0IiByeD0iOCIgZmlsbD0iI2ZmZjdlNiIgc3Ryb2tlPSIjZjU5ZTBiIiBzdHJva2Utd2lkdGg9IjEuMyIvPgogIDx0ZXh0IHg9IjEzNSIgeT0iMjQ5IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBmb250LXNpemU9IjkuNSIgZm9udC13ZWlnaHQ9IjcwMCIgZmlsbD0iI2I0NTMwOSI+VVJOLW9ubHkgLyB1bnNpZ25lZDwvdGV4dD4KICA8dGV4dCB4PSIxMzUiIHk9IjI2MiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgZm9udC1zaXplPSI5IiBmaWxsPSIjOTI3MjJmIj4mIzg1OTQ7IFRydXN0LU9uLUZpcnN0LVVzZSAobm90IHJlamVjdCk8L3RleHQ+CiAgPGxpbmUgeDE9IjIzMCIgeTE9IjI1MiIgeDI9IjI0OCIgeTI9IjI1MiIgc3Ryb2tlPSIjZjU5ZTBiIiBzdHJva2Utd2lkdGg9IjEuMyIgbWFya2VyLWVuZD0idXJsKCN2cC1hci1hbWJlcikiLz4KCiAgPCEtLSBkZXByZWNhdGVkIC0+IHdhcm4gYXQgc3RlcCA3IC0tPgogIDxyZWN0IHg9IjQwIiB5PSI0NTEiIHdpZHRoPSIxOTAiIGhlaWdodD0iMzQiIHJ4PSI4IiBmaWxsPSIjZmZmN2U2IiBzdHJva2U9IiNmNTllMGIiIHN0cm9rZS13aWR0aD0iMS4zIi8+CiAgPHRleHQgeD0iMTM1IiB5PSI0NjUiIHRleHQtYW5jaG9yPSJtaWRkbGUiIGZvbnQtc2l6ZT0iOS41IiBmb250LXdlaWdodD0iNzAwIiBmaWxsPSIjYjQ1MzA5Ij5kZXByZWNhdGVkPC90ZXh0PgogIDx0ZXh0IHg9IjEzNSIgeT0iNDc4IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBmb250LXNpemU9IjkiIGZpbGw9IiM5MjcyMmYiPiYjODU5NDsgd2FybiwgTUFZIGNvbnRpbnVlPC90ZXh0PgogIDxsaW5lIHgxPSIyMzAiIHkxPSI0NjgiIHgyPSIyNDgiIHkyPSI0NjgiIHN0cm9rZT0iI2Y1OWUwYiIgc3Ryb2tlLXdpZHRoPSIxLjMiIG1hcmtlci1lbmQ9InVybCgjdnAtYXItYW1iZXIpIi8+CgogIDwhLS0gZm9vdG5vdGUgLS0+CiAgPHRleHQgeD0iNDUwIiB5PSI3MDAiIHRleHQtYW5jaG9yPSJtaWRkbGUiIGZvbnQtc2l6ZT0iMTEiIGZvbnQtc3R5bGU9Iml0YWxpYyIgZmlsbD0iIzQ3NTU2OSI+VGhlIHByb2NlZHVyZSBpcyBsYXllcmVkIGFuZCBkZXRlcm1pbmlzdGljOiB0aGUgc2FtZSBwYXNzcG9ydCB5aWVsZHMgdGhlIHNhbWUgb3V0Y29tZSBldmVyeSB0aW1lLiBJbGx1c3RyYXRpdmU7ICYjMTY3OzEuMSBpcyBhdXRob3JpdGF0aXZlLjwvdGV4dD4KPC9zdmc+Cg==) *Figure 2 (informative): The verification procedure is a layered pipeline — each gate gates the next, any failure rejects, and the same passport yields the same outcome every time. This figure is illustrative; the normative steps are §1.1.1–§1.1.10 below.* #### 1.1.1 Retrieval Integrity[​](#111-retrieval-integrity "Direct link to 1.1.1 Retrieval Integrity") Before any document-level verification, the counterparty **MUST** establish retrieval integrity: * If the document was retrieved over the network, retrieval **MUST** use HTTPS with full TLS certificate validation per \[RFC9110]. Implementations **MUST NOT** accept ADL documents over plain HTTP from untrusted sources. * If the document was retrieved from a discovery endpoint (§6.4), the discovery endpoint's TLS authority establishes a starting trust anchor for the listed agents. Implementations **SHOULD** record this authority for use in §1.1.3. * If the document was retrieved from local storage, an internal registry, or an air-gapped channel, the counterparty **MUST** record the provenance (path, registry name, channel identifier) for downstream auditing. Such documents **SHOULD** still be cryptographically verified per the remaining steps in this section. #### 1.1.2 Schema Validation[​](#112-schema-validation "Direct link to 1.1.2 Schema Validation") The counterparty **MUST** validate the document against the ADL JSON Schema for the version declared in `adl_spec`. Documents that fail schema validation **MUST** be rejected; their declarations **MUST NOT** be acted upon. This step gates all subsequent verification because subsequent steps assume the document's structure conforms to the schema. #### 1.1.3 Identity Resolution[​](#113-identity-resolution "Direct link to 1.1.3 Identity Resolution") If the document declares an `id` or `cryptographic_identity.did`, the counterparty **MUST** resolve it to an authoritative public key using the procedure appropriate for the identifier scheme: * **HTTPS URI `id`** — The counterparty **MUST** dereference the `id` URL over HTTPS. The fetched document **MUST** match the document being verified by canonical byte sequence (per §10.2 / \[RFC8785]). If the canonical byte sequences do not match, the document being verified is not the authoritative version published at the canonical URL and **MUST** be rejected unless the counterparty has out-of-band reason to accept it (e.g., a known mirror with an integrity record). * **`did:web` `cryptographic_identity.did`** — The counterparty **MUST** resolve the DID by fetching `https://{domain}/.well-known/did.json` for top-level identifiers, or `https://{domain}/{path-segments}/did.json` for path-based identifiers, per the `did:web` method specification \[W3C.DID-WEB]. The fetched DID Document **MUST** be served over HTTPS with full certificate validation. The counterparty **MUST** extract the public key designated by the DID Document's `assertionMethod` verification relationship. If `assertionMethod` is absent or unresolvable, verification **MUST** fail. * **URN `id`** — URN identifiers do not resolve. If the document declares only a URN identifier, the counterparty **MUST NOT** rely on the URN for identity verification. The counterparty **MAY** still perform §1.1.5 (signature verification) using the inline `cryptographic_identity.public_key`, but **MUST** treat the result as Trust-On-First-Use and **MUST NOT** elevate the document's declarations to a higher trust tier than the channel that delivered it. #### 1.1.4 Public Key Cross-Check[​](#114-public-key-cross-check "Direct link to 1.1.4 Public Key Cross-Check") When both an inline `cryptographic_identity.public_key` and a resolved authoritative public key (from §1.1.3) are available, the counterparty **MUST** cross-check them: * The `algorithm` values **MUST** match. * The `value` byte sequences (after base64 decoding) **MUST** be identical. If the cross-check fails, the document **MUST** be rejected. A mismatch indicates either document tampering after signing or a misconfigured publisher; in either case, the document cannot be trusted. When only one public key source is available (e.g., URN-only identifier with inline key, or DID-only identifier without inline key), the counterparty **MUST** record which source was used and **MAY** apply additional policy (such as requiring human review) before acting on the document's declarations. #### 1.1.5 Signature Verification[​](#115-signature-verification "Direct link to 1.1.5 Signature Verification") If the document contains `security.attestation.signature`, the counterparty **MUST** verify it per §10.2: 1. Construct the verification payload by removing the `signature` object from `security.attestation` (preserving all other fields). 2. Serialize the resulting document using JCS \[RFC8785]. 3. If `signed_content` is `"digest"`, compute the digest using `digest_algorithm` and compare to `digest_value`; reject on mismatch. 4. Verify the signature `value` against the canonical byte sequence (or its digest) using the algorithm in `signature.algorithm` and the public key established in §1.1.3 / §1.1.4. A document that claims a signature but fails verification **MUST** be rejected. A document with no signature **MAY** be accepted only if the counterparty's policy permits unsigned documents from the document's retrieval channel. #### 1.1.6 Temporal Validity[​](#116-temporal-validity "Direct link to 1.1.6 Temporal Validity") The counterparty **MUST** check the attestation's temporal validity: * If `security.attestation.expires_at` is in the past, the document **MUST** be rejected unless the counterparty's policy explicitly permits expired attestations (e.g., for offline forensic analysis). * Implementations **SHOULD** warn when `expires_at` is within 30 days of the current time, per §10.2. #### 1.1.7 Lifecycle Gating[​](#117-lifecycle-gating "Direct link to 1.1.7 Lifecycle Gating") The counterparty **MUST** check `lifecycle.status` per §5.6: * `retired` — The counterparty **MUST NOT** provision, route to, or otherwise rely on the agent. Verification fails at this step. * `deprecated` — The counterparty **SHOULD** warn (including `sunset_date` and `successor` if present) and **MAY** continue. Counterparties **SHOULD NOT** onboard new dependencies on deprecated agents. * `draft` — The counterparty **MUST NOT** provision in production. In development environments, the counterparty **MAY** continue. * `active` — The counterparty **MAY** continue. #### 1.1.8 Provider–Identity Coherence[​](#118-provideridentity-coherence "Direct link to 1.1.8 Provider–Identity Coherence") The counterparty **SHOULD** verify that the signing identity is coherent with the document's declared `provider`: * The TLS authority used in §1.1.1 (for retrieval) and §1.1.3 (for identity resolution) **SHOULD** align with the domain of `provider.url` and the authority component of an HTTPS `id` or the domain segment of a `did:web` identifier. * When the counterparty maintains a provider allowlist (per §18), the signing identity **MUST** match an entry on that allowlist before the document's declarations are acted upon. #### 1.1.9 Permission and Classification Compatibility[​](#119-permission-and-classification-compatibility "Direct link to 1.1.9 Permission and Classification Compatibility") When the counterparty is invoking the agent (rather than merely cataloging it), the counterparty **MUST** apply the deny-by-default permission model (§9) and the data classification rules (§10.1) before completing verification. In particular: * The agent's declared `permissions.network`, `permissions.filesystem`, `permissions.environment`, and `permissions.execution` **MUST** be applied to subsequent tool invocations. * When the counterparty is itself an agent, its own `data_classification.sensitivity` **MUST** be at least as high as the data classification of any tool or resource it invokes on the verified agent. This prevents a `public`-classified agent from accessing `confidential` data exposed by a verified peer. #### 1.1.10 Verification Outcome[​](#1110-verification-outcome "Direct link to 1.1.10 Verification Outcome") A verification result **MUST** record, at minimum: * A boolean overall outcome (`verified` or `not_verified`) * The result of each step (1.1.1 through 1.1.9), including which step failed (if any) * The retrieval channel and trust anchor used * The public key source(s) used (inline, DID-resolved, or both) Implementations that operate in `audit` or `permissive` modes (allowing failed verifications to proceed with logging) **MUST** still record the same structure; the outcome is informational rather than gating in those modes. ### 1.2 Presentation Proof[​](#12-presentation-proof "Direct link to 1.2 Presentation Proof") §1.1 authenticates a passport — does this document genuinely belong to the agent it names? It does not, however, bind the passport to a specific request. A passport that is published at a discoverable URL, shared in a registry, or transmitted over an authenticated channel is replayable: any party that obtains the passport bytes can re-present them as their own for the document's entire validity window. This subsection closes that gap by defining a per-request **presentation proof**, signed by the passport's private key, that binds the passport to a specific request URI, method, and timestamp. The presentation proof is conceptually equivalent to OAuth 2.1's sender-constrained-token mechanism (DPoP, \[RFC9449]) but uses ADL-native primitives (JCS canonicalization per §10.2 + Ed25519 signing) so that ports across languages do not need a JWT toolchain. When an agent acts as the *presenter* of an ADL passport — when it submits its passport in support of a request to a counterparty — it **MUST**, unless §1.2.10 explicitly waives the requirement, produce a presentation proof. When a counterparty acts as the *verifier* of a presentation, it **MUST**, after completing §1.1 verification of the passport, perform the procedure in §1.2.6 before treating the request as authenticated. #### 1.2.1 Threat Model[​](#121-threat-model "Direct link to 1.2.1 Threat Model") The presentation proof addresses a single threat: replay of a previously observed or scraped passport. It assumes: * Passports are not secret. The threat model is that an attacker may obtain a complete, valid, signed passport (from a discovery endpoint, registry, network capture, or copy-pasted disclosure). * The attacker does **not** have access to the corresponding private key. * The verifier and presenter have synchronized clocks within a tolerance specified by §1.2.8. The presentation proof does **not** address private key compromise; that is a key-rotation concern handled at the attestation level (§10.2 `expires_at`) and by operational rotation policies. #### 1.2.2 Proof Document Structure[​](#122-proof-document-structure "Direct link to 1.2.2 Proof Document Structure") A presentation proof **MUST** be a JSON object with the following members: | Member | Type | Required | Description | | ----------- | ---------------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `adl_proof` | string | REQUIRED | Proof format version. **MUST** be `"1.0"` for this specification. | | `iss` | string | REQUIRED | The passport's `id` value. The verifier **MUST** confirm this matches the `id` of the accompanying passport. | | `iat` | string | REQUIRED | ISO 8601 timestamp when the proof was issued. | | `exp` | string | REQUIRED | ISO 8601 timestamp when the proof expires. **MUST NOT** be more than 5 minutes after `iat`. | | `jti` | string | REQUIRED | Globally unique proof identifier (recommended: ULID, UUIDv7, or 128-bit base32 random). Used by verifiers for replay prevention. | | `request` | object | REQUIRED | The request the proof binds to. See §1.2.3. | | `scopes` | array of strings | OPTIONAL | Per-request requested authorization scopes. When present, the verifier **MUST** check that the array is a subset of the presenter's passport-declared ceiling per §2.2. Sender-constrained scope binding analogous to DPoP-bound access tokens. | | `nonce` | string | OPTIONAL | A nonce previously issued by the verifier per §1.2.7. | | `signature` | object | REQUIRED | Ed25519 signature over the JCS-canonical bytes of the proof minus the signature object. Same shape as §10.2 attestation signatures. | #### 1.2.3 Request Binding Object[​](#123-request-binding-object "Direct link to 1.2.3 Request Binding Object") The `request` member binds the proof to a specific request: | Member | Type | Required | Description | | -------- | ------ | ---------------------------- | ------------------------------------------------------------------------------------------------------ | | `method` | string | REQUIRED for HTTP transports | Uppercase HTTP method (`GET`, `POST`, etc.). For non-HTTP transports, **MAY** be the literal `"NONE"`. | | `uri` | string | REQUIRED | The canonical request URI per §1.2.4. | For non-HTTP transports (e.g., A2A over message queues, MCP over stdio), `uri` **MUST** be a stable transport-specific identifier — a topic name, a fully-qualified RPC method, or an A2A skill URI — and `method` **MUST** be `"NONE"`. The intent is that two requests with the same logical target produce the same binding. #### 1.2.4 URI Canonicalization[​](#124-uri-canonicalization "Direct link to 1.2.4 URI Canonicalization") Before producing or verifying a proof, the `request.uri` value **MUST** be canonicalized: 1. The scheme **MUST** be lowercased. 2. The host (if present) **MUST** be lowercased and **MUST NOT** carry a trailing dot. 3. Default ports **MUST** be stripped (port 80 for `http`, 443 for `https`). 4. The path **MUST** be percent-encoding-normalized: unreserved characters (per \[RFC3986]) **MUST** be unencoded, and reserved characters **MUST** use uppercase hex (`%2F`, not `%2f`). 5. The query string, if present, **MUST** be preserved verbatim (order-significant). 6. The fragment **MUST** be omitted (fragments are not transmitted; including one in a proof is a defect). These rules match DPoP §4.2 (`htu`) \[RFC9449] for cross-implementation consistency. #### 1.2.5 Presentation[​](#125-presentation "Direct link to 1.2.5 Presentation") Two presentation modes are defined: **Pull (verifier-initiated retrieval).** The verifier dereferences the passport's `id` URL or `adl_document` URL via HTTPS. No presentation proof is required: the TLS authority that served the document at its canonical URL is the binding, and §1.1.3's URL-equals-document check is sufficient. **Push (presenter-initiated request).** The presenter attaches the passport and a presentation proof to its outgoing request. The proof **MUST** cover the request being made. For HTTP-based push, the presenter **SHOULD** use the following header convention: * `ADL-Passport`: Base64-encoded passport bytes (YAML or JSON). * `ADL-Passport-URL`: Alternative to `ADL-Passport`. Canonical URL the verifier may dereference to retrieve the passport. When both are present, the verifier **MUST** prefer dereferencing. * `ADL-Proof`: Base64-encoded presentation proof JSON. For non-HTTP transports, the presentation proof **MUST** be carried in a transport-appropriate analog (for example, an A2A `proof` field alongside the `passport` field). #### 1.2.6 Verification Procedure[​](#126-verification-procedure "Direct link to 1.2.6 Verification Procedure") ![Two-path comparison converging on one verifier. On the left, an attacker replays a scraped, valid, signed passport alone; because the attacker lacks the agent\'s private key the replay carries no per-request proof, and the verifier rejects it — replay defeated. On the right, the legitimate agent presents the same passport together with a presentation proof: a per-request object binding the passport id (iss) to the request method and canonical URI, an issued-at and short expiry, and a unique jti, all signed by the agent\'s private key. The verifier\'s §1.2.6 checks — issuer match, temporal validity within five minutes, request binding, signature against the passport key, and replay prevention via the jti cache — accept the bound request. The proof binds the passport to one request URI, method, timestamp, and jti, signed by the key the attacker does not have.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHZpZXdCb3g9IjAgMCA5MDAgNTYwIiB3aWR0aD0iOTAwIiBoZWlnaHQ9IjU2MCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsbGVkYnk9InBwLXRpdGxlIHBwLWRlc2MiIGZvbnQtZmFtaWx5PSItYXBwbGUtc3lzdGVtLCBCbGlua01hY1N5c3RlbUZvbnQsICdTZWdvZSBVSScsIEhlbHZldGljYSwgQXJpYWwsIHNhbnMtc2VyaWYiPgogIDx0aXRsZSBpZD0icHAtdGl0bGUiPlByZXNlbnRhdGlvbiBwcm9vZjogYSBwZXItcmVxdWVzdCBzaWduYXR1cmUgYmluZHMgdGhlIHBhc3Nwb3J0IHRvIG9uZSByZXF1ZXN0LCBkZWZlYXRpbmcgcmVwbGF5PC90aXRsZT4KICA8ZGVzYyBpZD0icHAtZGVzYyI+QSB0d28tcGF0aCBjb21wYXJpc29uIGNvbnZlcmdpbmcgb24gb25lIHZlcmlmaWVyLiBQYXNzcG9ydHMgYXJlIG5vdCBzZWNyZXQsIHNvIGFuIGF0dGFja2VyIGNhbiBvYnRhaW4gYSBjb21wbGV0ZSwgdmFsaWQsIHNpZ25lZCBwYXNzcG9ydC4gT24gdGhlIGxlZnQsIHRoZSBhdHRhY2tlciByZXBsYXlzIGEgc2NyYXBlZCBwYXNzcG9ydCBhbG9uZTogaXQgY2FycmllcyBubyBwZXItcmVxdWVzdCBwcm9vZiBiZWNhdXNlIHRoZSBhdHRhY2tlciBsYWNrcyB0aGUgYWdlbnQncyBwcml2YXRlIGtleS4gVGhlIHZlcmlmaWVyIHJlamVjdHMgaXQuIE9uIHRoZSByaWdodCwgdGhlIGxlZ2l0aW1hdGUgYWdlbnQgcHJlc2VudHMgdGhlIHNhbWUgcGFzc3BvcnQgdG9nZXRoZXIgd2l0aCBhIHByZXNlbnRhdGlvbiBwcm9vZiDigJQgYSBwZXItcmVxdWVzdCBvYmplY3QgYmluZGluZyB0aGUgcGFzc3BvcnQgaWQgKGlzcykgdG8gdGhlIHJlcXVlc3QgbWV0aG9kIGFuZCBjYW5vbmljYWwgVVJJLCBhbiBpc3N1ZWQtYXQgYW5kIHNob3J0IGV4cGlyeSwgYW5kIGEgdW5pcXVlIGp0aSwgYWxsIHNpZ25lZCBieSB0aGUgYWdlbnQncyBwcml2YXRlIGtleS4gVGhlIHZlcmlmaWVyIGNoZWNrcyBpc3N1ZXIgbWF0Y2gsIHRlbXBvcmFsIHZhbGlkaXR5IHdpdGhpbiBmaXZlIG1pbnV0ZXMsIHJlcXVlc3QgYmluZGluZywgdGhlIHNpZ25hdHVyZSBhZ2FpbnN0IHRoZSBwYXNzcG9ydCBrZXksIGFuZCByZXBsYXkgcHJldmVudGlvbiB2aWEgdGhlIGp0aSBjYWNoZSwgYW5kIGFjY2VwdHMgdGhlIHJlcXVlc3QuIFRoZSBwcm9vZiBiaW5kcyBwYXNzcG9ydCB0byBhIHNwZWNpZmljIHJlcXVlc3QgVVJJLCBtZXRob2QsIHRpbWVzdGFtcCwgYW5kIGp0aSwgc2lnbmVkIGJ5IHRoZSBwcml2YXRlIGtleSB0aGUgYXR0YWNrZXIgZG9lcyBub3QgaGF2ZS48L2Rlc2M+CgogIDxkZWZzPgogICAgPG1hcmtlciBpZD0icHAtYXIiIHZpZXdCb3g9IjAgMCAxMCAxMCIgcmVmWD0iOSIgcmVmWT0iNSIgbWFya2VyV2lkdGg9IjciIG1hcmtlckhlaWdodD0iNyIgb3JpZW50PSJhdXRvLXN0YXJ0LXJldmVyc2UiPgogICAgICA8cGF0aCBkPSJNMCwwIEwxMCw1IEwwLDEwIHoiIGZpbGw9IiMzMzQxNTUiLz4KICAgIDwvbWFya2VyPgogICAgPG1hcmtlciBpZD0icHAtYXItcmVkIiB2aWV3Qm94PSIwIDAgMTAgMTAiIHJlZlg9IjkiIHJlZlk9IjUiIG1hcmtlcldpZHRoPSI3IiBtYXJrZXJIZWlnaHQ9IjciIG9yaWVudD0iYXV0by1zdGFydC1yZXZlcnNlIj4KICAgICAgPHBhdGggZD0iTTAsMCBMMTAsNSBMMCwxMCB6IiBmaWxsPSIjYzUyMjFmIi8+CiAgICA8L21hcmtlcj4KICAgIDxtYXJrZXIgaWQ9InBwLWFyLWdyZWVuIiB2aWV3Qm94PSIwIDAgMTAgMTAiIHJlZlg9IjkiIHJlZlk9IjUiIG1hcmtlcldpZHRoPSI3IiBtYXJrZXJIZWlnaHQ9IjciIG9yaWVudD0iYXV0by1zdGFydC1yZXZlcnNlIj4KICAgICAgPHBhdGggZD0iTTAsMCBMMTAsNSBMMCwxMCB6IiBmaWxsPSIjMTM3MzMzIi8+CiAgICA8L21hcmtlcj4KICA8L2RlZnM+CgogIDxyZWN0IHg9IjAiIHk9IjAiIHdpZHRoPSI5MDAiIGhlaWdodD0iNTYwIiBmaWxsPSIjZmZmZmZmIi8+CgogIDwhLS0gVGl0bGUgLS0+CiAgPHRleHQgeD0iNDUwIiB5PSIzNCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgZm9udC1zaXplPSIyMCIgZm9udC13ZWlnaHQ9IjcwMCIgZmlsbD0iIzBmMTcyYSI+UHJlc2VudGF0aW9uIFByb29mICYjODIxMjsgUmVwbGF5IEJpbmRpbmc8L3RleHQ+CiAgPHRleHQgeD0iNDUwIiB5PSI1NiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgZm9udC1zaXplPSIxMyIgZm9udC1zdHlsZT0iaXRhbGljIiBmaWxsPSIjNDc1NTY5Ij5BIHBlci1yZXF1ZXN0IHNpZ25hdHVyZSBiaW5kcyB0aGUgcGFzc3BvcnQgdG8gb25lIHJlcXVlc3Q7IGEgc2NyYXBlZCBwYXNzcG9ydCBhbG9uZSBpcyByZWplY3RlZCAoJiMxNjc7MS4yKTwvdGV4dD4KCiAgPCEtLSBjb2x1bW4gaGVhZGVycyAtLT4KICA8dGV4dCB4PSIyMTAiIHk9IjkyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBmb250LXNpemU9IjEyLjUiIGZvbnQtd2VpZ2h0PSI3MDAiIGZpbGw9IiNhNTBlMGUiPlRocmVhdDogcmVwbGF5ZWQgcGFzc3BvcnQ8L3RleHQ+CiAgPHRleHQgeD0iNjkwIiB5PSI5MiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgZm9udC1zaXplPSIxMi41IiBmb250LXdlaWdodD0iNzAwIiBmaWxsPSIjMGQ2NTJkIj5MZWdpdGltYXRlOiBwYXNzcG9ydCArIHByb29mPC90ZXh0PgoKICA8IS0tID09PT09PT09PT09PT09PT09PT09PSBMRUZUOiBhdHRhY2tlciA9PT09PT09PT09PT09PT09PT09PT0gLS0+CiAgPHJlY3QgeD0iNzAiIHk9IjEwOCIgd2lkdGg9IjI4MCIgaGVpZ2h0PSI2MCIgcng9IjEwIiBmaWxsPSIjZmNlOGU2IiBzdHJva2U9IiNjNTIyMWYiIHN0cm9rZS13aWR0aD0iMS41Ii8+CiAgPHRleHQgeD0iMjEwIiB5PSIxMzIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIGZvbnQtc2l6ZT0iMTIiIGZvbnQtd2VpZ2h0PSI3MDAiIGZpbGw9IiNhNTBlMGUiPmF0dGFja2VyPC90ZXh0PgogIDx0ZXh0IHg9IjIxMCIgeT0iMTUwIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBmb250LXNpemU9IjkuNSIgZmlsbD0iIzFmMjkzNyI+aG9sZHMgYSBzY3JhcGVkLCB2YWxpZCwgc2lnbmVkIHBhc3Nwb3J0PC90ZXh0PgogIDx0ZXh0IHg9IjIxMCIgeT0iMTYyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBmb250LXNpemU9IjkuNSIgZm9udC1zdHlsZT0iaXRhbGljIiBmaWxsPSIjYTUwZTBlIj5idXQgbm90IHRoZSBwcml2YXRlIGtleTwvdGV4dD4KCiAgPCEtLSBzY3JhcGVkIHBhc3Nwb3J0IHRva2VuIC0tPgogIDxyZWN0IHg9IjEyMCIgeT0iMjA2IiB3aWR0aD0iMTgwIiBoZWlnaHQ9IjU4IiByeD0iOCIgZmlsbD0iI2ZmZjdlNiIgc3Ryb2tlPSIjZjU5ZTBiIiBzdHJva2Utd2lkdGg9IjEuNSIvPgogIDx0ZXh0IHg9IjIxMCIgeT0iMjI4IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBmb250LXNpemU9IjExIiBmb250LXdlaWdodD0iNzAwIiBmaWxsPSIjYjQ1MzA5Ij5wYXNzcG9ydCAoY29waWVkKTwvdGV4dD4KICA8dGV4dCB4PSIyMTAiIHk9IjI0NiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgZm9udC1zaXplPSI5IiBmaWxsPSIjMWYyOTM3Ij52YWxpZCBieXRlcywgdmFsaWQgc2lnbmF0dXJlPC90ZXh0PgogIDx0ZXh0IHg9IjIxMCIgeT0iMjU4IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBmb250LXNpemU9IjkiIGZvbnQtc3R5bGU9Iml0YWxpYyIgZmlsbD0iI2E1MGUwZSI+bm8gcGVyLXJlcXVlc3QgcHJvb2Y8L3RleHQ+CgogIDxsaW5lIHgxPSIyMTAiIHkxPSIxNjgiIHgyPSIyMTAiIHkyPSIyMDQiIHN0cm9rZT0iIzMzNDE1NSIgc3Ryb2tlLXdpZHRoPSIxLjQiIG1hcmtlci1lbmQ9InVybCgjcHAtYXIpIi8+CiAgPGxpbmUgeDE9IjIxMCIgeTE9IjI2NCIgeDI9IjIxMCIgeTI9IjMxOCIgc3Ryb2tlPSIjYzUyMjFmIiBzdHJva2Utd2lkdGg9IjEuNSIgbWFya2VyLWVuZD0idXJsKCNwcC1hci1yZWQpIi8+CiAgPHJlY3QgeD0iMTYwIiB5PSIyODQiIHdpZHRoPSIxMDAiIGhlaWdodD0iMTUiIGZpbGw9IiNmZmZmZmYiLz4KICA8dGV4dCB4PSIyMTAiIHk9IjI5NiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgZm9udC1zaXplPSI5LjUiIGZpbGw9IiNhNTBlMGUiPnJlcGxheSBhdHRlbXB0PC90ZXh0PgoKICA8IS0tID09PT09PT09PT09PT09PT09PT09PSBSSUdIVDogbGVnaXRpbWF0ZSBhZ2VudCA9PT09PT09PT09PT09PT09PT09PT0gLS0+CiAgPHJlY3QgeD0iNTUwIiB5PSIxMDgiIHdpZHRoPSIyODAiIGhlaWdodD0iNjAiIHJ4PSIxMCIgZmlsbD0iI2U2ZjRlYSIgc3Ryb2tlPSIjMTM3MzMzIiBzdHJva2Utd2lkdGg9IjEuNSIvPgogIDx0ZXh0IHg9IjY5MCIgeT0iMTMyIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBmb250LXNpemU9IjEyIiBmb250LXdlaWdodD0iNzAwIiBmaWxsPSIjMGQ2NTJkIj50aGUgYWdlbnQ8L3RleHQ+CiAgPHRleHQgeD0iNjkwIiB5PSIxNTAiIHRleHQtYW5jaG9yPSJtaWRkbGUiIGZvbnQtc2l6ZT0iOS41IiBmaWxsPSIjMWYyOTM3Ij5ob2xkcyB0aGUgcGFzc3BvcnQgYW5kIGl0cyBwcml2YXRlIGtleTwvdGV4dD4KICA8dGV4dCB4PSI2OTAiIHk9IjE2MiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgZm9udC1zaXplPSI5LjUiIGZvbnQtc3R5bGU9Iml0YWxpYyIgZmlsbD0iIzBkNjUyZCI+c2lnbnMgYSBmcmVzaCBwcm9vZiBwZXIgcmVxdWVzdDwvdGV4dD4KCiAgPCEtLSBwYXNzcG9ydCArIHByb29mIHRva2VuIC0tPgogIDxyZWN0IHg9IjU2MCIgeT0iMTkwIiB3aWR0aD0iMjYwIiBoZWlnaHQ9IjkyIiByeD0iOCIgZmlsbD0iI2ZmZjdlNiIgc3Ryb2tlPSIjZjU5ZTBiIiBzdHJva2Utd2lkdGg9IjEuNSIvPgogIDx0ZXh0IHg9IjY5MCIgeT0iMjEwIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBmb250LXNpemU9IjExIiBmb250LXdlaWdodD0iNzAwIiBmaWxsPSIjYjQ1MzA5Ij5wYXNzcG9ydCArIHByZXNlbnRhdGlvbiBwcm9vZjwvdGV4dD4KICA8bGluZSB4MT0iNTcyIiB5MT0iMjE4IiB4Mj0iODA4IiB5Mj0iMjE4IiBzdHJva2U9IiNmM2Q4YTgiIHN0cm9rZS13aWR0aD0iMSIvPgogIDxnIGZvbnQtc2l6ZT0iOSIgZmlsbD0iIzFmMjkzNyI+CiAgICA8dGV4dCB4PSI1NzIiIHk9IjIzNCI+aXNzID0gcGFzc3BvcnQgaWQgJiMxODM7IHJlcXVlc3Q6IG1ldGhvZCArIFVSSTwvdGV4dD4KICAgIDx0ZXh0IHg9IjU3MiIgeT0iMjQ4Ij5pYXQgJiMxODM7IGV4cCAoJiM4ODA0OyA1IG1pbikgJiMxODM7IGp0aSAodW5pcXVlKTwvdGV4dD4KICAgIDx0ZXh0IHg9IjU3MiIgeT0iMjYyIiBmb250LXdlaWdodD0iNzAwIiBmaWxsPSIjMGQ2NTJkIj5zaWduYXR1cmUgYnkgdGhlIGFnZW50J3MgcHJpdmF0ZSBrZXk8L3RleHQ+CiAgICA8dGV4dCB4PSI1NzIiIHk9IjI3NiIgZm9udC1zdHlsZT0iaXRhbGljIiBmaWxsPSIjNDc1NTY5Ij5iaW5kcyB0aGlzIHBhc3Nwb3J0IHRvIHRoaXMgb25lIHJlcXVlc3Q8L3RleHQ+CiAgPC9nPgoKICA8bGluZSB4MT0iNjkwIiB5MT0iMTY4IiB4Mj0iNjkwIiB5Mj0iMTg4IiBzdHJva2U9IiMzMzQxNTUiIHN0cm9rZS13aWR0aD0iMS40IiBtYXJrZXItZW5kPSJ1cmwoI3BwLWFyKSIvPgogIDxsaW5lIHgxPSI2OTAiIHkxPSIyODIiIHgyPSI2OTAiIHkyPSIzMTgiIHN0cm9rZT0iIzEzNzMzMyIgc3Ryb2tlLXdpZHRoPSIxLjUiIG1hcmtlci1lbmQ9InVybCgjcHAtYXItZ3JlZW4pIi8+CiAgPHJlY3QgeD0iNjQ4IiB5PSIyOTEiIHdpZHRoPSI4NCIgaGVpZ2h0PSIxNSIgZmlsbD0iI2ZmZmZmZiIvPgogIDx0ZXh0IHg9IjY5MCIgeT0iMzAzIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBmb250LXNpemU9IjkuNSIgZmlsbD0iIzBkNjUyZCI+Ym91bmQgcmVxdWVzdDwvdGV4dD4KCiAgPCEtLSA9PT09PT09PT09PT09PT09PT09PT0gVkVSSUZJRVIgKGNlbnRlciBib3R0b20pID09PT09PT09PT09PT09PT09PT09PSAtLT4KICA8cmVjdCB4PSIzMDAiIHk9IjMyMCIgd2lkdGg9IjMwMCIgaGVpZ2h0PSIxMTgiIHJ4PSIxMCIgZmlsbD0iI2Y4ZmFmYyIgc3Ryb2tlPSIjMWE3M2U4IiBzdHJva2Utd2lkdGg9IjEuNzUiLz4KICA8dGV4dCB4PSI0NTAiIHk9IjM0NCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgZm9udC1zaXplPSIxMyIgZm9udC13ZWlnaHQ9IjcwMCIgZmlsbD0iIzBiNTdkMCI+dmVyaWZpZXIgJiMxODM7ICYjMTY3OzEuMi42IGNoZWNrczwvdGV4dD4KICA8ZyBmb250LXNpemU9IjkuNSIgZmlsbD0iIzFmMjkzNyI+CiAgICA8dGV4dCB4PSIzMTgiIHk9IjM2NiI+aXNzdWVyIG1hdGNoIChpc3MgPSBpZCkgJiMxODM7IHRlbXBvcmFsICgmIzg4MDQ7IDUgbWluKTwvdGV4dD4KICAgIDx0ZXh0IHg9IjMxOCIgeT0iMzgyIj5yZXF1ZXN0IGJpbmRpbmcgKG1ldGhvZCArIFVSSSkgJiMxODM7IHNpZ25hdHVyZSAocGFzc3BvcnQga2V5KTwvdGV4dD4KICAgIDx0ZXh0IHg9IjMxOCIgeT0iMzk4Ij5yZXBsYXkgcHJldmVudGlvbiAmIzgyMTI7IGp0aSBzZWVuIGJlZm9yZT8gcmVqZWN0PC90ZXh0PgogIDwvZz4KICA8bGluZSB4MT0iMzE4IiB5MT0iNDA4IiB4Mj0iNTgyIiB5Mj0iNDA4IiBzdHJva2U9IiNjYmQ1ZTEiIHN0cm9rZS13aWR0aD0iMSIvPgogIDx0ZXh0IHg9IjQ1MCIgeT0iNDI2IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBmb250LXNpemU9IjkuNSIgZm9udC1zdHlsZT0iaXRhbGljIiBmaWxsPSIjNDc1NTY5Ij5ubyB2YWxpZCBwcm9vZiAmIzg2NTg7IG5vIGF1dGhlbnRpY2F0ZWQgcmVxdWVzdDwvdGV4dD4KCiAgPCEtLSBsZWZ0IHBhdGggaW50byB2ZXJpZmllciAtLT4KICA8bGluZSB4MT0iMjEwIiB5MT0iMzE4IiB4Mj0iMjEwIiB5Mj0iMzYwIiBzdHJva2U9IiNjNTIyMWYiIHN0cm9rZS13aWR0aD0iMS41Ii8+CiAgPGxpbmUgeDE9IjIxMCIgeTE9IjM2MCIgeDI9IjI5OCIgeTI9IjM2MCIgc3Ryb2tlPSIjYzUyMjFmIiBzdHJva2Utd2lkdGg9IjEuNSIgbWFya2VyLWVuZD0idXJsKCNwcC1hci1yZWQpIi8+CiAgPCEtLSByaWdodCBwYXRoIGludG8gdmVyaWZpZXIgLS0+CiAgPGxpbmUgeDE9IjY5MCIgeTE9IjMxOCIgeDI9IjY5MCIgeTI9IjM4MCIgc3Ryb2tlPSIjMTM3MzMzIiBzdHJva2Utd2lkdGg9IjEuNSIvPgogIDxsaW5lIHgxPSI2OTAiIHkxPSIzODAiIHgyPSI2MDIiIHkyPSIzODAiIHN0cm9rZT0iIzEzNzMzMyIgc3Ryb2tlLXdpZHRoPSIxLjUiIG1hcmtlci1lbmQ9InVybCgjcHAtYXItZ3JlZW4pIi8+CgogIDwhLS0gb3V0Y29tZXMgLS0+CiAgPHJlY3QgeD0iMTIwIiB5PSI0NzAiIHdpZHRoPSIxODAiIGhlaWdodD0iNDQiIHJ4PSIxMCIgZmlsbD0iI2ZjZThlNiIgc3Ryb2tlPSIjYzUyMjFmIiBzdHJva2Utd2lkdGg9IjEuNzUiLz4KICA8dGV4dCB4PSIyMTAiIHk9IjQ5MCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgZm9udC1zaXplPSIxMiIgZm9udC13ZWlnaHQ9IjcwMCIgZmlsbD0iI2E1MGUwZSI+UkVKRUNURUQ8L3RleHQ+CiAgPHRleHQgeD0iMjEwIiB5PSI1MDUiIHRleHQtYW5jaG9yPSJtaWRkbGUiIGZvbnQtc2l6ZT0iOSIgZmlsbD0iIzFmMjkzNyI+cmVwbGF5IGRlZmVhdGVkPC90ZXh0PgogIDxsaW5lIHgxPSIzMjAiIHkxPSI0MzgiIHgyPSIyNDgiIHkyPSI0NjgiIHN0cm9rZT0iI2M1MjIxZiIgc3Ryb2tlLXdpZHRoPSIxLjUiIG1hcmtlci1lbmQ9InVybCgjcHAtYXItcmVkKSIvPgoKICA8cmVjdCB4PSI2MDAiIHk9IjQ3MCIgd2lkdGg9IjE4MCIgaGVpZ2h0PSI0NCIgcng9IjEwIiBmaWxsPSIjZTZmNGVhIiBzdHJva2U9IiMxMzczMzMiIHN0cm9rZS13aWR0aD0iMS43NSIvPgogIDx0ZXh0IHg9IjY5MCIgeT0iNDkwIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBmb250LXNpemU9IjEyIiBmb250LXdlaWdodD0iNzAwIiBmaWxsPSIjMGQ2NTJkIj5BQ0NFUFRFRDwvdGV4dD4KICA8dGV4dCB4PSI2OTAiIHk9IjUwNSIgdGV4dC1hbmNob3I9Im1pZGRsZSIgZm9udC1zaXplPSI5IiBmaWxsPSIjMWYyOTM3Ij5yZXF1ZXN0IGF1dGhlbnRpY2F0ZWQ8L3RleHQ+CiAgPGxpbmUgeDE9IjU4MCIgeTE9IjQzOCIgeDI9IjY1MiIgeTI9IjQ2OCIgc3Ryb2tlPSIjMTM3MzMzIiBzdHJva2Utd2lkdGg9IjEuNSIgbWFya2VyLWVuZD0idXJsKCNwcC1hci1ncmVlbikiLz4KCiAgPCEtLSBmb290bm90ZSAtLT4KICA8dGV4dCB4PSI0NTAiIHk9IjU0NCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgZm9udC1zaXplPSIxMSIgZm9udC1zdHlsZT0iaXRhbGljIiBmaWxsPSIjNDc1NTY5Ij5UaGUgcHJvb2YgYmluZHMgcGFzc3BvcnQgJiM4NTk0OyByZXF1ZXN0IFVSSSArIG1ldGhvZCArIHRpbWVzdGFtcCArIGp0aSwgc2lnbmVkIGJ5IHRoZSBrZXkgdGhlIGF0dGFja2VyIGxhY2tzLiBJbGx1c3RyYXRpdmU7ICYjMTY3OzEuMiBpcyBhdXRob3JpdGF0aXZlLjwvdGV4dD4KPC9zdmc+Cg==) *Figure (informative): A scraped passport is replayable; a passport bound to a per-request proof is not. The proof binds the passport to a specific request and is signed by the private key an attacker lacks, so a replayed passport without a fresh proof is rejected. This figure is illustrative; the §1.2.6 steps below are authoritative.* After §1.1 succeeds, the verifier **MUST** perform the following checks. They are gated: failure of an earlier check halts the procedure. **§1.2.6.1 Proof Document Parsing.** Decode and parse the proof. A document that is not valid JSON, or that is missing any REQUIRED member from §1.2.2, **MUST** be rejected. **§1.2.6.2 Issuer Match.** The proof's `iss` **MUST** equal the passport's `id`. A mismatch indicates the proof was constructed for a different passport and **MUST** result in rejection. **§1.2.6.3 Temporal Validity.** The current time **MUST** lie between `iat - skew` and `exp + skew`, where `skew` is the value defined in §1.2.8. Additionally, `exp - iat` **MUST NOT** exceed 5 minutes; proofs that declare longer lifetimes **MUST** be rejected. **§1.2.6.4 Request Binding.** The proof's `request.method` **MUST** equal the actual request's HTTP method (compared case-insensitively, normalized to uppercase). The proof's `request.uri`, after the canonicalization in §1.2.4, **MUST** equal the canonicalized form of the actual request URI. Mismatch **MUST** result in rejection. **§1.2.6.5 Signature Verification.** The signature **MUST** verify against the JCS-canonical bytes of the proof with its `signature` object removed, using the verification key established by §1.1.4 / §1.1.5 (the same key used to verify the passport itself). Signature failure **MUST** result in rejection. **§1.2.6.6 Replay Prevention.** The verifier **MUST** maintain a cache of recently observed `jti` values, scoped to the verifier instance, with a TTL no shorter than the maximum proof lifetime (5 minutes). If the proof's `jti` is found in the cache, the proof **MUST** be rejected. Otherwise, the verifier **MUST** insert the `jti` into the cache before treating the request as authenticated. **§1.2.6.7 Nonce Verification (when applicable).** If the verifier has issued a nonce per §1.2.7 and the proof includes a `nonce` member, the value **MUST** match the issued nonce. If the verifier requires a nonce (high-security mode) and the proof omits it, the proof **MUST** be rejected. #### 1.2.7 Server-Issued Nonces[​](#127-server-issued-nonces "Direct link to 1.2.7 Server-Issued Nonces") A verifier **MAY** require that proofs include a server-issued nonce, providing stronger guarantees than time-based replay prevention alone. When this mode is enabled: * The verifier issues a nonce via a `WWW-Authenticate: ADL nonce="…"` challenge on a `401 Unauthorized` response, or via a separate challenge endpoint. * The presenter retrieves the nonce, includes it in the next proof's `nonce` member, and re-issues the request. * The verifier accepts the nonce only once and only within a configured TTL. Nonces are **OPTIONAL** in the base specification. Deployments handling `restricted` data classification (§10.1) **SHOULD** require nonces. #### 1.2.8 Clock Skew Tolerance[​](#128-clock-skew-tolerance "Direct link to 1.2.8 Clock Skew Tolerance") The default skew tolerance **MUST** be 60 seconds. Implementations **MAY** make this configurable but **MUST NOT** default to a value greater than 5 minutes. #### 1.2.9 Outcome Recording[​](#129-outcome-recording "Direct link to 1.2.9 Outcome Recording") The §1.1.10 verification outcome **MUST** be extended to record the result of each §1.2.6 step using the same step-result shape, with section values `"1.2.6.1"` through `"1.2.6.7"`. The aggregate outcome's `verified` flag **MUST** require all §1.1 and §1.2 block-severity steps to pass. #### 1.2.10 Backward Compatibility and Optional Enforcement[​](#1210-backward-compatibility-and-optional-enforcement "Direct link to 1.2.10 Backward Compatibility and Optional Enforcement") To allow incremental adoption: * Implementations **MAY** provide a `require_proof` configuration flag (default: `false` for backward compatibility, **RECOMMENDED**: `true` for production). * When `require_proof` is `false` and a proof is absent, §1.2 step results **MUST** be recorded with `severity: "warn"` and `passed: true` carrying the detail `"presentation proof not provided"`. The aggregate outcome remains `verified` based on §1.1 alone. * When `require_proof` is `true` and a proof is absent, the verifier **MUST** reject the request with a missing-proof step at §1.2.6.1, severity `"block"`. ## 2 Authorization (Enforcement Procedures)[​](#2-authorization-enforcement-procedures "Direct link to 2 Authorization (Enforcement Procedures)") Authentication (§1) establishes *who* a counterparty is. Authorization establishes *what they may do*. The scope *declarations* an agent advertises — `security.scopes` and `tools[*].security.scopes`, together with their inheritance and override rules — are defined in [ADL Core §10.4.1–§10.4.2](/spec/next#104-authorization-scopes). This section defines the *enforcement procedures* a verifier applies to those declarations, uniformly across both authentication paths defined in §1. ### 2.1 Authorization in Human-to-Agent Flows[​](#21-authorization-in-human-to-agent-flows "Direct link to 2.1 Authorization in Human-to-Agent Flows") When the calling party authenticates via §10.3.3 (OAuth 2.1, OIDC, mTLS, or API key), the agent **MUST** authorize the request as follows: 1. **Authenticate first.** §10.3.3 credential validation **MUST** succeed before scope evaluation. Authentication failure short-circuits with a `401 Unauthorized` response (or transport-equivalent) and **MUST NOT** leak which scopes the request was missing. 2. **Extract presented scopes.** For OAuth 2.1 / OIDC, parse the `scope` claim of the access token. For API keys with an out-of-band scope binding, look up the scope set associated with the key. For mTLS, extract scopes from the client certificate (e.g., from a Subject Alternative Name extension or an external attribute store). 3. **Determine required scopes for the requested operation.** * For requests that target a specific tool, required = `tools[i].security.scopes` if declared, else `security.scopes`. * For requests that target the agent in general (e.g., capability discovery, status), required = `security.scopes`. 4. **Authorize.** The request is authorized iff every member of the required set is present in the presented set. Implementations **MAY** evaluate scope membership case-sensitively (recommended) or per the deployment's OAuth 2.1 server policy. 5. **Reject with structured error.** When authorization fails, respond with HTTP `403 Forbidden` and a `WWW-Authenticate: Bearer error="insufficient_scope", scope=""` header per \[RFC6750] §3, and **MUST NOT** leak any data the client was attempting to access. This procedure is unchanged from standard OAuth 2.1 resource-server behavior; ADL's contribution is only the declarative `tools[*].security.scopes` override semantics. ### 2.2 Authorization in Agent-to-Agent Flows[​](#22-authorization-in-agent-to-agent-flows "Direct link to 2.2 Authorization in Agent-to-Agent Flows") When the calling party is itself an ADL agent authenticating via §1.1 (passport) and §1.2 (presentation proof), the agent **MUST** authorize the request as follows: 1. **Authenticate first.** §1.1 verification and §1.2.6 proof verification **MUST** succeed before scope evaluation. Authentication failure short-circuits per §1.1.10 / §1.2.9. 2. **Establish the presenter's scope ceiling.** The ceiling is the calling agent's passport `security.scopes`. The ceiling represents the maximum capability the calling agent can ever assert, signed by the calling agent's key as part of the passport (§10.2 attestation). 3. **Extract requested scopes from the proof.** Read the `scopes` member of the presentation proof (§1.2.2). When omitted, the requested scope set is empty. 4. **Verify ceiling subset.** The proof's `scopes` array **MUST** be a subset of the calling agent's passport `security.scopes` ceiling. A request whose proof asserts a scope outside the ceiling **MUST** be rejected at this step. This is the agent-to-agent analog of OAuth 2.1's authorization-server-issued scope: the passport-attested ceiling is the agent's standing grant, and the proof is its per-request attestation of which slice of that grant it is exercising. 5. **Determine required scopes for the requested operation.** Identical to §2.1 step 3 — tool override or root default. 6. **Authorize.** The request is authorized iff every member of the required set is present in the proof's `scopes` set. 7. **Reject with structured error.** When authorization fails, the rejection **MUST** identify the missing scopes in the structured outcome (§1.1.10 + §1.2.9) and **MAY** include them in a transport-level error response, scoped to information the calling agent already has the right to see. The proof's signature (§1.2.6.5) covers the `scopes` array as part of the canonical bytes, so the requested scope set is sender-constrained: a third party that intercepts the proof cannot replay it with an expanded scope set. ### 2.3 Composition Across Boundaries (Multi-Hop Authorization)[​](#23-composition-across-boundaries-multi-hop-authorization "Direct link to 2.3 Composition Across Boundaries (Multi-Hop Authorization)") When a human-authenticated request arrives at Agent A and Agent A subsequently calls upstream Agent B on the human's behalf, two independent authorizations occur: ![UML sequence diagram of multi-hop authorization with three lifelines: Human, Agent A, and Agent B. Step 1, the human sends a request to Agent A carrying an OAuth token with scope S\_h. Step 2, Agent A authorizes the human under §2.1, requiring its required\_A scopes to be a subset of S\_h. Step 3, Agent A invokes upstream Agent B, presenting its passport and a presentation proof carrying scope S\_a. Step 4, Agent B authorizes Agent A under §2.2: first a ceiling check that the proof scopes are a subset of Agent A\'s passport scopes, then that Agent B\'s required\_B scopes are a subset of the proof scopes. Step 5, Agent B returns a result to Agent A; step 6, Agent A returns a result to the human. A closing note states the two authorizations are independent: Agent A\'s outbound scope S\_a is bounded only by its passport ceiling, not by S\_h, and each hop keeps its own audit record so no single hop sees the whole chain.](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHZpZXdCb3g9IjAgMCA5MDAgNTgwIiB3aWR0aD0iOTAwIiBoZWlnaHQ9IjU4MCIgcm9sZT0iaW1nIiBhcmlhLWxhYmVsbGVkYnk9Im1oLXRpdGxlIG1oLWRlc2MiIGZvbnQtZmFtaWx5PSItYXBwbGUtc3lzdGVtLCBCbGlua01hY1N5c3RlbUZvbnQsICdTZWdvZSBVSScsIEhlbHZldGljYSwgQXJpYWwsIHNhbnMtc2VyaWYiPgogIDx0aXRsZSBpZD0ibWgtdGl0bGUiPk11bHRpLWhvcCBhdXRob3JpemF0aW9uOiB0d28gaW5kZXBlbmRlbnQgYXV0aG9yaXphdGlvbnMgYWNyb3NzIGEgaG9wIGJvdW5kYXJ5PC90aXRsZT4KICA8ZGVzYyBpZD0ibWgtZGVzYyI+QSBVTUwgc2VxdWVuY2UgZGlhZ3JhbSB3aXRoIHRocmVlIGxpZmVsaW5lczogSHVtYW4sIEFnZW50IEEsIGFuZCBBZ2VudCBCLiBTdGVwIDEsIHRoZSBodW1hbiBzZW5kcyBhIHJlcXVlc3QgdG8gQWdlbnQgQSBjYXJyeWluZyBhbiBPQXV0aCB0b2tlbiB3aXRoIHNjb3BlIFNfaC4gU3RlcCAyLCBBZ2VudCBBIGF1dGhvcml6ZXMgdGhlIGh1bWFuIHVuZGVyIMKnMi4xLCByZXF1aXJpbmcgaXRzIHJlcXVpcmVkX0Egc2NvcGVzIHRvIGJlIGEgc3Vic2V0IG9mIFNfaC4gU3RlcCAzLCBBZ2VudCBBIGludm9rZXMgdXBzdHJlYW0gQWdlbnQgQiwgcHJlc2VudGluZyBpdHMgcGFzc3BvcnQgYW5kIGEgcHJlc2VudGF0aW9uIHByb29mIGNhcnJ5aW5nIHNjb3BlIFNfYS4gU3RlcCA0LCBBZ2VudCBCIGF1dGhvcml6ZXMgQWdlbnQgQSB1bmRlciDCpzIuMjogZmlyc3QgYSBjZWlsaW5nIGNoZWNrIHRoYXQgdGhlIHByb29mIHNjb3BlcyBhcmUgYSBzdWJzZXQgb2YgQWdlbnQgQSdzIHBhc3Nwb3J0IHNjb3BlcywgdGhlbiB0aGF0IEFnZW50IEIncyByZXF1aXJlZF9CIHNjb3BlcyBhcmUgYSBzdWJzZXQgb2YgdGhlIHByb29mIHNjb3Blcy4gU3RlcCA1LCBBZ2VudCBCIHJldHVybnMgYSByZXN1bHQgdG8gQWdlbnQgQTsgc3RlcCA2LCBBZ2VudCBBIHJldHVybnMgYSByZXN1bHQgdG8gdGhlIGh1bWFuLiBBIGNsb3Npbmcgbm90ZSBzdGF0ZXMgdGhlIHR3byBhdXRob3JpemF0aW9ucyBhcmUgaW5kZXBlbmRlbnQ6IEFnZW50IEEncyBvdXRib3VuZCBzY29wZSBTX2EgaXMgYm91bmRlZCBvbmx5IGJ5IGl0cyBwYXNzcG9ydCBjZWlsaW5nLCBub3QgYnkgU19oLCBhbmQgZWFjaCBob3Aga2VlcHMgaXRzIG93biBhdWRpdCByZWNvcmQgc28gbm8gc2luZ2xlIGhvcCBzZWVzIHRoZSB3aG9sZSBjaGFpbi48L2Rlc2M+CgogIDxkZWZzPgogICAgPG1hcmtlciBpZD0ibWgtYXIiIHZpZXdCb3g9IjAgMCAxMCAxMCIgcmVmWD0iOSIgcmVmWT0iNSIgbWFya2VyV2lkdGg9IjciIG1hcmtlckhlaWdodD0iNyIgb3JpZW50PSJhdXRvLXN0YXJ0LXJldmVyc2UiPgogICAgICA8cGF0aCBkPSJNMCwwIEwxMCw1IEwwLDEwIHoiIGZpbGw9IiMzMzQxNTUiLz4KICAgIDwvbWFya2VyPgogIDwvZGVmcz4KCiAgPHJlY3QgeD0iMCIgeT0iMCIgd2lkdGg9IjkwMCIgaGVpZ2h0PSI1ODAiIGZpbGw9IiNmZmZmZmYiLz4KCiAgPCEtLSBUaXRsZSAtLT4KICA8dGV4dCB4PSI0NTAiIHk9IjM0IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBmb250LXNpemU9IjIwIiBmb250LXdlaWdodD0iNzAwIiBmaWxsPSIjMGYxNzJhIj5NdWx0aS1Ib3AgQXV0aG9yaXphdGlvbjwvdGV4dD4KICA8dGV4dCB4PSI0NTAiIHk9IjU2IiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBmb250LXNpemU9IjEzIiBmb250LXN0eWxlPSJpdGFsaWMiIGZpbGw9IiM0NzU1NjkiPlR3byBpbmRlcGVuZGVudCBhdXRob3JpemF0aW9ucyBhY3Jvc3MgYSBob3AgYm91bmRhcnkgJiM4MjEyOyBIdW1hbiAmIzg1OTQ7IEFnZW50IEEgJiM4NTk0OyBBZ2VudCBCICgmIzE2NzsyLjMpPC90ZXh0PgoKICA8IS0tIGxpZmVsaW5lcyAtLT4KICA8bGluZSB4MT0iMTMwIiB5MT0iMTE2IiB4Mj0iMTMwIiB5Mj0iNDUyIiBzdHJva2U9IiNjYmQ1ZTEiIHN0cm9rZS13aWR0aD0iMS4yNSIgc3Ryb2tlLWRhc2hhcnJheT0iNCA0Ii8+CiAgPGxpbmUgeDE9IjQ1MCIgeTE9IjExNiIgeDI9IjQ1MCIgeTI9IjQ1MiIgc3Ryb2tlPSIjY2JkNWUxIiBzdHJva2Utd2lkdGg9IjEuMjUiIHN0cm9rZS1kYXNoYXJyYXk9IjQgNCIvPgogIDxsaW5lIHgxPSI3NzAiIHkxPSIxMTYiIHgyPSI3NzAiIHkyPSI0NTIiIHN0cm9rZT0iI2NiZDVlMSIgc3Ryb2tlLXdpZHRoPSIxLjI1IiBzdHJva2UtZGFzaGFycmF5PSI0IDQiLz4KCiAgPCEtLSBwYXJ0aWNpcGFudCBib3hlcyAtLT4KICA8cmVjdCB4PSI2NSIgeT0iNzgiIHdpZHRoPSIxMzAiIGhlaWdodD0iMzYiIHJ4PSI4IiBmaWxsPSIjZThmMGZlIiBzdHJva2U9IiMxYTczZTgiIHN0cm9rZS13aWR0aD0iMS41Ii8+CiAgPHRleHQgeD0iMTMwIiB5PSIxMDEiIHRleHQtYW5jaG9yPSJtaWRkbGUiIGZvbnQtc2l6ZT0iMTMiIGZvbnQtd2VpZ2h0PSI3MDAiIGZpbGw9IiMwYjU3ZDAiPkh1bWFuPC90ZXh0PgogIDxyZWN0IHg9IjM4NSIgeT0iNzgiIHdpZHRoPSIxMzAiIGhlaWdodD0iMzYiIHJ4PSI4IiBmaWxsPSIjZThmMGZlIiBzdHJva2U9IiMxYTczZTgiIHN0cm9rZS13aWR0aD0iMS41Ii8+CiAgPHRleHQgeD0iNDUwIiB5PSIxMDEiIHRleHQtYW5jaG9yPSJtaWRkbGUiIGZvbnQtc2l6ZT0iMTMiIGZvbnQtd2VpZ2h0PSI3MDAiIGZpbGw9IiMwYjU3ZDAiPkFnZW50IEE8L3RleHQ+CiAgPHJlY3QgeD0iNzA1IiB5PSI3OCIgd2lkdGg9IjEzMCIgaGVpZ2h0PSIzNiIgcng9IjgiIGZpbGw9IiNlOGYwZmUiIHN0cm9rZT0iIzFhNzNlOCIgc3Ryb2tlLXdpZHRoPSIxLjUiLz4KICA8dGV4dCB4PSI3NzAiIHk9IjEwMSIgdGV4dC1hbmNob3I9Im1pZGRsZSIgZm9udC1zaXplPSIxMyIgZm9udC13ZWlnaHQ9IjcwMCIgZmlsbD0iIzBiNTdkMCI+QWdlbnQgQjwvdGV4dD4KCiAgPCEtLSBsZWdlbmQgKGluIHRoZSBjbGVhciBnYXAgYmV0d2VlbiBBZ2VudCBBIGFuZCBBZ2VudCBCIGhlYWRlcnMpIC0tPgogIDxsaW5lIHgxPSI1NDAiIHkxPSI5NiIgeDI9IjU2NiIgeTI9Ijk2IiBzdHJva2U9IiMzMzQxNTUiIHN0cm9rZS13aWR0aD0iMS41IiBtYXJrZXItZW5kPSJ1cmwoI21oLWFyKSIvPgogIDx0ZXh0IHg9IjU3MiIgeT0iMTAwIiBmb250LXNpemU9IjEwLjUiIGZpbGw9IiM2NDc0OGIiPmNhbGw8L3RleHQ+CiAgPGxpbmUgeDE9IjYxNiIgeTE9Ijk2IiB4Mj0iNjQyIiB5Mj0iOTYiIHN0cm9rZT0iIzMzNDE1NSIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0cm9rZS1kYXNoYXJyYXk9IjUgMyIgbWFya2VyLWVuZD0idXJsKCNtaC1hcikiLz4KICA8dGV4dCB4PSI2NDgiIHk9IjEwMCIgZm9udC1zaXplPSIxMC41IiBmaWxsPSIjNjQ3NDhiIj5yZXR1cm48L3RleHQ+CgogIDwhLS0gYWN0aXZhdGlvbiBiYXJzIC0tPgogIDxyZWN0IHg9IjQ0NCIgeT0iMTQ0IiB3aWR0aD0iMTIiIGhlaWdodD0iMjkyIiBmaWxsPSIjZDJlM2ZjIiBzdHJva2U9IiMxYTczZTgiIHN0cm9rZS13aWR0aD0iMC45Ii8+CiAgPHJlY3QgeD0iNzY0IiB5PSIyNTIiIHdpZHRoPSIxMiIgaGVpZ2h0PSIxMzIiIGZpbGw9IiNkMmUzZmMiIHN0cm9rZT0iIzFhNzNlOCIgc3Ryb2tlLXdpZHRoPSIwLjkiLz4KCiAgPCEtLSAoMSkgSHVtYW4gLT4gQWdlbnQgQSAtLT4KICA8dGV4dCB4PSIyODciIHk9IjE0MiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgZm9udC1zaXplPSIxMSIgZmlsbD0iIzFmMjkzNyI+KDEpIHJlcXVlc3QgJiMxODM7IE9BdXRoIHRva2VuLCBzY29wZSBTX2g8L3RleHQ+CiAgPGxpbmUgeDE9IjEzMCIgeTE9IjE1MCIgeDI9IjQ0MiIgeTI9IjE1MCIgc3Ryb2tlPSIjMzM0MTU1IiBzdHJva2Utd2lkdGg9IjEuNSIgbWFya2VyLWVuZD0idXJsKCNtaC1hcikiLz4KCiAgPCEtLSAoMikgwqcyLjEgYXV0aG9yaXplIGh1bWFuIChBZ2VudCBBJ3MgZGVjaXNpb24pOyBjZW50ZXJlZCBpbiB0aGUgSHVtYW48LT5BIGd1dHRlciAobWlkIHg9MjkwKSwgYmFsYW5jZWQgcGFkZGluZyAtLT4KICA8cmVjdCB4PSIxOTgiIHk9IjE2NyIgd2lkdGg9IjE4NCIgaGVpZ2h0PSI1MCIgcng9IjgiIGZpbGw9IiNmZmY3ZTYiIHN0cm9rZT0iI2Y1OWUwYiIgc3Ryb2tlLXdpZHRoPSIxLjQiLz4KICA8dGV4dCB4PSIyMTYiIHk9IjE4OCIgZm9udC1zaXplPSIxMC41IiBmb250LXdlaWdodD0iNzAwIiBmaWxsPSIjYjQ1MzA5Ij4oMikgJiMxNjc7Mi4xICYjODIxMjsgYXV0aG9yaXplIGh1bWFuPC90ZXh0PgogIDx0ZXh0IHg9IjIxNiIgeT0iMjA3IiBmb250LXNpemU9IjEwLjUiIGZpbGw9IiMxZjI5MzciPnJlcXVpcmVkX0EgJiM4ODM4OyBTX2g8L3RleHQ+CgogIDwhLS0gKDMpIEFnZW50IEEgLT4gQWdlbnQgQiAtLT4KICA8dGV4dCB4PSI2MTAiIHk9IjI1MCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgZm9udC1zaXplPSIxMSIgZmlsbD0iIzFmMjkzNyI+KDMpIGludm9rZSB1cHN0cmVhbSAmIzE4MzsgcGFzc3BvcnQgKyBwcm9vZiwgc2NvcGUgU19hPC90ZXh0PgogIDxsaW5lIHgxPSI0NTYiIHkxPSIyNTgiIHgyPSI3NjIiIHkyPSIyNTgiIHN0cm9rZT0iIzMzNDE1NSIgc3Ryb2tlLXdpZHRoPSIxLjUiIG1hcmtlci1lbmQ9InVybCgjbWgtYXIpIi8+CgogIDwhLS0gKDQpIMKnMi4yIGF1dGhvcml6ZSBBZ2VudCBBIChBZ2VudCBCJ3MgZGVjaXNpb24pOyBjZW50ZXJlZCBpbiB0aGUgQTwtPkIgZ3V0dGVyIChtaWQgeD02MTApLCBiYWxhbmNlZCBwYWRkaW5nIC0tPgogIDxyZWN0IHg9IjQ4MyIgeT0iMjc3IiB3aWR0aD0iMjU0IiBoZWlnaHQ9IjcyIiByeD0iOCIgZmlsbD0iI2ZmZjdlNiIgc3Ryb2tlPSIjZjU5ZTBiIiBzdHJva2Utd2lkdGg9IjEuNCIvPgogIDx0ZXh0IHg9IjUwMSIgeT0iMjk3IiBmb250LXNpemU9IjEwLjUiIGZvbnQtd2VpZ2h0PSI3MDAiIGZpbGw9IiNiNDUzMDkiPig0KSAmIzE2NzsyLjIgJiM4MjEyOyBhdXRob3JpemUgQWdlbnQgQTwvdGV4dD4KICA8dGV4dCB4PSI1MDEiIHk9IjMxNiIgZm9udC1zaXplPSIxMCIgZmlsbD0iIzFmMjkzNyI+MSAmIzE4MzsgY2VpbGluZzogcHJvb2Yuc2NvcGVzICYjODgzODsgQS5wYXNzcG9ydC5zY29wZXM8L3RleHQ+CiAgPHRleHQgeD0iNTAxIiB5PSIzMzUiIGZvbnQtc2l6ZT0iMTAiIGZpbGw9IiMxZjI5MzciPjIgJiMxODM7IHJlcXVpcmVkX0IgJiM4ODM4OyBwcm9vZi5zY29wZXM8L3RleHQ+CgogIDwhLS0gKDUpIEFnZW50IEIgLS0+IEFnZW50IEEgKHJldHVybikgLS0+CiAgPHRleHQgeD0iNjEwIiB5PSIzNzYiIHRleHQtYW5jaG9yPSJtaWRkbGUiIGZvbnQtc2l6ZT0iMTEiIGZpbGw9IiMxZjI5MzciPig1KSByZXN1bHQ8L3RleHQ+CiAgPGxpbmUgeDE9Ijc2NCIgeTE9IjM4NCIgeDI9IjQ1OCIgeTI9IjM4NCIgc3Ryb2tlPSIjMzM0MTU1IiBzdHJva2Utd2lkdGg9IjEuNSIgc3Ryb2tlLWRhc2hhcnJheT0iNiA0IiBtYXJrZXItZW5kPSJ1cmwoI21oLWFyKSIvPgoKICA8IS0tICg2KSBBZ2VudCBBIC0tPiBIdW1hbiAocmV0dXJuKSAtLT4KICA8dGV4dCB4PSIyODciIHk9IjQyOCIgdGV4dC1hbmNob3I9Im1pZGRsZSIgZm9udC1zaXplPSIxMSIgZmlsbD0iIzFmMjkzNyI+KDYpIHJlc3VsdDwvdGV4dD4KICA8bGluZSB4MT0iNDQ0IiB5MT0iNDM2IiB4Mj0iMTMyIiB5Mj0iNDM2IiBzdHJva2U9IiMzMzQxNTUiIHN0cm9rZS13aWR0aD0iMS41IiBzdHJva2UtZGFzaGFycmF5PSI2IDQiIG1hcmtlci1lbmQ9InVybCgjbWgtYXIpIi8+CgogIDwhLS0gc3Bhbm5pbmcgdGFrZWF3YXkgbm90ZSAtLT4KICA8cmVjdCB4PSI3MCIgeT0iNDYyIiB3aWR0aD0iNzYwIiBoZWlnaHQ9IjU0IiByeD0iMTAiIGZpbGw9IiNmOGZhZmMiIHN0cm9rZT0iI2NiZDVlMSIgc3Ryb2tlLXdpZHRoPSIxLjUiIHN0cm9rZS1kYXNoYXJyYXk9IjUgNCIvPgogIDx0ZXh0IHg9Ijg2IiB5PSI0ODQiIGZvbnQtc2l6ZT0iMTEiIGZpbGw9IiMxZjI5MzciPlR3byBpbmRlcGVuZGVudCBhdXRob3JpemF0aW9ucyAmIzgyMTI7IEFnZW50IEEncyBvdXRib3VuZCBzY29wZSBTX2EgaXMgYm91bmRlZCBvbmx5IGJ5IGl0cyBwYXNzcG9ydCBjZWlsaW5nLDwvdGV4dD4KICA8dGV4dCB4PSI4NiIgeT0iNTAyIiBmb250LXNpemU9IjExIiBmaWxsPSIjMWYyOTM3Ij5ub3QgYnkgU19oICYjODIxMjsgYW5kIGVhY2ggaG9wIGtlZXBzIGl0cyBvd24gYXVkaXQgcmVjb3JkLCBzbyBubyBzaW5nbGUgaG9wIHNlZXMgdGhlIHdob2xlIGNoYWluLjwvdGV4dD4KCiAgPCEtLSBmb290bm90ZSAtLT4KICA8dGV4dCB4PSI0NTAiIHk9IjU0NiIgdGV4dC1hbmNob3I9Im1pZGRsZSIgZm9udC1zaXplPSIxMC41IiBmb250LXN0eWxlPSJpdGFsaWMiIGZpbGw9IiM0NzU1NjkiPlRoZSAmIzE2NzsyLjEgLyAmIzE2NzsyLjIgY2hlY2tzIHJ1biBpZGVudGljYWxseSBldmVyeSB0aW1lIChkZXRlcm1pbmlzdGljKTsgd2hpY2ggY291bnRlcnBhcnR5IHRoZSBhZ2VudCBkaXNjb3ZlcnMsIGFuZCBpbiB3aGF0IG9yZGVyLCBpcyBlbWVyZ2VudC48L3RleHQ+CiAgPHRleHQgeD0iNDUwIiB5PSI1NjIiIHRleHQtYW5jaG9yPSJtaWRkbGUiIGZvbnQtc2l6ZT0iMTAuNSIgZm9udC1zdHlsZT0iaXRhbGljIiBmaWxsPSIjNDc1NTY5Ij5PbmUgcmVwcmVzZW50YXRpdmUgdHJhY2UuIElsbHVzdHJhdGl2ZTsgJiMxNjc7Mi4xJiM4MjExOyYjMTY3OzIuMyBhcmUgYXV0aG9yaXRhdGl2ZS48L3RleHQ+Cjwvc3ZnPgo=) *Figure: The two independent authorizations across the hop boundary — §2.1 (human → Agent A) and §2.2 (Agent A → Agent B). This is one representative trace: the §2.1/§2.2 checks run identically every time, while the agent's discovery of which counterparty to call is emergent.* The two authorizations are **independent**: * The human's scope set `S_h` authorizes the request *to* Agent A. It is not, by default, propagated upstream. * Agent A's outbound scope set `S_a` is constrained only by Agent A's own passport ceiling — not by `S_h`. * Agent B authorizes Agent A purely on the basis of `S_a` and `required_B`. Agent B does not (and cannot, without additional mechanism) see `S_h`. Implementations **MAY** apply additional per-hop policy. The two common patterns: * **Independent (default).** Each hop's authorization is its own decision. Recommended for most deployments. Audit MUST record both authorizations. * **Reduction (delegated).** Agent A computes `S_a = S_a_max ∩ map(S_h)` where `S_a_max` is its passport ceiling and `map(...)` projects human-scope vocabulary to upstream-scope vocabulary. This is conceptually equivalent to OAuth 2.1 Token Exchange \[RFC8693] with `actor_token` set to Agent A's passport. Implementations that adopt this pattern **MUST** document the mapping and **MUST** record the source human scopes in the audit trail. In all cases, implementations **MUST** maintain an audit record per hop containing: the inbound credential's scopes, the tool invoked, the required scopes, and the outcome. The audit chain reconstructs end-to-end authority even though no single hop sees the entire chain. ### 2.4 Effective Scope Computation[​](#24-effective-scope-computation "Direct link to 2.4 Effective Scope Computation") For a single authorization decision at any hop: ``` required = tools[i].security.scopes if declared, else security.scopes presented = OAuth token scopes ∪ proof.scopes ∪ out-of-band binding for key/cert (whichever applies) effective = required ∩ presented authorized = (required ⊆ presented) ``` When `authorized` is false, `(required \ presented)` (set difference) gives the missing-scope list returned in the structured error. For agent-to-agent specifically, the additional ceiling check is: ``` ceiling = caller_passport.security.scopes ceiling_satisfied = (proof.scopes ⊆ ceiling) ``` A request fails authorization if `ceiling_satisfied` is false, even when `authorized` would be true. The ceiling check **MUST** run before the required-scope check; an out-of-ceiling request is a misbehavior that the verifier **MUST** distinguish from an insufficient-scope request in audit logs. ### 2.5 Composition with §1 Authentication[​](#25-composition-with-1-authentication "Direct link to 2.5 Composition with §1 Authentication") Authorization (§2) **MUST** be evaluated only after authentication (§1) succeeds. The relationship is strictly layered: | Step | What it establishes | | --------------------------- | ------------------------------------------------------------------------------ | | §1.1 Verification Procedure | The passport is authentic and the calling identity is who it claims | | §1.2 Presentation Proof | The current request is bound to that identity right now | | §10.3.3 Credential Schemes | An OAuth 2.1 / OIDC / mTLS / API-key bearer is present (for non-agent callers) | | §2 Authorization Scopes | The authenticated party may perform this specific operation | A failure at any §1 step **MUST** prevent §2 evaluation. Conversely, §2 success without §1 success is a defect — implementations **MUST NOT** authorize requests against unauthenticated identities, even when the requested scope set looks sufficient. This is the OAuth 2.1 `unauthenticated → no scope decision` invariant carried into the agent-to-agent path. ### 2.6 Examples[​](#26-examples "Direct link to 2.6 Examples") **Root + per-tool override:** ``` { "security": { "scopes": ["invoices:read", "invoices:write"] }, "tools": [ { "name": "list_invoices", "security": { "scopes": ["invoices:read"] } }, { "name": "approve_invoice", "security": { "scopes": ["invoices:write", "invoices:approve"] } }, { "name": "search_help", "security": { "scopes": [] } } ] } ``` `list_invoices` narrows the root requirement to read-only. `approve_invoice` adds a tool-specific `invoices:approve` scope beyond the root. `search_help` explicitly requires no scopes (e.g., a public help search). **Agent-to-agent presentation proof carrying scopes:** ``` { "adl_proof": "1.0", "iss": "https://agents.acme.example/finance-bot", "iat": "2026-05-06T14:30:00Z", "exp": "2026-05-06T14:35:00Z", "jti": "01HW8YQ7K9X2N3T4M5R6S7V8W9", "request": { "method": "POST", "uri": "https://agents.acme.example/invoice-processor/tools/approve_invoice" }, "scopes": ["invoices:write", "invoices:approve"], "signature": { "algorithm": "Ed25519", "value": "...", "signed_content": "canonical" } } ``` The verifier (`invoice-processor`) checks that `["invoices:write", "invoices:approve"]` is a subset of `finance-bot`'s passport ceiling, then checks that the `approve_invoice` tool's required scopes are a subset of those, then proxies the call. *** ## IANA Considerations[​](#iana-considerations "Direct link to IANA Considerations") This document requests the registrations below, following \[RFC8126] and the HTTP registration procedures of \[RFC9110]. ### HTTP Authentication Scheme[​](#http-authentication-scheme "Direct link to HTTP Authentication Scheme") IANA is requested to add the following entry to the "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" (\[RFC9110] §16.4.1): | Authentication Scheme Name | Reference | | -------------------------- | --------------------- | | `ADL` | This document, §1.2.7 | The `ADL` scheme appears only in a `WWW-Authenticate` challenge, carrying a single verifier-issued `nonce` auth-param (`WWW-Authenticate: ADL nonce="…"`) on a `401 Unauthorized` response; the presenter echoes the value in the presentation proof's `nonce` member (§1.2.7). It does not define an `Authorization`-header credential. ### HTTP Field Names[​](#http-field-names "Direct link to HTTP Field Names") IANA is requested to add the following entries to the "Hypertext Transfer Protocol (HTTP) Field Name Registry" (\[RFC9110] §16.3.1): | Field Name | Status | Reference | | ------------------ | --------- | --------------------- | | `ADL-Passport` | permanent | This document, §1.2.5 | | `ADL-Passport-URL` | permanent | This document, §1.2.5 | | `ADL-Proof` | permanent | This document, §1.2.5 | > **Note (\[RFC6648]).** These field names omit the deprecated `X-` prefix, per \[RFC6648]. ADL has no deployed base that used `X-`-prefixed forms, so the unprefixed names are registered directly and no `X-` aliases are defined. No media type is registered by this document. The passport is conveyed base64-encoded in `ADL-Passport` (or dereferenced via `ADL-Passport-URL`) and validated against the ADL JSON Schema; the presentation proof is conveyed base64-encoded in `ADL-Proof` and validated against the structure in §1.2.2. ## Security Considerations[​](#security-considerations "Direct link to Security Considerations") This section consolidates the security properties and residual risks of the §1 authentication and §2 authorization procedures. The presentation-proof threat model (§1.2.1) and the no-leak authorization rules (§2.1) are normative where stated; this section summarizes them and adds operational guidance. **Passports are public; presentation proofs are not optional.** A passport is not secret (§1.2.1): an attacker may obtain a complete, valid, signed passport from a discovery endpoint, a registry, or network capture. Authentication of a *request* therefore **MUST** rely on the per-request presentation proof (§1.2), which binds the passport to the request method, URI, time window, and `jti` under a signature the attacker cannot produce. Accepting a passport without a fresh proof (outside the §1.2.10 waivers) re-opens the replay vector the proof exists to close. **did:web trust anchor.** When identity is resolved via `did:web` (§1.1.3, \[W3C.DID-WEB]), the verification key is only as trustworthy as the TLS and DNS for the DID's domain: whoever controls `https://{domain}/.well-known/did.json` controls the key. Compromise of the domain, its TLS certificate, or its DNS permits key substitution. Verifiers **SHOULD** pin or monitor did:web keys for high-value counterparties and **MUST** apply the §1.1.8 provider-coherence checks. An unsigned or URN-only document remains Trust-On-First-Use (§1.1.3) and **MUST NOT** be elevated above the trust of the channel that delivered it. **Replay-cache integrity and exhaustion.** Replay prevention (§1.2.6.6) requires a `jti` cache with a TTL at least the maximum proof lifetime. Two operational hazards follow. (1) *Distribution:* the cache is scoped to the verifier instance; a horizontally-scaled verifier whose instances do not share the cache can accept the same `jti` once per instance within the window. Deployments that scale a logical verifier across instances **SHOULD** use a shared or replicated `jti` store, or restrict the freshness guarantee to single-instance verifiers and rely on server-issued nonces (§1.2.7) for stronger binding. (2) *Exhaustion:* an attacker can flood the cache with distinct `jti` values; verifiers **SHOULD** bound cache size, rate-limit unauthenticated presentations, and use the proof's short `exp` (≤ 5 minutes, §1.2.3) as the eviction horizon. **Clock skew.** The bounded skew tolerance (§1.2.8; default 60 s, maximum 5 min) limits the window in which a captured proof could be replayed before the `jti` cache is consulted; deployments **MUST NOT** widen it beyond the §1.2.8 maximum. **No information leakage on failure.** Authorization failures **MUST** return only the structured outcome and **MUST NOT** leak data the caller was attempting to access (§2.1); the `WWW-Authenticate: Bearer error="insufficient_scope"` response (\[RFC6750]) names missing scopes only to the extent the caller is already entitled to know them. **Algorithm agility.** Signatures are verified over the JCS canonicalization of \[RFC8785] with Ed25519 RECOMMENDED; verifiers **MUST** reject weak or unknown signature algorithms (per the ADL Core cryptographic floors) rather than downgrading. ## References[​](#references "Direct link to References") ### Normative References[​](#normative-references "Direct link to Normative References") * **\[RFC2119]** Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, . * **\[RFC3986]** Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, . * **\[RFC6648]** Saint-Andre, P., Crocker, D., and M. Nottingham, "Deprecating the 'X-' Prefix and Similar Constructs in Application Protocols", BCP 178, RFC 6648, . * **\[RFC6750]** Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, . * **\[RFC8126]** Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, . * **\[RFC8174]** Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, . * **\[RFC8785]** Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, . * **\[RFC9110]** Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, . * **\[W3C.DID-WEB]** Guy, A., et al., "did:web Method Specification", W3C Credentials Community Group, . * **\[ADL-CORE]** Nederveld, T., "Agent Definition Language (ADL)", the Core document of this specification family; see [/spec](/spec/.md). ### Informative References[​](#informative-references "Direct link to Informative References") * **\[RFC8693]** Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, . * **\[RFC9449]** Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, .