E-Signing Functional description

(1)

p. 1 - 59 Nets Norway AS Haavard Martinsens Vei 54 NO-0045 Oslo

T +47 22 89 89 89 F +47 22 81 64 54 www.nets.eu

Foretaksregisteret NO 990 224 978

E-Signing Functional description

Version: 2.9

(2)

2 - 59

Signers ... 23 End user ... 23 Merchant ... 24 Notification ... 25 XML example ... 25 Merchant ... 26 Channels ... 27 Notification ... 27 Web context ... 27 WebContext element ... 27 Normal GUI ... 28 Reduced GUI ... 28 XML example ... 28 Execution details ... 29 Deadlines ... 30 Signing process ... 30 Steps ... 30 Sequential signing ... 31 Parallel signing... 31 Combination signing ... 32

(3)

3 - 59

Summary of order execution ... 32

Post processing ... 33 Archive ... 33 5. Administration of orders ... 34 Intro ... 34 Order status ... 34 Step status ... 35

Signing process status ... 35

Administration messages ... 36

Get signing processes ... 36

Get order status ... 37

Get order details ... 37

Get order ... 37

Get orders ... 37

Cancel order ... 37

Modify order deadline ... 37

Modify Signing Processes ... 38

Get documents ... 38

Get SDO ... 38

Get SDO details ... 38

Merge SDOs ... 38

Validate SDO ... 39

GetNotificationLog ... 39

Delete Document Data ... 39

Get PAdES ... 39 Generate PAdES ... 40 6. SignWeb ... 41 Intro ... 41 Normal GUI ... 42 Reduced GUI ... 43 Iframe in Iframe ... 43 Forcepkivendor ... 43

7. Using ID-Rights with E-Signing ... 44

Overview ... 44

Functions ... 44

The Organizations element ... 45

The B2BPostProcessing element ... 46

Response messages affected by ID-Rights ... 46

Example ... 46 Notices ... 47 8. Notifications ... 49 Intro ... 49 Notification triggers ... 49 Reminder settings ... 50

E-mail and SMS notification ... 50

9. Useful information ... 51

Intro ... 51

E-Signing java client API ... 51

Supported XML schema versions ... 51

System requirements ... 51

SDO validator ... 51

Support... 53

Request new functionality... 53

10. Appendix A: A complete example of an InsertOrder. 54 Content of example ... 54

(4)

4 - 59 XML example ... 56

(5)

5 - 59

1. Introduction

Purpose This document is a functional description and will detail the concept of E-Signing. E-Signing aims to offer Merchants:

- Advanced, yet user friendly, signing services based on digital IDs independent of eID providers.

- An easy way to integrate systems to E-Signing - Notification services and interfaces

Intended audience This document is intended for business integrators and application devel-opers. Referenced documentation Document Description Nets E-Archive-E-Signing Implementa-tion Guide

An implementation guide on how to use the E-Archive together with E-Signing.

Nets E-Archive

Im-plementation Guide An implementation guide on how to integrate directly to the E-Archive web services. Nets E-Signing

Sign-Web Integration Guide This document describes the integration to _{SignWeb like the use of WebContexts,} techni-calities involved with reconfiguring sign process page flows and more.

Nets RMS Interface

Specification A detailed description of the RMSMessage XML schema Nets

TrustNotifica-tionMessage Interface Specification

A detailed description of the E-Signing Notifica-tion service.

Nets TrustSign-Message Interface Specification

This document describes the XML messages in the TrustSignMessage communication protocol for accessing E-Signing.

Nets UDD Style Guide The UDD Style guide gives guidelines on how to implement custom style sheets and infor-mation on various constraints involved with implementing the SignWeb application within the Merchant site.

RMSMessage XML

Schema The schema defining the RMSMessage XML message structure.

TrustNotification-Message XML Schema The schema defining the TrustNotification XML message structure. TrustSignMessage

XML Schema A schema defining the TrustSignmessage XML message structure.

(6)

6 - 59

Terms and definitions

Term Description

eID provider Equivalent to ID provider or PKI provider, i.e. BankID, BuyPass, NemID etc.

End user The Customer’s customer, signatory, signer or other physical person with which the Customer has a relationship regarding signing of elec-tronic documents utilising E-Signing. Merchant A legal entity that is a E-Signing customer.

Websites or electronic services that use the Service for secure identification, signing, ar-chiving and/or inquiries to ID-Rights. A compa-ny can have one or more Merchants.

Merchant certificate The company/Merchants eID certificate. This is equivalent to the Norwegian “Virksomhetsser-tifikat” or “Brukerstedsser“Virksomhetsser-tifikat”, the Swedish “Förlitande sertifikat” and the Danish “Virk-somhedssignatur” (VOCES).

Order A construct holding documents, End users, notification rules and execution details. Partial SDO A Partial SDO is an SDO including only one

document and all signers that have signed the document at the requested time. A partial SDO is generated after each Signing process in the order.

Reminder A reminder is a setting that may only exist on a Signing process and is a notification mes-sage. A reminder has a StartTime and an inter-val in hours. A reminder is sent to the signer referenced to in a SigningProcess if the Start-Time is reached. The reminder is sent after every interval period. A reminder is sent to all channels defined on the referenced signer that has the OnReminderEvent trigger set.

Signed Data Object A Signed Data Object (SDO) is an XML docu-ment holding signatures and certificate revoca-tion data along with the signed documents. This structure may be considered as an oblig-ing digital contract and is the outcome of all SignProcesses. See the SDO section in chapter 2.

Signer An End user or Merchant that performs a sign-ing operation.

Signing order Documents, signing rules and information on the End user and/or signatory, submitted by the customer to the signing solution.

A Signing order is an order to E-Signing. The Signing order consists of the document(s) to be signed, the Signer(s), the web context, execution details. The Signing order may be equivalent to the InsertOrder message in the

(7)

7 - 59 TrustSignMessage XML interface.

Signing process A Signing process is constructed holding infor-mation about a single signer, a single docu-ment, a single WebContext and optionally a deadline and reminder settings. A Signer may only sign one document at a time.

Signing URL An URL that is constructed by E-Signing. If accessed, this URL will start a Signing process. Step A Step is a collection of Signing processes that

may be executed simultaneously. The Step with the lowest StepNumber is executed first. An order may consist of many steps. Only one Step may be Active at any given time.

StepNumber Each Step has a StepNumber. The

Step-Numbers are given in ascending order, and the Step with the lowest StepNumber is executed first.

Trigger A Trigger is a setting that is found on the No-tificationChannel element in the TrustSign-Message InsertOrder request. The value of this element tells E-Signing when to trigger a notification to the channel this element resides in.

Acronym Acronym Description

HTML HyperText Markup Language

HTTP HyperText Transfer Protocol

HTTPS Secure HTTP

NTP Network Time Protocol

PDF Portable Document Format

PKI Public Key Infrastructure

SDO Signed Data Object

