E-Signing Functional description

Transcription

1 Nets Norway AS Haavard Martinsens Vei 54 NO-0045 Oslo T F Foretaksregisteret NO E-Signing Functional description Version: 2.9 Date: p. 1-59

2 Contents 1. Introduction... 5 Purpose... 5 Intended audience... 5 Referenced documentation... 5 Terms and definitions... 6 Acronym... 7 Change log... 8 Contact information E-Signing overview and functions... 9 Architecture... 9 Interfaces... 9 Security... 9 Notification eid providers eid hosting E-Ident E-Archive ID-Rights SDO PAdES Use cases Become customer Multisignature signing flow Gathering an InsertOrder The InsertOrder message Documents One or several documents Document formats and sizes The XML document format XML Examples Identification before signing (RequiresAuthentication) Signers End user Merchant Notification XML example Merchant Channels Notification Web context WebContext element Normal GUI Reduced GUI XML example Execution details Deadlines Signing process Steps Sequential signing Parallel signing Combination signing

3 Summary of order execution Post processing Archive Administration of orders Intro Order status Step status Signing process status Administration messages Get signing processes Get order status Get order details Get order Get orders Cancel order Modify order deadline Modify Signing Processes Get documents Get SDO Get SDO details Merge SDOs Validate SDO GetNotificationLog Delete Document Data Get PAdES Generate PAdES SignWeb Intro Normal GUI Reduced GUI Iframe in Iframe Forcepkivendor Using ID-Rights with E-Signing Overview Functions The Organizations element The B2BPostProcessing element Response messages affected by ID-Rights Example Notices Notifications Intro Notification triggers Reminder settings and SMS notification Useful information Intro E-Signing java client API Supported XML schema versions System requirements SDO validator Support Request new functionality Appendix A: A complete example of an InsertOrder. 54 Content of example

4 XML example

5 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 developers. Referenced documentation Document Nets E-Archive-E- Signing Implementation Guide Nets E-Archive Implementation Guide Nets E-Signing Sign- Web Integration Guide Nets RMS Interface Specification Nets TrustNotificationMessage Interface Specification Nets TrustSign- Message Interface Specification Nets UDD Style Guide RMSMessage XML Schema TrustNotification- Message XML Schema TrustSignMessage XML Schema Description An implementation guide on how to use the E- Archive together with E-Signing. An implementation guide on how to integrate directly to the E-Archive web services. This document describes the integration to SignWeb like the use of WebContexts, technicalities involved with reconfiguring sign process page flows and more. A detailed description of the RMSMessage XML schema A detailed description of the E-Signing Notification service. This document describes the XML messages in the TrustSignMessage communication protocol for accessing E-Signing. The UDD Style guide gives guidelines on how to implement custom style sheets and information on various constraints involved with implementing the SignWeb application within the Merchant site. The schema defining the RMSMessage XML message structure. The schema defining the TrustNotification XML message structure. A schema defining the TrustSignmessage XML message structure. 5-59

6 Terms and definitions Term eid provider End user Merchant Merchant certificate Order Partial SDO Reminder Signed Data Object Signer Signing order Description Equivalent to ID provider or PKI provider, i.e. BankID, BuyPass, NemID etc. The Customer s customer, signatory, signer or other physical person with which the Customer has a relationship regarding signing of electronic documents utilising E-Signing. A legal entity that is a E-Signing customer. Websites or electronic services that use the Service for secure identification, signing, archiving and/or inquiries to ID-Rights. A company can have one or more Merchants. The company/merchants eid certificate. This is equivalent to the Norwegian Virksomhetssertifikat or Brukerstedssertifikat, the Swedish Förlitande sertifikat and the Danish Virksomhedssignatur (VOCES). A construct holding documents, End users, notification rules and execution details. 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. A reminder is a setting that may only exist on a Signing process and is a notification message. A reminder has a StartTime and an interval 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. A Signed Data Object (SDO) is an XML document holding signatures and certificate revocation data along with the signed documents. This structure may be considered as an obliging digital contract and is the outcome of all SignProcesses. See the SDO section in chapter 2. An End user or Merchant that performs a signing operation. 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 6-59

