adobesign v1.0.0

The pack names a reference, never a secret. Installing a pack registers capabilities and makes them governable; registration is not connectivity. The credential is created at the provider and held in the client's own secret manager under the reference the pack names, and deployment testing is still required to show the credential path works and cannot be bypassed.

Reference

secret-ref-adobesign-oauth-token

Custody

customer_vault

Injection

header (Authorization)

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 <token>'. 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. Tokens can be revoked via Adobe's /oauth/v2/revoke endpoint; revocation of a refresh token also revokes access tokens issued from it. Least 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'. Note 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. Executor 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.

• adobesign-account-agreements (api, pii): https://adobesign-account.invalid/api/rest/v6/agreements
• adobesign-account-librarydocuments (api, internal): https://adobesign-account.invalid/api/rest/v6/libraryDocuments
• adobesign-account-users (api, pii): https://adobesign-account.invalid/api/rest/v6/users

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. This 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. Documented 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 registered at the pii class. The review state is draft, not library, for a concrete reason: this pack's custody model — an OAuth access token held in the customer's vault and refreshed by an external process — has not yet been reviewed against the properties the capability-library plan (docs/gtm/CAPABILITY-LIBRARY-PLAN.md §4) gates any authentication mode on: issuance authority and delegation, scope, audience, TTL, refresh ownership, revocation, executor access and bypass paths. That review is unfinished. 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 reviewer with a browser should confirm the per-operation scope table in the interactive reference before promotion.

Draft review record dated 2026-09-21 · Reviewer: aaes-eng (an opaque id that resolves internally to the responsible reviewer)

• 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)

A pack review is not a vendor or examiner attestation. A retrieval date says when a source page was read; it does not by itself establish what the page said then. No pack is vendor-endorsed, and none has been connectivity-tested against a live vendor tenant.