SEID SDO “Samarbeidet om Elektronisk ID” Detailed information about SEID SDO:

http://www.npt.no/iKnowBase/Content/44963/ SEID_Leveranse_3_v1.0.pdf

SMS Short Message Service

SSL Secure Socket Layer

UTC Coordinated Universal Time

UTF-8 A character encoding format of ISO 10646 (RFC 3629)

XML eXtensible Markup Language

XMLDSIG XML Digital Signature

(8)

8 - 59

Change log This is a list of the changes done to this document:

Version Description Date

2.0 The document has been restruc-tured and updated with new word template and new service name.

14.03.2013

2.1 Updated with:

- Merchant signing is no long-er limited to BankID (NO) and Buypass in the “eID hosting” section of chapter2. - New version of SDO list

fig-ure in the “SDOsection” of chapter2.

- Information about document sizes in “Document formats and sizes”

20.06.2013

2.2 Information about a SDO validator added to chapter 9. Updated list of supported eIDs. Information about identification before signing and the use of the GetSigningProcesses message.

17.12.2013

2.3 Added information about the pa-rameter forcepkivendor. Removed Mobile BankID (SE) from list of eID’s as this is now a part of BankID (SE).

16.05.2014

2.4 Updated information about E-Archive, a new XML message (De-leteDocumentData) and a new order status.

16.06.2014

2.5 Minor error correction. 19.09.2014

2.6 Error corrections. 17.10.2014

2.7 Added information about PAdES. 04.11.2014 2.8 Updated with new last page picture

for PAdES 10.11.2014

2.9 Added note in the PAdES section 25.11.2014

Contact information Nets Signing and Identification Services has its own support. All technical

questions can be directed to the support. The support can be reached at:

support.esecurity@nets.eu.

(9)

9 - 59

2. E-Signing overview and functions

Architecture

Interfaces Merchants and End users communicates with E-Signing through the follow-ing interfaces:

- TrustSignMessage XML scheme - TrustNotificationMessage XML scheme

o This is the XML notification interface used to notify Mer-chants about changes to Signing orders in E-Signing. See chapter 8 about notifications and the “Nets

TrustNotifica-tionMessage XML Interface specification” for more

infor-mation. - SignWeb

o This is the interface between E-Signing and the End user (Signer). See chapter 6 for more information about Sign-Web.

Security _{The service uses signed XML messages when interacting with E-Signing. All}

messages to the service are signed using a signing certificate issued from Nets’ CA Eurida. E-Signing validates the signature, authenticates the call-ing party and performs authorization checks based on the request at hand. If the calling party is authenticated and authorized then the request are handled by E-Signing.

The communication line between the Merchant and Nets is based on two-way SSL using client certificates issued by the Nets CA Eurida.

(10)

10 - 59

Notification Notifications may be sent to both the Merchant and the Signer. More in-formation about notifications is found in chapter 8.

eID providers The following eID’s are supported in E-Signing: - BankID (Norway) / BankID-app (Norway)

- BankID on mobile phones (“BankID på mobil”) (Norway) - Buypass Smartcard (Norway)

- BankID including Mobile BankID and Nordea e-legitimation (Swe-den)

- Telia e-legitimation (Sweden) - NemID POCES (Denmark) - NemID MOCES (Denmark)

Information about the eID providers can be found in Appendix 2 – eID providers in the “Nets E-Signing Integration guide”.

Note: There might be some functions that are only available for some eID providers. The restrictions are found in both the above referred to integra-tion guide and the “Nets TrustSignMessage XML Interface specificaintegra-tion”.

eID hosting E-Signing hosts a customer’s Merchant certificate on behalf of the Mer-chant. The Merchant certificate is issued to the Merchants organization. The following is the usage of the Merchant certificate in E-Signing:

- Communication with eID providers: When using the signing applet and to validate a Signers certificate.

- To seal the SDO: The entire SDO is signed to ensure its integrity. - Merchant signing: A Merchant may be one of the Signers of a

doc-ument, and this is specified in the Signing order. If the Merchant has more than one eID enabled, the signing eID must be specified as well.

E-Ident The E-Ident service has been integrated with E-Signing to identify a user prior to presenting the document. The functionality used here is “Identifi-cation before signing”, and if confidentiality protection of the document to be signed is required this function can be used.

E-Archive A signed document (SDO) may be archived automatically in E-Archive with indexes specified when adding a Signing order to E-Signing. Documents stored in E-Archive can be retrieved using the E-Archive portal through Nets customer portal or by integrating the E-Archive web services in your Merchant application. It is also possible to archive documents to another organisation’s E-Archive as long as that organisation is whitelisted in the customer configuration. This may be useful when an organisation is operat-ing in different countries with different organisation numbers.

The archival status can be retrieved from E-Signing using any of the ad-ministration messages GetOrder, GetOrders, GetDocuments, GetOrderDe-tails and GetOrderStatus. These messages are described more in chapter 5 and in the “Nets TrustSignMessage XML Interface specification”.

ID-Rights The ID-Rights service has been integrated with E-Signing offering the pos-sibility to verify procuration and signing rights after all documents in a Signing order have been signed. It is also possible to fetch and attach Business certificates to the signed document (attached in the SDO struc-ture).

(11)

11 - 59 More information about the use of ID-Rights together with E-Signing is

found in chapter 7.

SDO A digitally signed document is often represented in formats that are chal-lenging to visualize for the customer. Digitally signed documents also re-quire a compilation of data to be able to prove in a future conflict (court case, dispute etc.) that a specific person actually signed this specific doc-ument at a proven time in the past.

The SEID SDO is a XML based data package designed to act as a self-contained validation of one or more digital signatures on one or more doc-uments. The reason for this format is to be able to confirm non repudiation and integrity of the signed document independent of time. Thus the result of a digital signing process can be packaged into a SEID SDO format to simplify validation, traceability and visualization of the signed document. A comparable format is PAdES which uses Acrobat reader to visualize the digital signature embedded in a .pdf document.

The Nets E-Signing service produces both a SDO and a PAdES file (if re-quested) as the result of a digital signing process.

The format is structured as an SDOlist with one or more SDOs. Each SDO consist of

- One document

- One or more signatures - One seal

- Signing time or validation time SDOLIST

SDO1

SIGNATURES 1-n SIGNATURE

VALIDATION DATA (OCSP or CRL) SIGNATURE DATA

SEAL

SIGNATURE

VALIDATION DATA (OCSP or CRL) SIGNATURE DATA DOCUMENT META DATA 1-n KEYVALUEPAIR SDO2 SIGNATURES 1-n SIGNATURE

SEAL

SIGNATURE

DOCUMENT META DATA

1-n KEYVALUEPAIR

A seal is a signature over the document and the signatures. The custom-er’s merchant/organization certificate hosted by E-Signing is used to seal

(12)

12 - 59 the document.