7 TrustSignMessage XML interface. Signing process Signing URL Step StepNumber Trigger A Signing process is constructed holding information about a single signer, a single document, a single WebContext and optionally a deadline and reminder settings. A Signer may only sign one document at a time. An URL that is constructed by E-Signing. If accessed, this URL will start a Signing process. 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. Each Step has a StepNumber. The Step- Numbers are given in ascending order, and the Step with the lowest StepNumber is executed first. A Trigger is a setting that is found on the NotificationChannel 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 HTTP HTTPS NTP PDF PKI SDO SEID SDO SMS SSL UTC HyperText Markup Language HyperText Transfer Protocol Secure HTTP Network Time Protocol Portable Document Format Public Key Infrastructure Signed Data Object Samarbeidet om Elektronisk ID Detailed information about SEID SDO: SEID_Leveranse_3_v1.0.pdf Short Message Service Secure Socket Layer Coordinated Universal Time UTF-8 A character encoding format of ISO (RFC 3629) XML XMLDSIG XSL extensible Markup Language XML Digital Signature XML Stylesheet Language 7-59

8 Change log This is a list of the changes done to this document: Version Description Date 2.0 The document has been restructured and updated with new word template and new service name. 2.1 Updated with: Merchant signing is no longer limited to BankID (NO) and Buypass in the eid hosting section of chapter2. - New version of SDO list figure in the SDOsection of chapter2. - Information about document sizes in Document formats and sizes 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. 2.3 Added information about the parameter forcepkivendor. Removed Mobile BankID (SE) from list of eid s as this is now a part of BankID (SE). 2.4 Updated information about E Archive, a new XML message (DeleteDocumentData) and a new order status. 2.5 Minor error correction Error corrections Added information about PAdES Updated with new last page picture for PAdES 2.9 Added note in the PAdES section 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: [email protected]. Business related questions should be directed to: [email protected]. 8-59

9 2. E-Signing overview and functions Architecture Interfaces Merchants and End users communicates with E-Signing through the following interfaces: - TrustSignMessage XML scheme - TrustNotificationMessage XML scheme o This is the XML notification interface used to notify Merchants about changes to Signing orders in E-Signing. See chapter 8 about notifications and the Nets TrustNotificationMessage XML Interface specification for more information. - 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 calling 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 twoway SSL using client certificates issued by the Nets CA Eurida. 9-59

10 Notification eid providers Notifications may be sent to both the Merchant and the Signer. More information about notifications is found in chapter 8. 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 (Sweden) - 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 integration guide and the Nets TrustSignMessage XML Interface specification. eid hosting E-Ident E-Archive E-Signing hosts a customer s Merchant certificate on behalf of the Merchant. 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 document, 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. The E-Ident service has been integrated with E-Signing to identify a user prior to presenting the document. The functionality used here is Identification before signing, and if confidentiality protection of the document to be signed is required this function can be used. 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 operating in different countries with different organisation numbers. The archival status can be retrieved from E-Signing using any of the administration messages GetOrder, GetOrders, GetDocuments, GetOrderDetails 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 possibility 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 structure)

11 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 challenging to visualize for the customer. Digitally signed documents also require 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 document at a proven time in the past. The SEID SDO is a XML based data package designed to act as a selfcontained validation of one or more digital signatures on one or more documents. 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 requested) 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 VALIDATION DATA (OCSP or CRL) SIGNATURE DATA SEAL SIGNATURE VALIDATION DATA (OCSP or CRL) SIGNATURE DATA DOCUMENT META DATA 1-n KEYVALUEPAIR A seal is a signature over the document and the signatures. The customer s merchant/organization certificate hosted by E-Signing is used to seal 11-59

