Table of Contents


  1. Preface
  2. Understanding Data Types and Field Properties
  3. Designing Processes
  4. Using and Displaying Data
  5. Designing Guides
  6. Designing Process Objects
  7. Designing Service Connectors
  8. Using Connectors
  9. System Services, Listeners and Connectors

2. Design

2. Design

Digital Signature Functions Overview

Digital Signature Functions Overview

Using the digital signature functions available for Process Designer, you can use XQuery to create processes and service connectors that handle signing of content. The supported functions are either:
  • Symmetric, signed using Hash-based Message Authentication Code (HMAC), which is based on a shared password and key, and allows you to use multiple key formats.
  • Asymmetric, signed using private keys (for example, PKCS8, PKCS12, Java KeyStore).
One common use for signed digital content is to allow for API authentication in a service connector, which allows you to use hashing and related functions on string-based content. For example, you might need to use signed headers as part of the payload
For more information on each of the functions, see Using Functions.
There are currently no supported functions to verify signed content, or to sign binary content.


The HMAC signing method is used with many services, including:
  • Amazon Web Services (AWS)
  • Twitter OAuth
Process Designer supports HMAC SHA1, HMAC SHA256, and HMAC SHA512 with Base64, Hex, Hex64 or Base64Url encoding. For example, you might use one of these functions to sign content for AWS:
  • dsig:hmacSignature( $data as xs:string, $key as xs:string, $algorithm as xs:string, $encoding as xs:string? ) as xs:string
  • dsig:hmacSHA1signature( $data as xs:string, $key as xs:string, $encoding as xs:string? ) as xs:string
  • dsig:hmacSHA256signature( $data as xs:string, $key as xs:string, $encoding as xs:string? ) as xs:string
  • dsig:hmacSHA512signature ( $data as xs:string, $key as xs:string, $encoding as xs:string?) as xs:string

AWS Authentication

The AWS REST API requires the authentication header in this format:
Authorization: AWS AWSAccessKeyId:Signature
Signature = dsig:hmacSHA1signature($strToSign, "
The AWSAccessKey and AwsSecretKeyId are generated by AWS and accessible through the AWS Developer Console.
$strToSign is combination of HTTP header values and other parameters.
For more information on REST authentication for AWS, see:

Asymmetric Private Key-Based Signing

The following private key methods are supported:
  • PKCS8
  • PKCS12
  • Java KeyStore
If using a private key to sign content, the keystore file must reside on a Secure Agent and the process or service connector must run on the Secure Agent in order to access the key. The file path to the key must be specified in the object properties (for example, "C:/certs/mykey.p12").
You can also:
  • Deploy the PKCS8/12 artifact on an agent contribution and specify its location using the 'project:/' scheme.
  • Supply the key using encoded key content instead of a file location, which may be useful during development of a service connector. For example, you can paste the encoded content into a text area for test purposes.

PKCS8 Key File

To sign with the PKCS8 key file, use this function:
dsig:signWithKeyFile( $messageToSign as xs:string, $pathToKey as xs:string, $encryptionAlgorithm as xs:string, $digestAlgorithm as xs:string ) as xs:string
The key file can be binary or in Base64-encoded format.
P12 and Keystore Based Files
To sign with a P12 or KeyStore-based file, use this function:
dsig:signWithCertificate( $messageToSign as xs:string, $pathToCertificate as xs:string, $keyRecoveryPassword as xs:string, $encryptionAlgorithm as xs:string, $digestAlgorithm as xs:string ) as xs:string
For example, you can use this method for Google JWT (JSON Web Token) Authentication for service accounts. After you obtain a Google private key for access and save it on your Secure Agent, you create a JWT request and sign it with your private key.