The E-Signing service can also make partial SDO’s available. A Partial SDO is a SDO including only one document and one signer. A partial SDO is generated after each signing process in the Signing order. The partial SDO is available using the GetDocuments message in the TrustSignMessage XML interface.

More information about the SEID SDO standard can be found here:

http://www.npt.no/teknisk/elektronisk-signatur/elektronisk-signatur/kva-er-seid-prosjektet/_attachment/1533?_ts=138749031b1

Nets offers a SDO validator to view and validate SDO’s. More information about the validator is found in chapter 9.

PAdES PAdES (PDF Advanced Electronic Signatures) is a standard for signed doc-uments, and the standard is maintained by ETSI (ETSI TS 102 778). In-formation about the standard and links to documents may be found at Wikipedia: http://en.wikipedia.org/wiki/PAdES

As a customer of the E-Signing service you may choose to get the signed documents in the PAdES format. E-Signing is using the PAdES-BES stand-ard without the use of signature policy. The signed document are following the LTV-profile (TS 102 778-4) with the use of a TSA service from Glob-alSign.

To retrieve the signed documents in accordance with PAdES standard there is two ways to do so in E-Signing. Firstly, you may request the document using the GetPAdES XML message, or secondly request the generation of a signed document based on a SDO using the GeneratePAdES XML message. The retrieval of the document from E-Signing with the GetPAdES message is only available for 90 days after the order has been completed.

A PDF signed document from E-Signing may only be generated from a PDF file (and not from a text or XML document signed through E-Signing). When generating the PDF signed document, the E-Signing service is ap-pending the following to the original document:

- A document reference on each side of the document

- A last page with the document reference and information about the signer(s) of this particular document.

- An extract of the signature from each signer (as an “attachment” in the document)

The document is sealed using a certificate issued to Nets Norway AS from GlobalSign.

(13)

13 - 59 The last page is added by Nets may look like this:

The last page is available in four languages:

- English (default if no other language are specified) - Norwegian

- Danish - Swedish

The default format for signed documents through E-Signing is still SDO, and this document should always be used in case of conflicts. The signed PDF document (PAdES) only includes extracts of the original signatures and not the entire signature.

Note: The use of this function may have an extra cost. If it is not al-ready priced in your agreement, please contact sales.esecurity@nets.eu

(14)

14 - 59

3. Use cases

This chapter includes a use case “become customer” with a single user and a single document and a use case with a multi signature flow.

“Become customer” This use case describes a scenario where an End user becomes a customer

of the Merchant. The use case involves the signing of one document by the End user. The agreement to become a customer is signed when the cus-tomer is inside the Merchant’s web site, and is a “synchronised” work flow.

1. The End user accesses the Merchant’s web site with the purpose of becoming a customer. At the Merchant’s web site the End users finds information about how to become a customer and a form to supply contact information.

2. The Merchant uses the below information to assemble a Signing order to use E-Signing in the signing flow. The Signing order is sent to E-Signing when completed:

a. A Signer ID like SSN or another unique ID

b. The preferred eID the End user will use to sign the docu-ment with (for example NemID, Buypass, BankID or other eID supported by E-Signing)

c. The document to be signed. This can be a preconfigured agreement that is automatically filled out with the End us-er’s contact information. The document format is depend-ing on the eID to be used. Most eID’s support TEXT or PDF. d. The execution details about signing deadlines and archival

information.

(15)

15 - 59 plete (“OnOrderCompletion” trigger).

3. The E-Signing service receives the InsertOrder XML message, and performs some internal actions before a response ok message is returned.

4. Based on the InsertOrderResponse message the Merchants re-quests E-Signing for a Signing URL using the GetSigningProcess-es message.

5. The E-signing service replies with at Signing URL to the End user’s signing process.

6. The Merchant redirects the End user to the E-Signing SignWeb in-terface. This redirect may happen inside an IFRAME at the Mer-chant’s web site or as a redirect to a Nets branded web site. E-Signing display’s the specified eID providers signing client with the document to be signed. The End user’s reads the document and signs it inside the eID provider’s applet.

7. The E-Signing SignWeb interface redirects the End user back to the Merchant’s web site.

8. The E-Signing service generates a SDO (the format of the signed document) and archives the document in Nets E-Archive (if speci-fied in the Signing order).

9. The E-Signing notification service sends a XML notification to the Merchant’s system informing the Merchant that the signing process is complete. The Merchant has just got a new customer.

10.A customer service representative at the Merchant may access the E-Archive using either a portal or web services to view the new agreement.

The sequence in this use case shows how the simplest possible Signing order is executed. This order fulfils the minimum criteria’s: one signer and one document. The figure illustrates a synchronous signing workflow where the order is created and signed by the End user within the current End user session/sequence.

E-Signing also supports asynchronous workflow. Asynchronous workflows allow Merchants to create orders not initiated by the End user. These could be created by merchant applications as part of internal processes (e.g. by customer service representatives). For such a workflow, step 1 in the above sequence does not exist and the End user is notified (email or SMS) when the Signing URL is ready.

(16)

16 - 59

Multisignature signing flow

The figure above is a sequence diagram describing the workflow in a Sign-ing order that involves three signers. The three signers complete their signing processes one after the other. The signers do not have the option of signing in the same time frame (parallel signing). We will have a look at how such a Signing order is assembled.

The order should fulfil the following merchant criteria’s:

- There are three documents. It is crucial that document one is signed by signer one before document two is signed by signer two. And then document three should be signed by signer three to com-plete the order.

- The merchant wants a notification after each signing operation (Signing process) and when the Signing order is completed. - It is important that the merchant gets notified if any of the signers

reject their Signing processes, since a rejection could terminate the entire order.

- Each signer must get a notification by email when his Signing pro-cess is ready for signing

- The Signers have to use the eID defined by the Merchant for sign-ing

- The order must be completed by 15.04.2009 12:00 AM. The sequence diagram in the figure shows the following:

1. The merchant assembles an InsertOrder request according to its own criterias and sends it to E-Signing. E-Signing sends a success response. The order contains the following:

a. 3 documents.

b. 3 signers. Each signer is defined with a social security number and an email notification channel. The email notifi-cation channel is set to be triggered when the signer’s

(17)

17 - 59 Signing process is ready.

c. An XML service notification channel for the merchant itself (The InsertOrderMerchant element. See the Merchant section in chapter 4). This channel is set to be triggered if a Signing order is rejected and each time a Signing process is completed and when the Signing order as a whole is complete.

d. The order deadline. e. 3 steps.

i. Step 1 holds a Signing process that references signer1 and document 1. The Signing process re-jection flag, TerminateOnSignerRere-jection, is set to true. This means that the order is terminated if this signer rejects signing the document.

ii. Step 2 holds a Signing process that references signer2 and document 2. The Signing process re-jection flag, TerminateOnSignerRere-jection, is set to true.

iii. Step 3 holds a Signing process that references to signer3 and document 3. The SigningProcess rejec-tion flag, TerminateOnSignerRejecrejec-tion, is set to true.