12 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: 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 documents, and the standard is maintained by ETSI (ETSI TS ). Information about the standard and links to documents may be found at Wikipedia: 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 standard without the use of signature policy. The signed document are following the LTV-profile (TS ) with the use of a TSA service from GlobalSign. 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 appending 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 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 already priced in your agreement, please contact [email protected] to retrieve the price list and an offer

14 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 customer 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 document 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 user s contact information. The document format is depending on the eid to be used. Most eid s support TEXT or PDF. d. The execution details about signing deadlines and archival information. e. Merchant XML notification when the Signing order is com

15 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 requests E-Signing for a Signing URL using the GetSigningProcesses 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 interface. This redirect may happen inside an IFRAME at the Merchant 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 specified 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 ( or SMS) when the Signing URL is ready

16 Multisignature signing flow The figure above is a sequence diagram describing the workflow in a Signing 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 complete 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 when his Signing process is ready for signing - The Signers have to use the eid defined by the Merchant for signing - The order must be completed by :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 notification channel. The notification channel is set to be triggered when the signer s 16-59

17 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 rejection flag, TerminateOnSignerRejection, 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 rejection flag, TerminateOnSignerRejection, is set to true. iii. Step 3 holds a Signing process that references to signer3 and document 3. The SigningProcess rejection flag, TerminateOnSignerRejection, is set to true. 2. The first signing process with signer 1 and document 1 is set to the Active status. This triggers an notification to signer 1 from the E-Signing notification service. The requests signer1 to sign document 1 by accessing the Signing URL attached to the Signer1 accesses the Signing URL and completes his Signing process. 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 process 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 notification to signer 2. The requests signer2 to sign document 2 by accessing the Signing URL attached to the Signer2 accesses the Signing URL and completes his Signing process. The signing process is completed and receives the Complete status. As this is the only signing process in the second step, the 17-59

18 step is also set to Complete. 7. The Merchant is again notified about the completed signing process. 8. The signing process in step 3 is now Active. This triggers an notification to signer 3. The requests signer3 to sign document 3 by accessing the Signing URL attached to the Signer3 accesses the Signing URL and completes his Signing process. 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 Merchant can use the GetSDO message to retrieve the signed document container

19 4. Gathering an InsertOrder The InsertOrder message The InsertOrder message in the TrustSignmessage interface is the main XML message to E-Signing. This chapter aims to give Merchants guidance 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 particular 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

20 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 Document). 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 InsertOrder 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 document UTF-8 bytes must be Base64-encoded

21 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 particular eid. eid BankID (NO) / Bank- ID-app BankID på mobil (NO) BankID (SE) NemID with keycard ( nøglekort ) (DK) NemID with keyfile ( nøglefil ) (DK) Telia e-legitimation (SE) Recommended document size (base64 encoded) 3 MB 116 characters 2 MB 3 MB 1 MB 1 MB Note: It is recommended to test the size of your document. When testing the document sizes, test both to add an InsertOrder to E-Signing 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 The XML document format Signing an XML-document is supported, but must be handled slightly different 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: <Document> <LocalDocumentReference>DOC1</LocalDocumentReference> <Presentation> <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: <Document> <LocalDocumentReference>DOC1</LocalDocumentReference> <Presentation> <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: <Document> <LocalDocumentReference>DOC3</LocalDocumentReference> <Presentation> <Title>The title for DOC3</Title> <Description>The description for DOC3</Description> </Presentation> <DocType> <XML> <B64XMLBytes>the xml bytes b64 encoded</b64xmlbytes> <B64XSLBytes>the xsl bytes b64 encoded</b64xslbytes> </XML> </DocType> </Document> 22-59

