See https://support.esign-app.com for eSign Documentation and Support

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Current »

All persistent eSign data (e.g. Signatures) resides ONLY within each Customer’s host Jira instance (e.g. https://<customername>.atlassian.net). See the following Atlassian support article on data residency for host Jira instances (https://support.atlassian.com/security-and-access-policies/docs/understand-data-residency-and-realms/).

In operation, eSign requires temporary access to Jira Host instance data to implement electronic signature functionality. This information is retrieved via the Atlassian Jira API (encrypted in transit) and used temporarily by eSign during signature processing; it is not permanently stored.

The eSign processing servers are hosted securely by AWS. The eSign processing servers are hosted securely by AWS. See https://aws.amazon.com/compliance/iso-certified/ for more information on AWS security compliance and accreditation.

The following table identifies the Jira data that is accessed temporarily by the eSign servers and why each is necessary.

Jira API

Fields Accessed (Not Stored)

Purpose

Jira Configuration

Project name, enabled Issue Types, defined User Fields and allowed Issue States

eSign workflow controls allow restricting Signatures to User Fields. The list of defined User Fields is retrieved for eSign Configuration (e.g. Reporter, Assignee, Custom).

eSign allows restricting Signature function by Issue State (e.g. Open/In Progress)

Project display name and issue types are displayed on the Verification Report

Issue Data

Project, Issue Status, User Fields (subset)

Issue Status is required to enforce workflow status restrictions configured at the project level. The contents of User fields configured in eSign as restricted User Fields are accessed to determine if the current user is permitted to execute a signature on that issue.

Issue Data

Issue Type, Summary, Description, Attachment metadata

Signature verification requires a cryptographic link to the contents of the issue. The Issue Summary, Description and Attachment (metadata) is hashed into a checksum that is stored with each executed signature. This checksum is used during signature verification to detect if issue contents or attachments were changed after signing.

Note that attachments file contents are not accessed; the attachment checksum is based on the metadata only (e.g. filename, date/time, size).

User Data

Display Name, Time zone and Locale, E-mail Address

The user name, time zone and locale are retrieved to populate the signee name and local date/time for the electronic signature.

E-mail address is used only to send transactional notification email (e.g. Signature Pin Reset)

  • No labels