2. The first signing process with signer 1 and document 1 is set to the Active status. This triggers an email notification to signer 1 from the E-Signing notification service. The email requests signer1 to sign document 1 by accessing the Signing URL attached to the email.

3. Signer1 accesses the Signing URL and completes his Signing pro-cess. The signing process is completed and receives the Complete status. As this is the only signing process in the first step, the step is also set to Complete.

4. The Merchant has requested to be notified when each signing pro-cess is complete. Therefore, the E-Signing notification service sends an XML message to the Merchant saying just that.

5. The signing process in step 2 is now Active. This triggers an email notification to signer 2. The email requests signer2 to sign docu-ment 2 by accessing the Signing URL attached to the email. 6. Signer2 accesses the Signing URL and completes his Signing

pro-cess. The signing process is completed and receives the Complete status. As this is the only signing process in the second step, the

(18)

18 - 59 step is also set to Complete.

7. The Merchant is again notified about the completed signing pro-cess.

8. The signing process in step 3 is now Active. This triggers an email notification to signer 3. The email requests signer3 to sign docu-ment 3 by accessing the Signing URL attached to the email. 9. Signer3 accesses the Signing URL and completes his Signing

pro-cess. The signing process is completed and receives the Complete status. As this is the only signing process in the second step, the step is also set to Complete. This is also the last step in the Signing order. The order is set to Complete

10.The Merchant is again notified about both the completed signing process and the completed Signing order.

The merchant has the option to retrieve information about the Signing order, both during and after completion of the Signing order. The Merchant can use any of the administration messages in the TrustSignMessage web service to request information. The GetOrderStatus is a useful message. The signed document (SDO) holds all the signer signatures along with the signed documents and acts as a digital contract. The SDO is the proof that the signing processes took place. The SDO can either be archived in E-Archive (this must be defined in the InsertOrder message) or the Mer-chant can use the GetSDO message to retrieve the signed document con-tainer.

(19)

19 - 59

4. Gathering an InsertOrder

The InsertOrder

message The _{XML message to E-Signing. This chapter aims to give Merchants guidance}InsertOrder message in the TrustSignmessage interface is the main

on how to assemble a Signing order.

The figure below shows an overview of this message.

Each Signing order must have a unique OrderID. The OrderID is used to keep track of Signing orders sent to E-Signing. The OrderID is a string with a maximum length of 40 characters.

Each Signing order may have an OrderDescription describing this par-ticular Signing order.

In the following section the rest of the elements in the InsertOrder are described in details.

A complete example of an InsertOrder message involving two signers and three documents is shown as an appendix in chapter 10.

(20)

20 - 59

Documents

One or several

documents A Signing order must contain one or more documents.

For each document that is going to be added to the Signing order, a new Document element must be created (InsertOrder  Documents  Doc-ument).

To add a document to the InsertOrder request do the following: - Create a new Document-element

- Give the document a LocalDocumentReference. This is a label that must be unique for every Document-element in the current Inser-tOrder request. This label is referenced later in the InsertOrder request when the Signing Processes are assembled.

- Give the document a Title. This will be displayed to the Signer and should give him an idea of the contents of the document. - Give the document a Description. This should be something that

gives meaning to the Signer of this document. The description is presented to all End users signing this document.

- If the document is a PDF, provide the document content as a base64-encoded byte-array

If the document is a TEXT, provide the document UTF-8 bytes. The docu-ment UTF-8 bytes must be Base64-encoded.

(21)

21 - 59

Document formats

and sizes The support of document formats are depending on the eID the End user is going to use when signing the document. The formats supported in E-Signing are:

- PDF - Text - XML

Regarding which document format supported for your eIDs, see one of the appendices in the “Nets E-Signing Integration guide”.

There is a maximum limit for the size of each Signing order and the size of a document. This limit is currently set to 5 MB for both. This means that it is possible to create a Signing order with one document with the size of 5 MB. If there are several documents in the Signing order, the total must not exceed 5 MB.

However, Nets has tested the document sizes for some of the eIDs, and below is the currently recommended size limit of a document for a particu-lar eID.

eID Recommended document size (base64

encod-ed) BankID (NO) /

Bank-ID-app 3 MB

“BankID på mobil”

(NO) 116 characters

BankID (SE) 2 MB

NemID with keycard

(“nøglekort”) (DK) 3 MB NemID with keyfile

(“nøglefil”) (DK) 1 MB Telia e-legitimation

(SE) 1 MB

Note: It is recommended to test the size of your document. When test-ing the document sizes, test both to add an InsertOrder to E-Signtest-ing and to fetch the document using GetSDO or GetDocuments.

Further, when using NemID, be aware that the SDO may become quite large when using both a large document and several signers. This is due to the fact that a SDO with NemID signatures includes the document itself + NemID signatures, and all NemID signatures include both the signature and the document itself. The SDO may therefore be doubled, tripled, and so on in size dependent on the number of signers. This may result in problems using the GetSDO and GetSDODetails functions from E-Signing.

(22)

22 - 59

The XML document

format Signing an XML-document is supported, but must be handled slightly dif-ferent from the merchant’s point of view. The issue to keep in mind here is how to present the XML to the End user.

XML Examples _The_Document_{element XML for a PDF document will be like:}

<Title>This is the title</Title>

<Description>This is the desc</Description> </Presentation> <DocType> <PDF> <B64DocumentBytes>ANSGKFLSDSF==</B64DocumentBytes> </PDF> </DocType> </Document>

The Document element XML for a TEXT document will be like:

<Title>This is the title</Title>

<Description>This is the desc</Description> </Presentation> <DocType> <TEXT> <B64DocumentBytes> ANSGKFLSDSF==</B64DocumentBytes> </TEXT> </DocType> </Document>

The Document element XML for a XML document will be like:

<Title>The title for DOC3</Title>

<Description>The description for DOC3</Description> </Presentation>

<B64XMLBytes>the xml bytes b64 encoded</B64XMLBytes> <B64XSLBytes>the xsl bytes b64 encoded</B64XSLBytes> </XML>

</DocType> </Document>

(23)

23 - 59 Identification before signing (RequiresAuthentic ation)

It is possible to force End users to identify themselves before presenting the document to be signed. The Identification before signing (RequiresAu-thentication) function is typically used when the content of the document to be signed is sensitive. This field is a true/false parameter.

If the parameter is set to true, the End users will need to identify them-selves before signing. The identification and signing will be performed us-ing the same eID provider.

For some eID’s the SSN from the InsertOrder will be used as a presetID, and the End user will not be presented with the page in the applet where the SSN is provided. The eID’s having this feature is dependent on eID’s with the possibility to set SSN as PresetID in E-Ident.

Signers

The Signers element is mandatory and must contain at least one Signer element. A Merchant may want to sign a document with its own eID, host-ed by E-Signing (often referrhost-ed to as Merchant certificate). This is done by specifying a MerchantSigner. A Signer may either be an EndUserSigner or a MerchantSigner.