23 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 (RequiresAuthentication) 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 themselves before signing. The identification and signing will be performed using 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, hosted by E-Signing (often referred 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 customer. This signer signs documents using a web browser

24 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 signingoperation. 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 CertificatePolicy 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 document 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 meaningful since it will not be displayed during the signing operation. But it must be unique because it is referenced to later in the InsertOrder request

25 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 Notification element must reside in the EndUserSigner element. The Notification 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 notification settings are defined. A Channel element may represent an , an SMS or an XML Service channel. The NotificationChannel holds a communication channel and the Triggers. 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 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 reminder is sent. <Signer> <EndUserSigner> <LocalSignerReference> </LocalSignerReference> <Name>Signer1</Name> <AcceptedPKIs> <BankID> 25-59

26 <CertificatePolicy>Employee</CertificatePolicy> <SignerID> <IDType>SSN</IDType> <IDValue> </IDValue> </SignerID> </BankID> </AcceptedPKIs> <Notification> <NotificationChannels> <NotificationChannel> <Channel> < > </ > </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 Channels The Merchant can set up a Signing order with a number of notification channels. The supported merchant communication channels are: - XML - SMS - 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 WebContext is a set of URLs that tells E-Signing where an End user is supposed to perform the signing process. A Merchant inserts a Signing 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 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 document. 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 channel and the trigger OnSignProcessReady, the End user will receive an holding the SignURL when it is his turn to sign. The SignURLBase is the signing URL prefix. When a Signing order is inserted into E-Signing the WebContext is registered for later use. When a Merchant 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 document Nets E-Signing SignWeb Integration guide. XML example <WebContext> <LocalWebContextRef>WebCtx_1</LocalWebContextRef> <SignURLBase> <ErrorURL- Base> <StyleURL> <ExitURL> </WebContext> 28-59

29 Execution details The ExecutionDetails element in the InsertOrder message is where the execution of the order is defined. This element holds the following information: - The order deadline - An option to set the DisplayProcessInfo element. The presence of this element with the value true tells E-Signing to display additional information about the document being signed to the End user. 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 signing 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. - Steps and Signing processes

30 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 after 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 reminder 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 contain 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

31 - Step 1 with StepNumber 1. This tells E-Signing that this Step is going to be executed first. All Signing 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 going 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 going 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 signers. 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 order containing a parallel signing workflow has to define only one step. All Signing processes residing in a Step are allowed to be executed simultaneously

32 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 signers - 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 Post processing The PostProcessing element includes all information about archival. The PostProcessing element was introduced in the XML schema version 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-Archive User guide and Nets E-Archive Implementation Guide

34 5. Administration of orders Intro Order status 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. The different Signing order statuses are listed in the table below Status Active Description 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 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 message. ExpiredBy- Proxy RejectedBySigner 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. 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 ModifyOrderDeadline message. 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 Failed 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 archival. 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. 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 34-59

35 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 particular order. Step status The different Step statuses are listed in the table below: Status Active Pending CancelledBy- Merchant Expired ExpiredBy- Proxy RejectedBySigner Description 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. A Step is set to Pending if the previous Steps have not been completed. The Step is given the CancelledByMerchant status is the Merchant sends a CancelOrder message to E-Signing. The Step is set to Expired if the Step s deadline has been reached. This can be modified using the ModifyOrderDeadline message. 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. 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 Pending CancelledBy- Merchant Expired RejectedBySigner A Signing process is set to Pending if the Signing process is not ready for signing. The previous Steps have not been completed. The Signing process is given the CancelledByMerchant status is the Merchant sends a CancelOrder message to E-Signing. The Signing process is set to Expired if the Signing process deadline has been reached. This can be modified using the ModifyOrderDeadline message. 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 GetSigningProcesses message is used to fetch all signing processes for a given order and signer. The message uses OrderID and LocalSignerReference 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 Signing 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 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 processing of the order has been done. Post processing 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 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 message above for a comparison of these two messages. Get order details Get order Get orders 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. The GetOrder XML message returns the original InsertOrder the way it was inserted by the Merchant. This message uses the OrderID as input. The GetOrders message is a search message that can filter on order status, 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 Modify order deadline 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. The ModifyOrderDeadline message is used to modify an orders deadline. This message uses the 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 Modify Signing Processes The ModifySigningProcess message offers the ability to set a signing process to the RejectedBySigner state. Get documents Get SDO 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, LocalDocumentReference (optional), ReturnDocument and ReturnSDO as input parameters. The GetSDO message returns the complete SDO for a specified Signing order if the Signing order status is Complete. This message uses the OrderID 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 message must be used to fetch the signed document. This message 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 signatures of two SDOs into one SDO which then includes all the signatures. 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 Validate SDO GetNotificationLog 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. The GetNotificationLog message returns information about all notifications 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 notification, it is recommended to implement this message. Delete Document Data The DeleteDocumentData message offers functionality to delete documents, 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, Expired, RejectedBySigner, Failed, CancelledByMerchant and ExpiredByProxy. 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 including 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 during 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 outlined in the last-page table has indeed signed the PDF document

40 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 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 (default graphical user interface), or as part of the merchant s own web application (reduced graphical user interface). Normal/default and reduced are SignWeb terms for how the interface is rendered towards the End user. GUI Normal/default user interface Reduced user interface Description SignWeb presents the Signing process within a standardized visual profile including a Nets Technology color scheme, page navigation, response messages, and user experience SignWeb suppresses all standard visual elements 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 provide customizable visual elements to the End user during the Signing process user interaction. Please refer to the Nets E-Signing SignWeb Integration Guide for detailed information on how the WebContext is used. The guide also describes in detail how to utilize the WebContext when embedding 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 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 InsertOrder 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 7 Navigation elements with links to help information 42-59

43 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 information. 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 AcceptedPKIs. The parameter and the usage of this are described in Nets E-Signing Signweb integration guide

44 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 Services portfolio from Nets. It automates the process flow and secures signing rules and procuration when businesses are entering 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 ([email protected]) or support ([email protected]). Read more about the ID-Rights service in ID-Rights Functional description. Functions E-Signing uses the following functions in ID-Rights: - Verify procuration and signing rights (after all documents have been signed) - Fetch and attach a business certificate to the signed document (at

45 tached in the SDO structure) After all documents in an InsertOrder (see Nets TrustSignMessage interface 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 procuration and the signing rights of one or more documents. The Business Certificate(s) will be attached to the SDO. The Business Certificate(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 organization 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 AttachBusinessCertificateToSDO 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

46 The B2BPostProcessing element The B2BPostProcessing element consists of one or several SignAndProcuraVerification elements. The Merchant can set which organizations signing rules or procuration that shall be verified on which document. It is also possible to specify specific Signers that must have signed the specified document. Note: This verification will succeed even though more people than necessary have signed the document. If a signature or procuration check fails (the Signers of the document(s) do not have the right signing rights or procuration), it is possible to terminate the entire InsertOrder and set the status of the InsertOrder to Failed. This is done using the TerminateOnSPCheckFails. Note: If using this function, when the InsertOrder is set to failed, the SDO from the order will not be archived. Response messages affected by ID- Rights The following E-Signing response messages are affected by ID-Rights: - GetOrderResponse - GetOrdersResponse - GetDocumentsResponse - GetOrderDetailsResponse - GetOrderStatusResponse The above responses are updated with a StatusNote explaining the status of the procuration and signing rights check. Example Merchant A (organization number ) wants to make a mutual contract with merchant B (organization number ). Signer A and B will sign document A for merchant A and Signer C and D will sign document A for merchant B. Signer A also has a business interest in Merchant B so it is important that Signer A are not used for validation the signature rights for Merchant B. The XML examples are not 100% correct, the meaning of this is only to help understanding the structure and functionality

47 We have 2 organizations: <Organization> <LocalOrganizationRef>OrgA</LocalOrganizationRef> <OrganizationNumber>111111</OrganizationNumber> </Organization> <Organization> <LocalOrganizationRef>OrgB</LocalOrganizationRef> <OrganizationNumber>222222</OrganizationNumber> </Organization> <SignAndProcuraVerification> <LocalOrganizationRef>OrgA</LocalOrganizationRef> <LocalDocumentReference>DocA</LocalDocumentReference> </SignAndProcuraVerification> <SignAndProcuraVerification> <LocalOrganizationRef>OrgB</LocalOrganizationRef> <LocalDocumentReference>DocA</LocalDocumentReference> <Signers> <LocalSignerReference>SigC</LocalSignerReference> <LocalSignerReference>SigD</LocalSignerReference> </Signers> </SignAndProcuraVerification> So for Merchant A the verify message towards ID-Rights will contain all signers that has signed document A (Signer A, B, C, D). The verify message for Merchant B will only contain Signer C and D. The Signers element cannot contain signers that have not signed the specific document. Notices Enkeltmannsforetak and Business certificate: An Enkeltmannsforetak does not usually have a business certificate registered, and if it is registered that a business certificate should be fetch for an Enkeltmannsforetak the Signing order will fail. Scenario: The Merchant wants to verify the signature rights for an organization. The organization is an Enkeltmannsforetak, and the organization does not have a business certificate registered in BRREG. The Merchant has in addition to a check for the signature rights of the organization set the following in the InsertOrder: - <Organization> -> <AttachBusinessCertificatetoSDO> = true - <SignAndProcuraVerification> - > <TerminateOnSPCheckFails> = true The Signing order will in this case be set to Failed. The StatusNote in for 47-59

48 example an GetOrderStatusResponse will be as follows: <StatusNote>[SignAndProcuraVerificationStatus=Failed] [BusinessCertificateStatus=Failed][SealStatus=Complete]</StatusNote> To avoid that the Signing order is set to Failed, it is recommended to use the GetBusinessInterest function in ID-Rights, prior to set up the Signing order. If the business is of type Enkeltmannsforetak, it is advice not to ask for a Business certificate

49 8. Notifications Intro The Merchant can be notified using XML, SMS and/or as notification channels and the Signer can be notified using SMS and/or as the notification channels. Notification triggers Here is a list of events that trigger a notification. Some of the events will only trigger a notification to the Merchant, and not to the Signer. See the Recipient column for the possible receiver of the event. Event Recipient Description OnOrderCancellation OnOrderCompletion OnOrderRejection OnOrderExpiration OnOrderFailed Merchant Signer Merchant Signer Merchant Signer Merchant Signer Merchant Signer A Signing order has been cancelled by the Merchant. The Signing order status is now Cancelled, and a cancelled notification is distributed. A Signing order has been completed. The Signing order status is now Complete and a complete notification is distributed. A Signing order has been set to the RejectedBySigner state. The optional reject text from the End user is included. See the Order status section in chapter 5 on how to reach the RejectedBySigner status. A Signing order deadline has passed. The Signing order status is now Expired. The Signing order has failed, and the Signing order status is now Failed. OnStepReady Merchant Means that the Merchant will receive a notification to the Channel specified whenever a step switches its state to Active. OnStepExpiration Merchant Means that the Merchant will receive a notification to the Channel specified when a step is expired. OnStepCompletion Merchant Means that the Merchant will receive a notification to the Channel specified when a step completed successfully. OnSignProcessReady Signer Means that the End user will receive a notification when a signing process is ready to be executed. This is triggered when a signing 49-59

50 OnSignProcessRejection OnSignProcessExpiration OnSignProcessCompletion Merchant Merchant Signer Merchant process is set to the Active state. Means that the Merchant will receive a notification when a signing process is rejected by a signer. The optional reject text from the End user is included. Means that the recipient will receive a notification when a signing process is expired. Means that the Merchant will receive a notification when a signing process completed successfully. OnReminderEvent Signer This Trigger must be seen in combination with a signing process. If set, the signer will receive a reminder notification if the ReminderSettings is present on any of the signing processes that involves this signer. Reminder settings A reminder is a setting that may only exist on a Signing process and is a notification message. A reminder has a StartTime and an interval in hours. A reminder is sent to the signer referenced to in a Signing process if the StartTime 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. The start time must be: - after NOW - after the preceding Step s deadline if it exists - before the SigningProcessDeadline if it exists, else - before the StepDeadline in the Step it resides in, if it exists, else - before the OrderDeadline and SMS notification and SMS notification are available with default texts from Nets. The texts are available in the following languages: - Norwegian - Danish - Swedish - English notifications are sent from the address: [email protected]. It is not possible to reply to that address

51 9. Useful information Intro This chapter includes some useful information. E-Signing java client API Supported XML schema versions A java client API is offered as a tool to integrate the Merchants system with E-Signing. See the Nets E-Signing java API Implementation guide for more information. The following XML schema versions are supported: - TrustSignMessage TrustSignMessage TrustSignMessage TrustSignMessage TrustSignMessage TrustSignMessage TrustSignMessage System requirements The application using E-Signing must run on a computer that has a system clock synchronized using NTP (Network Time Protocol). E-Signing is synchronized to UTC. SDO validator A SDO validator is available at The SDO validator offers this functionality: - Statement of the document validity - View the document - List of the signers - Document title - Information about the seal of the SDO The SDO validator can either be used manually by browsing for files or a Merchant can call the validator using HTTP POST to force validation of a specific SDO. When browsing for a file, the document must be stored on disk with the file ending.sdo. The following is an example on how to use the HTTP POST: 51-59

52 Step 1 Merchant send an http post to the validator. This HTML FORM is an example: <input type="file" name="localfile" class="file_input" onchange="this.form.submit()" /> </form> The SDO validator returns a URL to the Merchant like: <form method="post" enctype="multipart/form-data" name="sdoupload" action=" preprod.bbs.no/sdoval/viewfile.jsp?reqid=2bf3b8ae- 4d80-42bc-b0f2-8d5d3a3fdfc6 Step 2 The Merchant directs the End user to the URL returned in step 1. Note: The URL are only valid for 10 minutes. Here is an example of the SDO validator: The validator is currently available in English, Norwegian, Swedish and Danish

53 Support Nets esecurity support is available using the e- mail address. The support is available on working days between 8:00 and 16:00. Request new functionality Contact Nets esecurity Sales at to request new functionality for the Merchant like expanded eid support, usage of E- Archive and usage of ID-Rights

54 10. Appendix A: A complete example of an InsertOrder This chapter includes an example of a complete InsertOrder message. Content of example The example InsertOrder involves: - Three documents - Merchant notification - Two signers - Two different webcontexts Information about the documents: Information about the two signers: 54-59

55 Information about the Web context: Information about the order of execution: 55-59

56 XML example <TrustSignMessage xmlns=" xmlns:xsi=" <MerchantID>9999</MerchantID> <Time> T11:45:53+00:00</Time> <MessageID>1</MessageID> <InsertOrder> <OrderID>merchant </OrderID> <OrderDescription>Demo order with 2 signers and 3 documents</orderdescription> <Documents> <Document> <LocalDocumentReference>DOC1</LocalDocumentReference> <Presentation> <Title>The title for DOC1</Title> <Description>The description for DOC1</Description> </Presentation> <DocType> <PDF> <B64DocumentBytes>the pdf bytes b64 encoded</b64documentbytes> </PDF> </DocType> </Document> <Document> <LocalDocumentReference>DOC2</LocalDocumentReference> <Presentation> <Title>The title for DOC2</Title> <Description>The description for DOC2</Description> </Presentation> <DocType> <TEXT> <B64DocumentBytes>the text bytes b64 encoded</b64documentbytes> </TEXT> </DocType> </Document> <Document> <LocalDocumentReference>DOC3</LocalDocumentReference> <Presentation> <Title>The title for DOC3</Title> <Description>The description for DOC3</Description> </Presentation> <DocType> <XML> <B64XMLBytes>the xml bytes b64 encoded</b64xmlbytes> <B64XSLBytes>the xsl bytes b64 encoded</b64xslbytes> </XML> </DocType> </Document> </Documents> 56-59

57 57-59 <Merchant> <Notification> <NotificationChannels> <NotificationChannel> <Channel> <XMLService> <URL> </XMLService> </Channel> <Triggers> <Trigger>OnOrderCompletion</Trigger> <Trigger>OnOrderExpiration</Trigger> <Trigger>OnOrderRejection</Trigger> </Triggers> </NotificationChannel> </NotificationChannels> </Notification> </Merchant> <Signers> <Signer> <EndUserSigner> <LocalSignerReference> </LocalSignerReference> <Name>Signer1</Name> <AcceptedPKIs> <BankID> <CertificatePolicy>Employee</CertificatePolicy> <SignerID> <IDType>SSN</IDType> <IDValue> </IDValue> </SignerID> </BankID> </AcceptedPKIs> <Notification> <NotificationChannels> <NotificationChannel> <Channel> < > </ > </Channel> <Triggers> <Trigger>OnSignProcessReady</Trigger> <Trigger>OnOrderCompletion</Trigger> <Trigger>OnReminderEvent</Trigger> </Triggers> </NotificationChannel> </NotificationChannels> </Notification> </EndUserSigner> </Signer> <Signer> <EndUserSigner> <LocalSignerReference> </LocalSignerReference>

58 58-59 <Name>Signer2</Name> <AcceptedPKIs> <BuyPass> <CertificatePolicy>Personal</CertificatePolicy> <SignerID> <IDType>SSN</IDType> <IDValue> </IDValue> </SignerID> </BuyPass> </AcceptedPKIs> <Notification> <NotificationChannels> <NotificationChannel> <Channel> < > </ > </Channel> <Triggers> <Trigger>OnSignProcessReady</Trigger> </Triggers> </NotificationChannel> <NotificationChannel> <Channel> <SMS> <PhoneNumber> </PhoneNumber> </SMS> </Channel> <Triggers> <Trigger>OnReminderEvent</Trigger> </Triggers> </NotificationChannel> </NotificationChannels> </Notification> </EndUserSigner> </Signer> </Signers> <WebContexts> <WebContext> <LocalWebContextRef>WebCtx_1</LocalWebContextRef> <SignURLBase> <ErrorURL- Base> <StyleURL> <ExitURL> </WebContext> </WebContexts> <ExecutionDetails> <OrderDeadline> T15:15:00+01:00</OrderDeadline> <GenerateOneTimeURLs>true</GenerateOneTimeURLs> <Steps> <Step> <StepNumber>1</StepNumber>

59 <SigningProcess> <LocalWebContextRef>WebCtx_1</LocalWebContextRef> <LocalDocumentReference>DOC1</LocalDocumentReference> <LocalSignerReference> </LocalSignerReference> <ReminderSettings> <StartTime> T08:00:00+01:00</StartTime> </ReminderSettings> </SigningProcess> </Step> <Step> <StepNumber>2</StepNumber> <SigningProcess> <LocalWebContextRef>WebCtx_1</LocalWebContextRef> <LocalDocumentReference>DOC2</LocalDocumentReference> <LocalSignerReference> </LocalSignerReference> </SigningProcess> <SigningProcess> <LocalDocumentReference>DOC2</LocalDocumentReference> <LocalSignerReference> </LocalSignerReference> </SigningProcess> </Step> <Step> <StepNumber>3</StepNumber> <SigningProcess> <LocalWebContextRef>WebCtx_1</LocalWebContextRef> <LocalDocumentReference>DOC3</LocalDocumentReference> <LocalSignerReference> </LocalSignerReference> </SigningProcess> </Step> </Steps> </ExecutionDetails> </InsertOrder> </TrustSignMessage> 59-59