Skip to content
ENETDocumentation is only available in English.
Marketplace (opens in a new tab)

Electronic signature terms

Draft. These terms take effect when SignPlus is published on the Atlassian Marketplace.

1. Scope

1.1 These terms apply to the creation of electronic signatures with SignPlus for Confluence (the “Application”). They supplement the application licence (the “Licence”) and form part of the Application’s Documentation within the meaning of clause 7.1 of the Licence. Terms defined in the Licence have the same meaning here.

1.2 Where these terms and the Licence conflict, the Licence governs, except that clause 4 of these terms states the Application’s limitations as clause 7.1 of the Licence provides.

1.3 The processing of personal data by the Application is described in its privacy notice.

2. Who provides the signature

2.1 Oktul OÜ is not a trust service provider and does not create, validate or preserve electronic signatures. The Application prepares a document from a Confluence page and sends it, with the details of each signer, to Dokobit, which provides the signing service.

2.2 A signature is created by the signer, with an identification and signing method Dokobit supports, on Dokobit’s signing page. The Application has no access to a signer’s credentials, personal code or PIN.

2.3 Dokobit states that it is a qualified trust service provider for the validation of electronic signatures and seals under Regulation (EU) No 910/2014 (“eIDAS”), supervised by the Communications Regulatory Authority of the Republic of Lithuania and listed on the EU Trusted List. Its compliance page carries its certificates and practice statement. The qualified certificate behind a qualified electronic signature is issued to the signer by the trust service provider behind their eID, not by Dokobit and not by Oktul. Dokobit identifies the provider as Dokobit, UAB (registry code 301549834) in its terms of service.

2.4 Which Dokobit account a signing runs on is decided by the signing mode:

  • Your own token: the customer’s own Dokobit account. The customer’s agreement with Dokobit governs the signing service, its fees and its availability.
  • Test: Dokobit’s test environment. A document signed in this mode carries Dokobit’s watermark, can be signed only with test identities, and has no legal effect.

3.1 Under Article 25(2) of eIDAS, a qualified electronic signature has the equivalent legal effect of a handwritten signature. An advanced electronic signature, and any other electronic signature, may not be denied legal effect and admissibility as evidence solely because it is electronic, under Article 25(1).

3.2 The level of signature a signing requires is set by the customer, under E-signature levels in the Application’s settings. Oktul does not advise on, and does not warrant, whether a signature of a given level, format or method meets a requirement of law, of a court, of a public authority or of a counterparty for a particular document or in a particular jurisdiction. That assessment is the customer’s.

3.3 The signed file is the evidence of what was signed. A Confluence page, its byline and the Application’s records are not.

4. What the Application guarantees, and its limits

4.1 The document. The document sent for signing is a rendering of the Confluence page as the person who started the signing could see it at the moment it was rendered, laid out with the site’s export styling, followed by the page’s attachments where they were included. The limits of that rendering are stated in what the document contains. The customer can produce the same document without starting a signing, and should review it before a signing is started.

4.2 Change detection. The Application records, with each signing, a SHA-256 hash of the page’s space id, page id and version number, and reports whether the page’s current version still matches it. This detects that the page was edited after it was sent for signing. It does not identify what changed, and it does not cover the content of other pages, files or systems the page displays.

4.3 Page restrictions. Where chosen, the Application restricts editing of the page to the Application, and viewing of it to the participants, while a signing runs. A Confluence space administrator, and on some Confluence plans an organisation administrator, can always remove or bypass a page restriction. The Application cannot make a page unchangeable.

4.4 Completion. A signing is recorded as complete only after the Application has obtained the signed file from Dokobit and attached it to the page. A notice that a signing was declined is acted on only after Dokobit confirms it.

4.5 Availability. A signing depends on the availability of Dokobit, of the Atlassian platform and of the signer’s identification method, none of which Oktul controls. Clause 12.3 of the Licence applies.

5. The customer’s responsibilities

5.1 The customer is responsible for:

  • the content of the page sent for signing, and the customer’s right to send it to Dokobit;
  • naming the right signers, and the accuracy of the names and email addresses given for them;
  • choosing the signing mode, the signature level, the format and the signing methods suited to the document;
  • reviewing the document before a signing is started;
  • keeping the signed file for as long as the customer needs it as evidence, in accordance with clause 6.

5.2 The customer must not use a document signed in Test mode as a signed document.

6. Retention of signed files

6.1 The signed file is attached to the Confluence page and is subject to the customer’s Confluence retention. Oktul keeps no copy. Deleting the signing’s record in the Application does not delete the signed file.

6.2 Dokobit keeps a copy for the period stated in the privacy notice. Long-term preservation of a signature’s validity, for example by archive timestamping, is not part of the Application. A customer who needs it uses a preservation service of its choice.

7. Changes

7.1 A change to these terms is recorded in the release notes and made in accordance with clause 19 of the Licence.