End user _An_{EndUserSigner}_{is typically an End user who is the merchant’s}

(24)

24 - 59 To add an EndUserSigner to the InsertOrder request we have to do the following:

- Create new SignerEndUserSigner elements

- Give each EndUserSigner a LocalSignerReference. This is a label that must be unique for every Signer element in the InsertOrder request. The LocalSignerReference value does not need to be something meaningful since it will not be displayed during signing-operation. But it must be unique because it is referenced to later in the InsertOrder request.

- Provide a name for each EndUserSigner. This element is optional and cannot be verified by E-Signing, but it is highly recommended using the persons real name since this may be shown in the GUI during the End user signing process.

- The Merchant may define the AcceptedPKIs element. This element tells E-Signing which eID provider the End user can choose from when signing a document. The Merchant’s supported eID providers are already registered in E-Signing. The AcceptedPKIs must only contain eIDs that are also supported by the Merchant. For each eID specified in the AcceptedPKIs element, the Merchant may tell which SignerID the End user must have. In the CertificatePoli-cy element the Merchant has the option to mandate which eID (profile) the End user must use when signing a document. See the description about the forcepkivendor parameter as an option to the AcceptePKIs element in section Forcepkivendor of chapter 6.

Merchant

By defining a MerchantSigner, the Merchant tells E-Signing to sign a doc-ument on behalf of the Merchant using its own eID. The signer is not a physical person. E-Signing uses the Merchant’s eID hosted by E-Signing to sign the document.

To add an MerchantSigner to the InsertOrder request you have to do the following:

- Create new SignerMerchantSigner element

Give the MerchantSigner a LocalSignerReference. This is a label that must be unique for every Signer element in the InsertOrder request. The LocalSignerReference value does not need to be something mean-ingful since it will not be displayed during the signing operation. But it must be unique because it is referenced to later in the InsertOrder re-quest.

(25)

25 - 59

Notification

The Merchant may want to notify End users or get notified itself on special events regarding a Signing order. To setup End user notification, the Noti-fication element must reside in the EndUserSigner element. The Noti-fication element holds NotificationChannels which may contain at least 1 NotificationChannel element. A NotificationChannel element holds a Channel and a Triggers element. This is where the actual notifica-tion settings are defined. A Channel element may represent an Email, an SMS or an XML Service channel.

The NotificationChannel holds a communication channel and the Trig-gers. The Triggers element may hold one or more Trigger elements. A Trigger element describes an event that should triggee a notification to the channel. Supported triggers for End user notifications are:

- OnOrderCancellation - OnOrderCompletion - OnOrderRejection - OnOrderExpiration - OnSignProcessReady - OnSignProcessExpiration - OnReminderEvent - OnOrderFailed

See chapter 8 for detailed description about notifications and the different triggers.

XML example _{An XML example of the}_Signer_{element. Here the Signer must use BankID}

(NO) as the eID, the Signer will be notified using e-mail when a Signing process is ready and when a Signing order is complete. If the Signer has not signed the document after some time, an e-mail reminder is sent.

<Signer> <EndUserSigner> <LocalSignerReference>01027512345</LocalSignerReference> <Name>Signer1</Name> <AcceptedPKIs> <BankID>

(26)

26 - 59 <CertificatePolicy>Employee</CertificatePolicy> <SignerID> <IDType>SSN</IDType> <IDValue>01027512345</IDValue> </SignerID> </BankID> </AcceptedPKIs> <Notification> <NotificationChannels> <NotificationChannel> <Channel> <Email> <EmailAddress>user@work.no</EmailAddress> </Email> </Channel> <Triggers> <Trigger>OnSignProcessReady</Trigger> <Trigger>OnOrderCompletion</Trigger> <Trigger>OnReminderEvent</Trigger> </Triggers> </NotificationChannel> </NotificationChannels> </Notification> </EndUserSigner> </Signer>

Merchant

The InsertOrder offers the merchant the ability to get notified on events regarding a Signing order. The Merchant element, similar to the EndUser-Signer element, may hold the Notification element.

(27)

27 - 59

Channels The Merchant can set up a Signing order with a number of notification channels. The supported merchant communication channels are:

- XML - SMS - E-mail

Note: Fax is no longer supported as a notification channel.

Notification Supported triggers for merchant channels are: - OnOrderCancellation - OnOrderCompletion - OnOrderExpiration - OnOrderFailed - OnStepReady - OnStepExpiration - OnStepCompletion - OnSignProcessRejection - OnSignProcessExpiration - OnSignProcessCompletion

Web context

WebContext

element A _{supposed to perform the signing process. A Merchant inserts a Signing}WebContext is a set of URLs that tells E-Signing where an End user is

order with the intent to have End users sign documents on the web. The E-Signing service that handles the actual signing processes is SignWeb.

(28)

28 - 59 After inserting a Signing order, the Merchant may retrieve a Signing URL. This URL is a pointer to a signing process involving an End user and a doc-ument. The Merchant chooses how the End user experiences the signing process by either redirecting the End user to SignWeb or presenting its own signing page. The SignURL can also be distributed to Endu sers via notification channels. If an End user is registered with the email channel and the trigger “OnSignProcessReady”, the End user will receive an email holding the SignURL when it is his turn to sign.

The SignURLBase is the signing URL prefix. When a Signing order is insert-ed into E-Signing the WebContext is registerinsert-ed for later use. When a Mer-chant asks for the signing URL, E-Signing generates a unique reference and appends it to the end of the SignURLBase. Signing URL = SignURLBase + <generated reference>.

Normal GUI _{By redirecting an End user to SignWeb, the End user’s browser will display}

E-Signing’s GUI. This is referred to as the normal GUI. There is no need to define a WebContext element when using this user interface.

Reduced GUI _{The merchant may want to present its own look-and-feel by having the}

End user sign documents on its own web portal. This is referred to as the reduced GUI user interface.

Details on WebContexts and the different GUIs may be found in the docu-ment “Nets E-Signing SignWeb Integration guide”.

XML example <WebContext> <LocalWebContextRef>WebCtx_1</LocalWebContextRef> <SignURLBase>http://www.merchant.no/Sign?ref=</SignURLBase> <ErrorURL-Base>http://www.merchant.no/Sign/Error?errorCode=</ErrorURLBase> <StyleURL>http://www.merchant.no/Sign/custom.css</StyleURL> <ExitURL>http://www.merchant.no/Sign/Complete</ExitURL> </WebContext>

(29)

29 - 59

Execution details

The ExecutionDetails element in the InsertOrder message is where the execution of the order is defined. This element holds the following infor-mation:

- The order deadline

- An option to set the DisplayProcessInfo element. The presence of this element with the value true tells E-Signing to display addi-tional information about the document being signed to the End us-er. In a Signing order, many signers may sign the same document. The DisplayProcessInfo element tells E-Signing to display the Name, NameStatus or NameStatusTime concerning the signers of the document involved. (Not all eID providers can show this info.) - An option to set the GenerateOneTimeURL element. This element, if

