{ "schema": "aaes/capability-pack/1", "provider": "adobesign", "version": "1.0.0", "description": "Adobe Acrobat Sign: read agreements, library documents and users, and create-and-send an agreement for signature in one account.", "notes": "The endpoint host 'adobesign-account.invalid' is a reserved non-production placeholder (an RFC 2606 reserved TLD): substitute the account's own API access point host before enabling, in the endpoints, the resource locators and the egress allowlist — the allowlist matches exactly, so all three must be substituted together, and substitution is a required deployment step. Acrobat Sign shards accounts by geography; the real substitution shape is 'api.{shard}.adobesign.com' (for example 'api.na1.adobesign.com' or 'api.eu1.adobesign.com'), and the deployment resolves the account's access point via GET /api/rest/v6/base_uris as Adobe documents — a request to the wrong shard fails with INVALID_API_ACCESS_POINT.\n\nThis pack registers only endpoints the official Acrobat Sign REST API v6 documentation describes: listing agreements, listing library documents, listing users, and creating an agreement. Reads are collection reads: single-record reads (GET /api/rest/v6/agreements/{agreementId}, GET /api/rest/v6/libraryDocuments/{libraryDocumentId}, GET /api/rest/v6/users/{userId}), document retrieval and the POST /api/rest/v6/search advanced query are not registered by this pack.\n\nDocumented exclusions: this pack does not register agreement state transitions (PUT /agreements/{agreementId}/state, which can cancel an in-flight agreement), reminders (POST /agreements/{agreementId}/reminders, which emails participants), agreement sharing, transient-document upload, library-document creation and update, widget and MegaSign creation, webhook management, and user creation or update — deliberate exclusions, not approximated capabilities. Agreement content is contractual material about identifiable signers, so agreement data is classified as pii (personal data).\n\nThe custody review that docs/gtm/CAPABILITY-LIBRARY-PLAN.md §4 gates authentication modes on was completed on 2026-09-21 against this pack's custody model (an OAuth access token held in the customer's vault and refreshed by an external process), with these findings, one per gated property.\n\nIssuance authority and delegation: tokens are minted by Adobe's authorization server for an application the customer registers, and each OAuth grant delegates restricted access on the authorizing user's behalf, with the ':account' scope modifier delegating account-wide authority where the integration must act on account-wide resources.\n\nScope: the reviewed documentation enumerates the scope names this pack needs — agreement_read, library_read and user_read for the reads, agreement_write and agreement_send for creation and send — and documents a tension the deployment must resolve at app registration: v6 best-practices guidance marks agreement_send deprecated and not accepted for some v6 endpoints while the v6 POST /agreements reference and Adobe's API FAQ list agreement_send:account for sending, so the effective scope set is confirmed against the account, not assumed.\n\nAudience: the retrieved docs document no audience claim — the bearer value authorizes against the account's own API access point (its shard host), and audience binding beyond that is not established. TTL: access tokens live one hour (expires_in 3600), and the refresh token expires after 60 days of inactivity.\n\nRefresh ownership: minting and refresh are owned by an external deployment process that writes the fresh header value into the vault; the executor injects the stored value verbatim and performs no token lifecycle itself, and a stale value fails closed.\n\nRevocation: Adobe's /oauth/v2/revoke endpoint revokes tokens, and revoking a refresh token also revokes the access tokens issued from it. Executor access and replay/exposure: the executor reads only the vault reference; the token is a bearer credential replayable within its one-hour TTL, and the 60-day inactivity expiry bounds an idle stolen refresh token.\n\nAlternate access paths: the Acrobat Sign web app and other integrations retain access outside this pack, and revoking this grant closes only this path. The custody gate is documented and passed; remaining owner placeholders bind at deployment. Source note: the interactive v6 method reference at secure.na1.adobesign.com is a JavaScript-driven console whose per-operation content could not be fully extracted during this retrieval, so the operation definitions and OAuth security requirements cited here were taken from Adobe's developer-guide apiusage page (which documents POST /api/rest/v6/agreements with the IN_PROCESS send state and the agreement_send:account scope) and the best-practices page; a deployment reviewer should confirm the per-operation scope table in the interactive reference before enabling.", "credential": { "secret_ref_id": "secret-ref-adobesign-oauth-token", "custody": "customer_vault", "inject": "header", "inject_name": "Authorization", "note": "An Adobe Acrobat Sign OAuth 2.0 access token, held in the client's own secret manager. The stored material must be the complete Authorization header value: the scheme 'Bearer', one separating space, then the access token — 'Bearer '. customer_vault is the only generally-supported production custody model here — identity_federation and customer_broker are refused at startup and inline is lab-only. Acrobat Sign access tokens are short-lived: Adobe documents an access-token lifetime of one hour (expires_in 3600), with a refresh token that expires after 60 days of inactivity, so minting and refresh must be owned by an external deployment process that writes the fresh header value into the vault — the executor injects the stored value verbatim and performs no token lifecycle itself, and a stale value fails closed.\n\nTokens can be revoked via Adobe's /oauth/v2/revoke endpoint; revocation of a refresh token also revokes access tokens issued from it.\n\nLeast privilege: request only the OAuth scopes these capabilities need — 'agreement_read', 'library_read' and 'user_read' for the reads, plus 'agreement_write' for agreement creation and 'agreement_send' for the send — with the ':account' scope modifier (for example 'agreement_send:account') and the corresponding account-level authorization where the integration must act on account-wide resources rather than only the authorizing user's own; the v6 reference for POST /agreements lists the send permission as 'agreement_send:account'.\n\nNote a documentation tension the deployment must resolve at app registration: Adobe's own v6 best-practices guidance marks 'agreement_send' as deprecated and not accepted for some v6 endpoints (for example transient documents) while the v6 POST /agreements reference and Adobe's API FAQ list 'agreement_send:account' for sending — confirm the effective scope set against the account before enabling.\n\nExecutor hygiene: the value must live only in executor memory for the lifetime of a call, must never be written to logs, traces or diagnostics, and must not appear in crash dumps; a deployment that cannot meet that bar must not enable the pack." }, "capabilities": [ { "capability_id": "adobesign.agreements.read", "version": "1.0.0", "kind": "tool", "risk_tier": "R0", "owner": "REPLACE-WITH-ACCOUNTABLE-HUMAN", "data_class": "pii", "egress_allowlist": [ "adobesign-account.invalid" ], "endpoint": "https://adobesign-account.invalid/api/rest/v6/agreements", "method": "GET", "connector": "http", "custody": "customer_vault", "secret_ref_id": "secret-ref-adobesign-oauth-token", "inject": "header", "inject_name": "Authorization", "actions": [ "read" ], "resource_id": "adobesign-account-agreements", "description": "Retrieve the user's agreements in a paginated list (filterable by group): agreement ids, names, statuses and participant information — contractual material about identifiable people, classified as pii (personal data).\n\nThe registered path covers the collection read only — single-agreement reads (GET /api/rest/v6/agreements/{agreementId}), document retrieval and the POST /api/rest/v6/search advanced query are not registered by this pack.", "requires_review": true }, { "capability_id": "adobesign.librarydocuments.read", "version": "1.0.0", "kind": "tool", "risk_tier": "R0", "owner": "REPLACE-WITH-ACCOUNTABLE-HUMAN", "data_class": "internal", "egress_allowlist": [ "adobesign-account.invalid" ], "endpoint": "https://adobesign-account.invalid/api/rest/v6/libraryDocuments", "method": "GET", "connector": "http", "custody": "customer_vault", "secret_ref_id": "secret-ref-adobesign-oauth-token", "inject": "header", "inject_name": "Authorization", "actions": [ "read" ], "resource_id": "adobesign-account-librarydocuments", "description": "Retrieve the paginated list of library documents (reusable document templates) visible to the calling user: ids, names, statuses and sharing modes — internal contract tooling, classified as internal data.\n\nThe registered path covers the collection read only — single-library-document reads are not registered by this pack.", "requires_review": true }, { "capability_id": "adobesign.users.read", "version": "1.0.0", "kind": "tool", "risk_tier": "R0", "owner": "REPLACE-WITH-ACCOUNTABLE-HUMAN", "data_class": "pii", "egress_allowlist": [ "adobesign-account.invalid" ], "endpoint": "https://adobesign-account.invalid/api/rest/v6/users", "method": "GET", "connector": "http", "custody": "customer_vault", "secret_ref_id": "secret-ref-adobesign-oauth-token", "inject": "header", "inject_name": "Authorization", "actions": [ "read" ], "resource_id": "adobesign-account-users", "description": "Retrieve the paginated list of users in the account: names, email addresses, statuses and account-admin information — employee personal data, classified as pii (personal data).\n\nThe registered path covers the collection read only — single-user reads are not registered by this pack.", "requires_review": true }, { "capability_id": "adobesign.agreements.create_send", "version": "1.0.0", "kind": "tool", "risk_tier": "R3", "owner": "REPLACE-WITH-ACCOUNTABLE-HUMAN", "data_class": "pii", "egress_allowlist": [ "adobesign-account.invalid" ], "endpoint": "https://adobesign-account.invalid/api/rest/v6/agreements", "method": "POST", "connector": "http", "custody": "customer_vault", "secret_ref_id": "secret-ref-adobesign-oauth-token", "inject": "header", "inject_name": "Authorization", "actions": [ "create", "send" ], "resource_id": "adobesign-account-agreements", "description": "Create an agreement and send it for signature in one call. The documented effect depends on the request's state field: IN_PROCESS sends the agreement immediately, while DRAFT and AUTHORING do not send. This capability registers the send: one call with state IN_PROCESS creates the agreement and starts delivery of a legally significant signature request to the named recipients — and a delivered agreement cannot be un-delivered (cancellation is a separate act that stops the signing process but does not un-send the recipient notification).\n\nNote the delivery is asynchronous, so the response is request-accepted, not delivered: Adobe processes the send in the background, and the agreement's status reads DOCUMENTS_NOT_YET_PROCESSED until that completes. OUT_FOR_SIGNATURE is a workflow state — evidence the agreement entered the signing workflow, not proof that any individual recipient received or opened a notification — so the caller confirms delivery with a subsequent read, which this pack does not register (single-agreement reads are an exclusion).\n\nThe actions are create and send at the minimum R3 tier — send is one of the designated actions requiring human approval.\n\nOn supported AAES-mediated execution paths, the declared irreversible actions require an authorized person’s approval. Observation-only and bypass calls cannot be stopped by this control.", "requires_review": true } ], "resources": [ { "resource_id": "adobesign-account-agreements", "kind": "api", "locator": "https://adobesign-account.invalid/api/rest/v6/agreements", "data_class": "pii", "owner": "REPLACE-WITH-ACCOUNTABLE-HUMAN" }, { "resource_id": "adobesign-account-librarydocuments", "kind": "api", "locator": "https://adobesign-account.invalid/api/rest/v6/libraryDocuments", "data_class": "internal", "owner": "REPLACE-WITH-ACCOUNTABLE-HUMAN" }, { "resource_id": "adobesign-account-users", "kind": "api", "locator": "https://adobesign-account.invalid/api/rest/v6/users", "data_class": "pii", "owner": "REPLACE-WITH-ACCOUNTABLE-HUMAN" } ], "review": { "state": "library", "date": "2026-09-22", "sources": [ "https://opensource.adobe.com/acrobat-sign/developer_guide/apiusage.html (retrieved 2026-09-21)", "https://secure.na1.adobesign.com/public/docs/restapi/v6 (retrieved 2026-09-21)", "https://opensource.adobe.com/acrobat-sign/developer_guide/best-practices.html (retrieved 2026-09-21)", "https://opensource.adobe.com/acrobat-sign/releasenotes/v6releasenotes.html (retrieved 2026-09-21)", "https://opensource.adobe.com/acrobat-sign/developer_guide/oauth.html (retrieved 2026-09-21)", "https://developer.adobe.com/acrobat-sign/docs/api/ (retrieved 2026-09-21)" ], "reviewer_id": "aaes-eng" } }