the value is true, forces E-Signing to generate OneTimeURL. A OneTimeURL can only be used once. If a End user accesses a sign-ing URL, this URL is marked as used and cannot be accessed again. The second time an End user tries to access it, they would get an error message. A OneTimeURL also has a deadline which allows it to be accessible only for a limited amount of time. The time limit is set to 10 minutes. The Merchant can get new unused URLs using the GetSigningProcesses message. The OneTimeURL functionality is meant to be used in a synchronous process.

(30)

30 - 59

Deadlines _{E-Signing gives the merchant the option to set a deadline on the order, on}

each Step and on each Signing process in a Step. The rules for order, step and signing processes deadlines:

- The OrderDeadline must be after NOW (the time E-Signing receives the order) and before NOW + 90 days. This is a limit set by E-Signing.

- A Step has a step number. Step 1’s deadline must be after NOW and before the OrderDeadline. Deadlines for Step 1+x must be af-ter the previous step’s deadline and before the OrderDeadline. - A Signing process deadline for Signing process must be after NOW

and before the StepDeadline of which the Signing process is in. If the Step and Signing process deadlines are not set by the integrator, they are automatically to set the same as OrderDeadline.

Signing process A Signing process is constructed holding information about a single signer, a single document, a single WebContext and optionally a deadline and re-minder settings. A signer may only sign one document at a time.

Steps _{A Step may hold one or more Signing processes. A Signing order may}

con-tain many Steps but only one Step may be active at a time. Each Step must contain a StepNumber which tells E-Signing the order of execution. Steps are numbered sequentially, beginning at 1.

(31)

31 - 59 - Step 1 with StepNumber 1. This tells E-Signing that this Step is

go-ing to be executed first. All Signgo-ing processes in a Step must be complete in order for a Step to get the Complete status.

- Step 2 with StepNumber 2. This tells E-Signing that this Step is go-ing to be executed after Step 1 has completed successfully. In the meantime this Step has the Pending status.

- Step 3 with StepNumber 3. This tells E-Signing that this Step is go-ing to be executed after Step 2 has completed successfully. In the meantime this Step has the Pending status.

Sequential signing

A sequential workflow is illustrated above. The figure illustrates three sign-ers. Signer1 has to complete his signing process before signer 2 and signer 2 has to complete his signing process before signer 3 is enabled to execute his signing operation.

The order of execution, in this example, is sequential and is regulated by E-Signing by the use of Steps and Signing processes. In this example, the Merchant should define three Steps with one Signing process in each Step.

Parallel signing

A parallel signing workflow is illustrated in the figure above. A Signing or-der containing a parallel signing workflow has to define only one step. All Signing processes residing in a Step are allowed to be executed simultane-ously.

(32)

32 - 59

Combination signing

If we merge the sequential and parallel Signing process examples we get a combination. The figure above illustrates a signing workflow that combines the sequential and the parallel workflows.

Below is an illustration of three steps. The first step includes one signing process, step two includes two Signing processes (parallel) and the last step includes one Signing process.

Summary of order

execution The following summarizes the concept of “the order of execution”:

- An order consist of one or more documents and one or more sign-ers

- A signer may sign many documents within the same Signing order - One signer and one document make up a Signing process.

- Steps mandate the order of execution.

- A Step’s StepNumber tells E-Signing the order of execution. All Steps must be numbered from 1 and upwards.

- A Signing order may only have one Active Step at any moment. All other steps are pending or complete.

- A Step may consist of one or more Signing processes. All Signing processes within a Step may be executed in parallel (at the same time).

(33)

33 - 59

Post processing

The PostProcessing element includes all information about archival. The PostProcessing element was introduced in the XML schema version 20140303.

Archive _{When the Signing order is completed and a SDO is generated, E-Signing}

can archive the SDO in the Nets E-Archive. This is specified in the PostProcessing element in the InsertOrder message. The name of the archive and the archival indexes must be supplied. The archive indexes are used to locate this particular signed document in E-Archive. By using the MetaData element, the customer may archive a document to another organisation number than the one registered in the customer

configuration. This may only be done if the other organisation number is whitelisted in the customers E-Signing configuration.

Note: If the Signing order includes more than one document, the SDO is divided into as many SDO’s as there are documents in the Signing order. Each SDO includes one document with all its signatures, and will be handled as one archive object. The E-Archive can be accessed either through a portal or through a web services. More information about E-Archive is found in “Nets E-E-Archive User guide” and “Nets E-E-Archive

(34)

34 - 59

5. Administration of orders

Intro E-Signing keeps track by giving the Signing order, each Step and each Signing process in each Step a status. The status hierarchy is managed by strict rules.

Order status The different Signing order statuses are listed in the table below

Status Description

Active The Active status is the first status a Signing order will be given. The Signing order is in this status as long as there are Steps with the Active status.

When the Signing order is registered it gets the Active status. Step 1 and all its Signing processes get the Active status. The rest of the Steps, and their Signing processes, get the Pending status.

Can- celledBy-Merchant

The CancelledByMerchant status is given to a Signing order when the Merchant sends a CancelOrder message on a specified Signing order to E-Signing. The Signing order is cancelled. This is a final state.

Expired The Signing order is expired. This state is applied when a deadline is reached. The Signing order can be returned to an Active status using the ModifyOrderDeadline mes-sage.

ExpiredBy-Proxy The Signing order is set to the ExpiredByProxy status when either a Step or a Signing process has reached its deadline. The deadline can be modified using the Modi-fyOrderDeadline message.

Reject-edBySigner A Signing order is set to RejectedBySigner if the following occurs: - The End user has rejected to sign a document. - The TerminateOrderOnRejection setting in the

InsertOrder is set to true

This state may also be reached if the Merchant uses the ModifySigningProcess message. This state is a final state.

Complete The Signing order is set to Complete when all steps and signing processes are completed and all post processing of an order has been completed. Post processing includes creating and sealing the SDO, send notifications and ar-chival. The Signing order will also reach this state if one or more of the Signing processes have been rejected, but the TerminateOrderOnRejection is set to false. This is a final state.

Failed A Signing order is set to Failed if one of the Signers of a document did not have the right to sign the document. This state will only occur in conjunction with the use of

(35)

35 - 59 ID-Rights functionality. This is a final state.

Deleted The Signing order is set to Deleted if the XML message DeleteDocumentData has been performed for that par-ticular order.

Step status The different Step statuses are listed in the table below:

Status Description

Active A Step is set to the Active status when the Steps prior to this Step have been completed with either a Complete or RejectedBySigner status. The first Step is set to Active at the same time as the Signing order is set to Active. Only one step may be in the Active status at the same time.

Pending A Step is set to Pending if the previous Steps have not been completed.

CancelledBy-Merchant The Step is given the CancelledByMerchant status is the Merchant sends a CancelOrder message to E-Signing. Expired The Step is set to Expired if the Step’s deadline has been

reached. This can be modified using the Modi-fyOrderDeadline message.

ExpiredBy-Proxy The Step is set to ExpiredByProxi if one or more of the Signing processes in the step have reached its deadline. This can be modified using the ModifyOrderDeadline message.

Reject-edBySigner A Step is set to RejectedBySigner if the following occurs: - The End user has rejected to sign a document. - The TerminateOrderOnRejection setting in the

InsertOrder is set to true

This state may also be reached if the Merchant uses the ModifySigningProcess message. This state is a final state.

Complete The Step is set to Complete when all Signing processes are completed. The Step will also reach this state if one or more of the Signing processes have been rejected, but the TerminateOrderOnRejection is set to false. This is a final state. The next step will now reach the Active state.

Signing process

status The different Signing process statuses are listed in the table below: Status Description

Active All Signing processes in a Step are set to Active when the Step reaches the Active status. A SignURL for the Active Signing processes are now available, and the End user can sign the document in this Signing process.

(36)

36 - 59 Pending A Signing process is set to Pending if the Signing

pro-cess is not ready for signing. The previous Steps have not been completed.

CancelledBy-Merchant The Signing process is given the CancelledByMerchant status is the Merchant sends a CancelOrder message to E-Signing.

Expired The Signing process is set to Expired if the Signing pro-cess’ deadline has been reached. This can be modified using the ModifyOrderDeadline message.

Reject-edBySigner The End user has rejected to sign the document in the Signing process. This state may also be reached if the Merchant uses the ModifySigningProcess message. This state is a final state.

Complete The End user has signed the document, and the signing process is completed. The Signing process is set to Complete. This is a final state.

Administration messages

Get signing

processes The _{for a given order and signer. The message uses}GetSigningProcesses message is used to fetch all signing processes

OrderID and LocalSign-erReference as input. Optionally, the Signing processes’ status can be specified.

In return the asking application will among other get a list of all Signing processes for this signer, status of the Signing processes, details about the document in the Signing process, the SignURL (if not signed and the Sign-ing process status is Active) and the SigningTime (if signed)

This message is often used to fetch the particular SignURL that the Signer must access to sign a document. Other ways to get a signing URL is to use either e-mail notification sent directly to the Signer or XML notification sent to the Merchant application/system.

This message is also used to check the status of a Signing process. The status of a Signing process is set to complete immediately after the signing has been performed. As a comparison, the status of an order is set to complete after all signatures has been set to complete and all post pro-cessing of the order has been done. Post propro-cessing includes creating and sealing the SDO, send notifications and archival.

Note: This message must be implemented when using E-Signing to check the status of specific Signing processes. If notification is not used this message must be implemented to retrieve the signing URL.

(37)

37 - 59

Get order status _The_{GetOrderStatus}_{XML message gives the status of all elements in a}

specified InsertOrder. The message uses the OrderID as input, and it returns the status of:

- The entire order - Each document - Each signer - Each step

- Each signing process

This is a very useful message used to keep an overview and track of all Signing orders sent to E-Signing. See also the Get signing processes mes-sage above for a comparison of these two mesmes-sages.

Get order details _The_{GetOrderDetails}_{XML message returns a subset of the}_InsertOrder

as it was inserted. The response to this message is not as comprehensive as the GetOrder response, but it gives an overview of the Signing order and the current statuses.

Get order _The_GetOrder_{XML message returns the original}_InsertOrder_{the way it}

was inserted by the Merchant. This message uses the OrderID as input.

Get orders _The_GetOrders_{message is a search message that can filter on order}

sta-tus, signers, meta data and/or time. The message uses these filters as input. The message returns a list of Signing orders corresponding to the search criteria including the OrderID, OrderStatus, OrderDeadline and some other parameters.

Be aware that this message might be time consuming, and the response time may be significant higher than other messages sent to E-Signing.

Cancel order _The_CancelOrder_{XML message offers the ability to cancel an existing}

Signing order. The message uses the OrderID as input, and if succeeded E-Signing returns a CancelOrderResponse with the OrderID and a TransRef. Transref is a transaction ID for audit purposes. If the Signing order does not exist, an ErrorResponse is returned.

Modify order

deadline The _{This message uses the}ModifyOrderDeadline message is used to modify an orders deadline.

OrderID, a ShiftValue and Notify as inputs. The ShiftValue says who many hours the original deadlines in a Signing order shall be expanded with. All deadlines will be shifted according to this value. This message can be used if a Signing order has expired before all Signing processes have been completed.

(38)

38 - 59

Modify Signing

Processes The _{process to the RejectedBySigner state.}ModifySigningProcess message offers the ability to set a signing

Get documents _The_GetDocuments_{message may return a single or all documents in the}

specified Signing order and/or the SDO or partial SDO’s. A Partial SDO is an SDO including only one document and all signers that have signed the document at the requested time. A partial SDO is generated after each Signing process in the Signing order. The message uses the OrderID, Lo-calDocumentReference (optional), ReturnDocument and ReturnSDO as input parameters.

Get SDO _The_GetSDO_{message returns the complete SDO for a specified Signing}

order if the Signing order status is Complete. This message uses the Or-derID as input. If the Signing order status is not complete, the response will be empty.

To get Partial SDOs use the GetDocuments message.

If the Merchant are not using archival through E-Signing, the GetSDO mes-sage must be used to fetch the signed document. This mesmes-sage should be sent to E-Signing just after the Merchant has been notified that a Signing order has reached the Signing order status Complete.

Note: E-Signing is only keeping signed documents for 90 days. To keep a signed document, use either this message to fetch the SDO or use the archival function through E-Signing.

A description of the SDO is found in chapter 2.

Get SDO details _The_{GetSDODetails}_{message is used to retrieve detailed information about}

the content in a SDO. This message uses the SDO as input in addition to a boolean value to verify the SDO. If the VerifySDO is set to true the SDO content integrity is validated.

The information in this message’s response can be used to extract signing information like signer, signing time, signed data and other.

Merge SDOs _The_MergeSDOs_{message gives the merchant the ability to merge}

signa-tures of two SDOs into one SDO which then includes all the signasigna-tures. This is only possible if the two original SDOs include one document each which is identical. The message uses two SDO’s as input.

Note: This message is not supported by all eIDs. See both the “Nets

E-Signing Integration guide” and the “Nets TrustSignMessage Interface specification” for information about eIDs not supported.

(39)

39 - 59

Validate SDO _The_ValidateSDO_{XML message checks the validity of a specified SDO. The}

message uses the SDO to be validated as input. The response is either valid or invalid.

GetNotificationLog _The_{GetNotificationLog}_{message returns information about all}

notifica-tions that have been sent to the merchant itself and End users involved in a specified InsertOrder. This message uses the OrderID as input. To message is useful to get an overview of all notification sent, and if the Merchant are using either XML, SMS or e-mail notification, it is recom-mended to implement this message.

Delete Document Data

The DeleteDocumentData message offers functionality to delete docu-ments, SDO’s and signatures from the E-Signing database. Documents will only be deleted if the signing order is in a final state like Complete, Ex-pired, RejectedBySigner, Failed, CancelledByMerchant and Ex-piredByProxy. An error message will be returned if the signing order is active.

This message is useful if it is important for to delete documents earlier than Nets’ regular data deletion.

Note: When using this message, ensure that you are either archiving your signed documents in a Nets archive or that you have fetch the signed document using for example the GetSDO message.

Get PAdES The GetPAdES message will return the signed document as a .pdf file in-cluding an extract of all signatures. A last page is added to the originally signed document for presentation off the signatures.

The signed PDF document according to PAdES standard is a more readable format than the SDO format for end users. See also information about PAdES in chapter 2.

Note: E-Signing is only keeping signed documents for 90 days, and it is only possible to retrieve the PAdES document from a signing order dur-ing those days.

In more detail the GetPAdES message returns a Nets-signed PDF according to the PAdES-LTV specifications. Before applying a PAdES-LTV signature, Nets appends a new page to the PDF holding a table describing the entities that signed the original document along with additional information. After modifying the original PDF by applying an informative last page, Nets acts as a notary service certifying (attesting by signing) that the entities out-lined in the last-page table has indeed signed the PDF document.

(40)

40 - 59

Generate PAdES The GeneratePAdES messages offers functionality to generate a signed PDF document (PAdES) from a SDO. The message uses a SDO as input and based on that file generates a signed PDF document (PAdES) in return. This message can be used to convert SDO’s to the a signed PDF document (PAdES) after the E-Signing service has removed the signed document of an order.

(41)

41 - 59

6. SignWeb

Intro _{SignWeb is the End user interface for E-Signing. SignWeb provides the End}

user signer with a web application front-end for accessing, viewing and executing Signing processes that Merchants create and administer. SignWeb is configurable to run either as an independent application (de-fault graphical user interface), or as part of the merchant’s own web appli-cation (reduced graphical user interface). Normal/default and reduced are SignWeb terms for how the interface is rendered towards the End user.

GUI Description

Normal/default user

interface SignWeb presents the Signing process within a standardized visual profile including a Nets Technology color scheme, page navigation, response messages, and user experience Reduced user

inter-face SignWeb suppresses all standard visual ele-ments and allows a merchant to reconfigure and layout the sign process in their own visual profile.

A WebContext is a TrustSignMessage construct that SignWeb uses to vide customizable visual elements to the End user during the Signing pro-cess user interaction. Please refer to the “Nets E-Signing SignWeb

Integra-tion Guide” for detailed informaIntegra-tion on how the WebContext is used. The

guide also describes in detail how to utilize the WebContext when embed-ding SignWeb inside the Merchant site.

Please refer to the “Nets UDD Style Guide” for specific guidelines on how to implement custom style sheets and information on various constraints involved with implementing the SignWeb application within the merchant site.

Refer also to the “Nets E-Signing SignWeb Integration Guide” to better understand the technicalities involved with reconfiguring sign process page flows.

(42)

42 - 59

Normal GUI _{The normal user interface for SignWeb has the following elements:}

Number Description

1 A page heading with optional language choices 2 The Merchant logo.

3 The Merchant description of the Signing order in plain text. The displayed text is provided by Merchant in the Inser-tOrder message

4 The eID provider client.

5 A configurable list of participating signers, and an expiry date (eID provider dependant)

6 Nets logo with associated stylesheet

(43)

43 - 59

Reduced GUI _{The reduced interface allows merchants greater flexibility at laying out the}

sign process pages and also reconfiguring the sequence of page flow. Please refer to the “SignWeb Merchant Integration Guide” for detailed in-formation.

Number Description

1 Merchant site

2 eID provider applet within the Merchant site

Iframe in Iframe When using the reduced GUI interface (IFRAME) inside another IFRAME, there are some considerations the Merchant should be aware of:

- The End users will get a warning when they accesses the Signing URL if the Merchant sets up an IFRAME that is not secure (HTTPS). - Some browsers turns of cookies for IFRAMES in as a default setting - The Merchant must be aware of the IFRAME hierarchy when exiting

an IFRAME due to errors, cancellation or completed signing.

Forcepkivendor Forcepkivendor is a parameter that can be appended to the signing URL presented to the end user. This parameter gives merchants with more than one eID the possibility to only show one or some of the eID’s configured. This parameter can be used as an option to the XML element Accept-edPKIs.

The parameter and the usage of this are described in “Nets E-Signing

(44)

44 - 59

7. Using ID-Rights with E-Signing

Overview

For usage in the business to business market, the ID-Rights service has been launched. ID-Rights is a service in the Signing and Identification Ser-vices portfolio from Nets. It automates the process flow and secures sign-ing rules and procuration when businesses are entersign-ing into agreements between each other. ID-Rights consists of a set of functions related to procuration and signing rules.

The ID-Rights service has been integrated with E-Signing for verification of procuration and signing rights after a Signing order has been completed. To start using ID-Rights, please contact either your sales representative at Nets (sales.esecurity@nets.eu) or support (support.esecurity@nets.eu). Read more about the ID-Rights service in “ID-Rights Functional

descrip-tion”.

Functions _{E-Signing uses the following functions in ID-Rights:}

- Verify procuration and signing rights (after all documents have been signed)

(45)

45 - 59 tached in the SDO structure)

After all documents in an InsertOrder (see “Nets TrustSignMessage

inter-face specification”) have been signed E-Signing can make a request to

ID-Rights asking to verify either the procuration or the signing rights of one to all documents in the InsertOrder.

E-Signing may also fetch the Business Certificate used to verify the procu-ration and the signing rights of one or more documents. The Business Cer-tificate(s) will be attached to the SDO. The Business CerCer-tificate(s) is signed by our partner, Experian.

The E-Signing message InsertOrder has been updated with some new elements to support the above functions:

- Organizations - B2BPostProcessing

The Organizations element

One InsertOrder may contain one or more Organizations. The organi-zation’s signing rights and procuration will be checked as indicated in the B2BPostProcessing element described later.

It is possible to attach the organizations business certificate to the SDO generated from the InsertOrder. To do so, set the AttachBusinessCer-tificateToSDO element to true in the InsertOrder message.

At the moment, only Norway (NO) is supported as Country.

Note; The Organizations element shall only be used if the Merchant is configured with ID-Rights in combination with E-Signing.

E-Signing Functional description

E-Signing Functional description

Contents

1.

Introduction

2.

E-Signing overview and functions

3.

Use cases

4.

Gathering an InsertOrder

Documents

Signers

Merchant

Web context

Execution details

Post processing

5.

Administration of orders

Administration messages

6.

SignWeb

7.

Using ID-Rights with E-Signing