Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
This section will highlight important requirements or describe any additional cross-cutting requirements that apply to this Building Block.
The Cross-cutting requirements described in this section are an extension of the cross-cutting requirements defined in the architecture specification document.
HSM must be compliant to a minimum of FIPS 140-2 Level 3. This guarantees the protection of private keys. HSM/Key Management application shall not print any information about the end-use details. Keys should be created only within the HSM. This may apply to all other Building Blocks when dealing with cryptographic keys.
All audit logs shall be integrity-protected against tampering. The eSignature Building Block shall follow the data policy and audit logging requirements as laid out in the GovStack architecture.
Signing using a single key can compromise the user's privacy in the long run. For example, a single key used to sign the consent of health form and agreement of the medical insurance could reveal that the consent and the agreement are from the same person. Generally available signed documents could be used to perform 360-degree profiling. This violates the Generic Architectural Privacy recommendation. Privacy-preserving techniques can be used in signature schemes, document storage, or reducing the key's lifespan to protect the user's privacy.
The system shall provide traceability across services using trace ID or similar design patterns. (REQUIRED)
The system shall provide logs to help debug the problems. (REQUIRED)
The system shall not print sensitive information. (REQUIRED)
Private Key
User details
Authentication Token
Payment Token
Signature of the document
Full Certificate (Thumbprint is allowed to be printed)
User PIN
OTP
In case a user/mobile app is involved, then logging shall provide traceability from the app to the server. (REQUIRED)
The version history table describes the major changes to the specifications between published versions.
Version | Authors | Comment |
---|---|---|
Key Digital Functionalities describe the core (required) functions that this Building Block must be able to perform.
To facilitate the eSignature service as described in section 2, the Building Block must have specific Key Digital Functionalities.
The Hardware Security Module (HSM) is an integral part of the eSignature Building Block. The HSM ensures the protection of a key with utmost safety. Without an HSM the key can potentially fall into the wrong hands and could result in huge mistrust. All keys used in our one-time signatures are created, used, and destroyed within the HSM. The HSM should be configured with FIPS 140-2 Level 3. This device will follow PKCS11 or JCE standards.
The eSignature creation device (SCD) is the component where the user's private key would be stored. The SCD could be a Smart card, Mobile App, Sim card App, or equivalent. The SCD interacts with the eSignature Building Block using its own internal protocol. Every eSignature Building Block will support one or many such SCDs. Most of the SCD would be protected with a secure PIN/Biometrics.
The SCD should be qualified with at least one of the following FIPS 140-2/3 Level 3 or Annex II of or equivalent common criteria certification.
The time of a sign is an important part of the signature. Without a proper time of the signature, we can never trust the signature, as one can not find if the signature happened before its expiry or after expiry. Most often this functionality is provided by the timestamping server hosted by the CA. This service follows
This is one of the most important functionality of eSignature. This service is responsible for providing the One Time Signature API and interacts with the Hardware Security Module (HSM). This service validates the user against the Authorization Building Block. A valid user is allowed to create a key in HSM and sign it. Every key created here will also need an X509 certificate. The certificate management module will publish this created X509 certificate.
Keys created during One Time Signature should be deleted after the signature process. Logs SHOULD be kept in a database of the details of the deletion. Logs MUST include timestamps and identify the user and affiliation that performed the transaction.
eSignature creation device (SCD) On-Boarding is the module responsible for binding the SCD and user. The module interacts with the Identity Building Block and will validate the user's presence before issuing the Certificate. This module is responsible for talking to the SCD for all types of key management and administrative needs. This module is hosted on a server and would ensure the keeping of clear audit records and Know Your Customer/Client (KYC) records.
The SCD Signing is one of the vital functions of the eSignature Building Block. When a user holds its key in an SCD then this module is responsible for interacting with the SCD to sign any required document. This module works in asynchronous mode. A signature is requested on demand using the API. However, the module interacts with the SCD asynchronously. The module is responsible for connecting to SCD for all signing purposes.
All certificates that are created within the SCD will be hosted in this module. The module lets everyone have their X509 public certificate hosted for any verification. The module should have an administrative ability to allow people to revoke the keys on demand. The module has to maintain the OCSP & CRL-based revocations. Key revocation is not available in Onetime Signatures as the certificate is short-lived.
This module is responsible for notifying the SCD device when a signature is needed. This helps the SCD to alert the user. The user can look through the notification and accept to sign the document. The module is also responsible for notification of a signature to the user's mobile phone/email/SCD. The notification to the user can be used as an audit record by the user. This interface abstracts the messaging with an omnichannel interface. The notification Building Block can be used to send notifications to the end user/device.
Once the signature is completed the signature backend keeps the signature until the eService server makes a request. Once the eService has received the Signature Token (SignatureId), It can request the eSignature BB to send the final signature. Once the Signature Token is validated the BB sends the signature. This happens over a backend-protected channel.
This is the callback service available in eService. Once the signature is complete the user will be redirected to the eService. This module is responsible for understanding the redirect request and the HTTP parameters that are passed during this redirection.
This module is responsible for validating a digital signature. This is provided as a library. A format-specific validation library should be provided. The majority of the format adopted in this specification provides a clear explanation of how to validate the signature. But in a few specified formats like ASC, it may be necessary for the signature service to explicitly state the validation mechanism. It is also expected that the service provider will provide a library, application (optional), and online service(optional) to validate the signature.
This section provides a detailed view of how this Building Block will interact with other Building Blocks to support common use cases.
This internal workflow is used by the eSignature Building Block to provide one-time signature. In order to make the sequence diagram easier to follow the eSignature Building Block is divided into front-end and back-end parts. Frontend constitutes the functionality running in the user's internet browser and backend refers to the API running on a server.
Workflow is kicked off by a third party using the eSignature client library to get a digest of document to be signed. Using the digest (hash) the redirection request is made towards the eSignature Building Block front-end. If required by the Building Block configuration, it will also check if the Payment token supplied by the request is valid. In the eSignature Building Block front-end, the user selects the option to use National ID to do a one-time signature. Then the user is redirected to the Identity Building Block to authenticate and user data is returned back to the eSignature Building Block back-end after completion of all standard interaction API calls. Then a Host Security Module (HSM) hardware is used to generate a temporary keypair. From that keypair, the public part is exported as a Certificate Signing Request (CSR). CSR is submitted to a Certificate Authority (CA) instance that will generate and publish a short-lived (1-minute) certificate based on the supplied CA.
After the certificate has been created the private key in the Hardware Security Module (HSM) is used to sign a document digest. After the document digest is signed, a timestamp is requested on the signature from the timestamping service. After the timestamp is generated and received on a signature, the results are saved into a database, and a signature ID is generated to reference the signature data. The signature ID is then returned to the eSignature front-end, and the user's flow is redirected back to the e-Service provider using the callback URL and signature ID. After receiving the signature ID the e-Service provider can then receive the signature from the eSignature Building Block back-end. As an option, the eSignature Building Block back-end can verify the requests coming from the correct IP. After finally receiving the signature, eService can merge it with the original document to get a signed version of it using the client-side library received from the eSignature Building Block front-end.
In case of signing in with the user's device, there are multiple workflows:
Register the user's Signature Creation Device (SCD).
Signing with the user's Signature Creation Device (SCD).
Registering starts with the user authenticating against the ID Building Block and getting the authentication token. After the user is authenticated, a Remote SCD service is called to onboard the user. There is a request sent to the user's device to create keys. After keys are generated the public part of the keypair is sent to the eSignature Building Block as a Certificate Signing Request (CSR). CSR is submitted to a certificate authority (CA) instance that will generate and publish a certificate based on the supplied CA.
This internal workflow is for signing with the user's Signature Creation Device (SCD). In order to make the sequence diagram easier to follow the eSignature Building Block is divided into front-end and back-end parts. Front-end constitutes the functionality running in the user's internet browser and back-end refers to the API running on a server.
First, eService fetches the client-side library from the eSignature Building Block front-end. The client library is used to create a digest of the document to be signed. Using the digest (hash) the redirection request is made towards the eSignature Building Block front-end. In the eSignature Building Block front-end, the user selects the option to use the SCD model. The pseudonym entry page is shown and the user enters the pseudonym, which is sent to the e-Signature Building Block back-end to receive the generated pseudonym token. After receiving a pseudonym token, eSignature Building Block back-end can be invoked to create the signature. eSignature Building Block back-end will then invoke Remote SCD Service to create the signature. Remote SCD service will send a notification to the user's SCD with a notification and request to put PIN code. After the user enters the PIN code, a signature is generated and sent back to the Remote SCD Service. Remote SCD Service will then send the signature back to the eSignature Building Block back-end.
After the Signature is received, eSignature Building Block back-end will send a request to the Timestamping Authority for a timestamp on the signature to be created. After the timestamp is generated and received on a signature, the results are saved into a database, and a signature ID is generated to reference the signature data. Signature ID is then returned to the eSignature front-end, and the user's flow is redirected back to the eService provider using the callback URL and signature ID. After receiving the signature ID the eService provider can then receive the signature from the eSignature Building Block back-end. As an option, the eSignature Building Block back-end can verify the requests coming from the correct IP. After finally receiving the signature, eService can merge it with the original document to get a signed version of it using the client-side library received from the eSignature Building Block front-end.
Terminology used within this specification.
Name | Type | Description |
---|---|---|
Name | Type | Description |
---|---|---|
This interface handles the necessary health, metrics, traceability and legal needs for the given Building Block. While there are no certain standards to this, it is recommended to follow the design to address some of the challenges. Issuance of signature certificates is usually backed by several legal regulations. The requirements can range from KYC details available upon Judicial intervention, Revocation and Transparency of the revoked certificate as per OCSP/CRL (Similar to /) and Dispute Resolution.
SignatureId
String
Unique Signature Token for signature operations. This can be a random String as well.
SignatureType
Enum
Can be ONETIME or SCD
SignatureFormat
Enum
Signature format that should be applied. Can be XAdES, CAdES, ASIC, JWS, PAdES
Hash
String
Hash to be signed in hex characters or base64
HashType
Enum
Hash type - SHA2-256, SHA2-384, SHA2-512, SHA3-256, SHA3-384, SHA3-512, BLAKE2B
DisplayData
String
Text string to be shown on user’s device (SCD). Limited to 256 characters.
Certificate
String
X509 Certificate in PEM format
RequestTimestamp
Timestamp
Timestamp of the request
Signature
Signature
Signature in base64 format
SignatureTimestamp
String
rfc3161 asn.1 in base64
ResponseTimestmap
Timestamp
Timestamp of the response
Status
Enum
Request status enum. Can be OK, ERROR
StatusDesc
String
Description of status
CallbackURL
URL
URL to call back with results
Pseudonym
String
Unique pseudonym for the user that is bound to the specific SCD/Key id combo. We can call this as Key Handle
AuthToken
String
JWT Token from ID Building Block
PaymentToken
String
Jwt Token from Payments Building Block
AuthToken
String
JWT Token from ID Building Block
PaymentToken
String
JWT Token from Payments Building Block
CSR
String
Certificate signing request PKCS#10 in PEM format
SCDType
Enum
The SCD type that is used by user. Can be of REMOTE_SCD_APP_APPLE, REMOTE_SCD_APP_ANDROID, REMOTE_SCD_APP_SE_APPLE, REMOTE_SCD_APP_SE_ANDROID, REMOTE_SCD_SIM, REMOTE_SCD_ESIM,
REMOTE_SCD_SMARTID
SCDKeyId
Number
Key id for case the SCD has multiple certificates
SCDRemoteId
String
Remote identifier for the SCD communication, for REMOTE_SCD_APP* devices it is push ID, for REMOTE_SCD_ESIM/ REMOTE_SCD_SIM it is msisdn
For
REMOTE_SCD_SMARTID it is citizen id
Pseudonym
String
Unique pseudonym for the user that is bound to the specific SCD/Key id combo. We can call this as Key Handle
CertReqTimestamp
Timestamp
Timestamp for the certificate request
CertId
String
Unique identifier for the certificate, SCD, Key id combo
Certificate
String
X509 Certificate in PEM format in ACTIVE status
CertRespTimestamp
Timestamp
Timestamp for the Certificate response
Status
Enum
Request status. Can be of of OK, ERROR
StatusDesc
String
Description of status
0.8
Sasikumar Ganesan, Jurgen Niinre, Dr. P. S. Ramkumar, Kassy Kadio
Initial draft specifications
0.9
eSignature team, Architecture team, Technical Committee
Technical review and updates
1.0
eSignature team + Product Committee
Presentation updates
This section links to any external documents that may be relevant, such as standards documents or other descriptions of this Building Block that may be useful.
Some common workflows that leverage the eSignature Building Block can be found here:
https://govstack-global.atlassian.net/wiki/spaces/GH/pages/261947413/eSignature+Use+Case
https://govstack-global.atlassian.net/wiki/spaces/GH/pages/261947413/eSignature+Use+Case
A historical log of key decisions regarding this Building Block.
A list of topics that may be relevant to future versions of this Building Block.
A list of functions out of the scope of this Building Block.
Developed by Sasikumar Ganesan, Jurgen Niinre, Dr. P. S. Ramkumar, Kassy Kadio, in cooperation with GIZ, ITU, and DIAL
This section provides context for this Building Block.
eSignature Building Block provides the necessary functionalities to bring handwritten signatures to the digital world. Handwritten signatures have served as a way to agree/witness a given document, yet, in today's digital world most documents are in digital form. The digital form varies between structured (XML, JSON) and unstructured documents (PDF, Word, Image, CSV, Spreadsheet). eSignatures can be added to digital documents similar to handwritten signatures achieving the same functionality.
Additionally, eSignatures improve user experience in managing the signing process as the same can be embedded directly in e-Services, leaving out the need to print out forms, sign on paper, scan, and upload/send.
eSignature provides a considerable advantage over handwritten signatures because of the availability for verification at any point in time. This allows for remote validation of signatures, content (content being the same as that during signing), identity, and time. This assurance allows us to trust a signed document remotely and can be used for legally binding agreements. Sample use cases include:
Submitting applications to Government agencies (e.g. Child Care, Residence Registration, Marriage, etc.)
Purchase and use banking services (i.e. making transfers, adding transfer limits, applying for loans)
Purchasing telecom services (i.e. purchase SIM/eSIM, change contract, add a TV subscription)
Purchase utility services (i.e. new contract for electricity, gas)
Purchase insurance contract
With eSignature there is no need to print documents on paper anymore, saving a lot of paper and promoting a green lifestyle. This can also save money and can be calculated with an online calculator designed for the eSignature practice.
Ability to support eSignature for everyone.
Ability to support eSignature through a specialized user device/card.
The ability for third-party services (including other Building Blocks) to interact, sign, and verify the eSignatures in a standardized model.
Users: people or applications (delegated by a user) who use the eSignature Building Block to give eSignatures.
Services: third-party services that require a user eSignature to provide the service.
Auditor: individual or organization that reviews the platform for any misuse (intentional or unintentional)
Administrator: individual or team that configures the eSignature Building Block and is responsible for ensuring the functioning of the Building Block.
Certification Authority: a certification authority that can issue a certificate as X509.
Timestamp Authority: a trusted third party who can provide certified time.
There are two lifecycles available for the eSignature Building Block. Both mechanisms have their own unique advantages, therefore it is recommended to follow both for an inclusive approach.
One-time signatures are one of the easiest ways to get large-scale adoption of eSignatures. This approach does not require any device to be owned by the end user. This approach relies on the work done by the ID Building Block to authenticate an end user.
User authenticates against the ID Building Block
The user is redirected to the eSignatures Building Block
A new key pair is created in the HSM (Hardware Security Module)
An X509 Certificate is issued with the details from the ID Building Block (Name, Age, Gender, Location)
The new key is used to timestamp and sign the document
The X509 certificate is set to expire 1 minute from the time of creation
The signed document is sent
The private key is deleted from the HSM
The SCD (Signature Creation Device) is a personal device of the user. It could be a Mobile Phone, SIM card, Smart Card, Secure SD Card, USB Storage device, NFC Card, etc. The SCD device can be used to store the keys for long-term usage. This allows the user to interact with the ID Building Block once and create a key on the SCD. This key then can be used for signing any document without interacting with the ID Building block.
The binding of the private key with the user is called On-boarding. In this process, a user is authenticated and his key is created on the SCD.
User authenticates against the ID Building Block
The user is redirected to the eSignature page where his SCD device is detected
The user is asked to select a valid SCD device and enter its security PIN/Biometric/One Time Password
The eSignature Building Block interacts with the SCD (protocols are left open for implementation) to create a Key Pair
A CSR (Certificate Signing Request) is created
This request is sent to the eSignature Building Block
The Building Block verified the ID Building Block token and the data in the CSR
If they match then the CSR is converted to an X509 certificate and the same is issued back to the device
The key created on the SCD device can be used by the user to digitally sign any of the documents.
The third-party who needs to sign the document will be redirected to the eSignature Building Block
The eSignature Building Block will ask for the pseudonym (eSignature handle) from the user
The user provides the pseudonym to the eSignature Building Block
The eSignature Building Block sends a notification to the SCD (Internal Protocol)
The user is shown his choice to sign or not to sign
Once the user signs the SCD will send the signature to the third-party
The Digital Signature will then be attached to the given document in one of the supported formats as described by the eSignature Building Block
View and provide consent to the document that is about to be signed
Register the user's Signature Creation Device (SCD)
Confirm the signature with a PIN code on the user's SCD
View user's SCD-s and certificates
Digitally sign the documents (PDF, Word, Excel, JSON, XML, Image)
Use a personal device to store the keys safely
Ability to sign the document where the user has no device
Ability to sign a document without the involvement of ID Building Block
Ability to sign a document using only the ID issued by the ID Building Block
User
Ability to view the list of signings performed
Invoke eSignatures to obtain a digital signature
Sign the digital document in the desired eSignature format
Allow a safe async way to obtain signatures
A simple-to-use library to validate the eSignature
Retrieve and review specific audit data
Validate and get signatures on any audit data
Audit cryptographic functioning and compliance for auditing and key security
Configure the system without intervening with the signature process
Administer without modification or tampering with the data or key security
eSignature Building Block will provide a helper library for the Services. The helper library could be used to integrate eSignatures faster.
Get digital document digest to be sent to eSignature Building Block. Obtaining just the hash reduces the storage overhead and also avoids the privacy concern of sending the original document.
Embedding received eSignature back into the document or attaching it in case of detached signatures.
Validate digitally signed documents and the validity of the certificate.
Supports the following signature formats:
In order for eSignatures to be secure and adhere to privacy regulations the eSignature Building Block uses the following levels of authentication,
Authentication via ID Building Block: the service that uses eSignature will have to authenticate the user against the ID Building Block.
Unique pseudonym: the service is redirected to a webpage on the eSignature portal where the user can enter a unique pseudonym known only to the user to start the signing process (without a pin, the signing will not be complete).
Asking for a PIN code on the user's device: eSignature Building Block will send a request to the user's device so that the user can confirm the signing request with a PIN.
The signature will be returned using an internal API protected by the Information Mediation Building Block.
eSignature Building Block must log all signing transactions to be compliant with current regulations. The minimum details to be logged are:
User's identity without revealing personally identifiable information.
Document digest.
Timestamp of the signing.
This section provides a reference for APIs that should be implemented by this Building Block.
A Set of microservices is defined to receive requests from other GovStack-compatible Building Blocks and third-party Services with relevant inputs and return processed results from key digital functionalities of this Building Block. This section provides a reference for APIs that should be implemented by this Building Block. The APIs defined here establish a blueprint for how the Building Block will interact with other Building Blocks or third-party services. Additional APIs may be implemented by the Building Block, but the listed APIs define a minimal set of functionality that should be provided by any implementation of this Building Block.
eSignature Building Block must expose its microservices through RESTful API interfaces as defined by OpenAPI v3+ standards. A summary of the APIS exposed by this Building Block is summarized in the table below.
The update API can be used to revoke the certificate. All revoked certificates will be available over OCSP.
Term | Description |
eSignature, e-Signature, electronic signature, digital signature | A data unit which is used by a Signatory to indicate his or her link to a Document |
Certificate | Data that links a public key to a natural person and confirms the name of that person |
Signatory/User | A natural person or an application delegated by the user who can create a digital signature |
eSignature creation device (SCD) | Configured software and/or hardware used to create an eSignature. Two types of eSignature creation devices are supported: * Local - Private keys are stored locally on mobile devices. * Remote - Private keys are stored on the remote secure storage. |
Signing application, Signature requestor, Third-Party | An application that has the Document that needs the Signatory's signature |
Document (to be signed) | Data that needs to be signed by the Signatory. It can be any data file in an arbitrary format. Document to be signed is usually handled by a third party and made available to Signatory after signing. |
Onboarding | The process of identifying Signatory, issuing a Certificate, and binding it to an eSignature Creation Device. User identification is performed using Govstack's Identity Building Block. |
HSM | Hardware Security Module - a device or software that can store private keys safely. |
SCD | Signature Creation Device - Can be local or remote based on where the keys are stored. |
X509 | A certificate format as defined in |
Timestamp | Compliant to |
Sign | The process of using SCD or One Time signature APIs to encrypt the hash of the document. |
CSR | Certificate Signing Request as per |
One time Signature | A private key is created upon authentication of the user and expires right after the signature. Should not be confused with OTS or related signature models. |
Revocation | All revocation of certificates will be available over . Follows the respective standards RFC 8954. |
This section lists the technical capabilities of this Building Block.
The eSignature Building Block has several functional layers within it. Some functional layers follow the existing set of protocols and custom protocols, While the other functional requirements are defined within this specification. In this section, we will provide a clear indication to state what blocks follow what kind of protocols.
In the case of the One-Time Signature, a Hardware Security Module (HSM) must be used to create cryptographic keys. (REQUIRED)
It must be used to sign a certificate. (REQUIRED)
Keys shall not be exported. (REQUIRED)
MUST be protected well with best security practices. (REQUIRED)
Signature Creation Device (SCD) should have secure storage to protect private keys. (REQUIRED)
SCD may have proprietary APIs with the eSignature Building Block. (REQUIRED)
SCD is assumed to be with the user. (REQUIRED)
A user's PIN is a must for the SCD. (REQUIRED)
Keys shall not be exportable. (REQUIRED)
For a valid signature, a timestamp server is a must. (REQUIRED)
The timestamp server shall follow . (REQUIRED)
eSignature Building Block may be a certifying authority. (REQUIRED)
If not, the Building Block shall have access to a certifying authority and be able to issue certificates or be a subordinate certification authority. (REQUIRED)
Service shall support the onboarding of the Signature Creation Device (SCD). (REQUIRED)
Service shall support both the key functionalities of signing using SCD and One-Time Signature. (REQUIRED)
The user shall be authenticated through the ID Building Block for the One-Time Signature. (REQUIRED)
The user shall be allowed to perform a signature through a pseudonym without user login. (REQUIRED)
Optionally can support payments through a payment gateway. (OPTIONAL)
Shall support all the listed signature types. (REQUIRED)
Shall support redirection and callback as per the specification. (REQUIRED)
All user activities should be available for audit. (REQUIRED)
May have the feature to tamper-proof the audit records. (REQUIRED)
Auditors shall have the ability to get audit-proof of a transaction. (REQUIRED)
Shall provide the ability to list and revoke a certificate. (REQUIRED)
The user shall have the ability to revoke their keys (API-based or through customer care). (REQUIRED)
Certificates shall have any of the following statuses (REQUIRED):
Active – The certificate is active and can be used for signing.
Expired – certificates are expired and should be renewed.
Suspended – certificate is suspended. The reason for suspension shall be provided together with status information.
Revoked – certificate is revoked. The reason for revoking shall be provided together with status information.
Users shall be able to view their certificates and corresponding statuses. (REQUIRED)
Shall provide the ability to notify the user over email, SMS, app notification, or any other equivalent. (REQUIRED)
The user shall be notified of failed and successful transactions. (REQUIRED)
The Messaging interface should send relevant information to the logging sub-block to maintain the history of all messages sent from this Building Block, which are useful for audit purposes. (RECOMMENDED)
The messaging interface should provide the necessary protocol, data format, and information and interface to interact with the Messaging Building Block for sending notifications to a specific target Signature Creation Device or user through a variety of channels (SMS/email/etc.) (RECOMMENDED)
Note: The keywords "must", "must not", "required", "shall", "shall not", "should", "should not", "recommended", "may", and "optional" in this document are to be interpreted as described in
eSignature BB will call this callback URL on external service once signing is completed
API version
"v1"
signatureId that can be used to retreive the response as hex string of hash
"7607fa7f45b2558201baf05215521a7df63078774f0b0d1ad15ccfcb0aad9484"
hex string value of hash to mitigate replay attacks
"d2dff00401c92ca6879ef5f0938ce31580898266d59832d8531e8d04fc3898a6"
hex string value of hash used to maintain state between the request and the callback
"2569cb4125cb7303f0f16782e7e2814b2269888c734af4c90639653e4f92d3a5"
Returns html for continuing user's flow
Provide interactive html for pseodonym entry form that will get the signature via sign/pseudonym and will call callbackUrl
API version
"v1"
Pre format the signature in a give format so that it can be more inserted by the formatting library XAdES|CAdES|ASIC|JWS|PAdES
"PAdES"
hash as byte array encoded in base64
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
hash type used SHA2-256|SHA2-384|SHA2-512|SHA3-256|SHA3-384|SHA3-512|BLAKE2B
"SHA2-256"
Data to be displayed on users SCD (for ex transactionId)
"UGxlYXNlIHNpZ24gdGhlIGNvbnNlbnQgZm9ybSBhcyByZXF1ZXN0ZWQgKHRyYW5zYWN0aW9uSWQ6MTIzNCk"
Timestamp in ISO 8601
"2023-03-20T09%3A12%3A28Z"
hex string value of hash to mitigate replay attacks
"d2dff00401c92ca6879ef5f0938ce31580898266d59832d8531e8d04fc3898a6"
hex string value of hash used to maintain state between the request and the callback
"2569cb4125cb7303f0f16782e7e2814b2269888c734af4c90639653e4f92d3a5"
Callback url to be sent on signing response. Callback URL will have query parameters from SignatureResponse statusCode(base64urlencoded), statusMessage(base64urlencoded), signature (base64urlencoded), certificate (base64urlencoded), signatureTimestamp (base64urlencoded), responseTimestamp (urlencoded), pseudonymToken (jwt)
"https%3A%2F%2Fmysite"
Returns html for entering pseudonym
In order not to get the pseodonym token internally
API version
"v1"
Unique pseudonym
"johndoe5766"
Pseodonym token generated successfully
jwt pseudonym authorization
"eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiIsImtpZCI6IjcyNzcyYzI5OGNkZDNmYmQ3YmQxNmI5NTAxZDY0ODdiIn0.eyJwdWIiOiJKb2huIERvZSJ9.zNNhLDuydPHC7-YQYDhaGTaqS-efAL79pJXdWWm5Y7Fd94fVRCLvRTaA16ffQyhYPXHKcx8Q9baTB_fX0PtBuA"
Get list of all user certificates
API version
"v1"
Add filter condition ALL|ACTIVATED|EXPIRED|REVOKED|SUSPENDED
"ALL"
JWT Authentication token received from ID BB
"eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiIsImtpZCI6IjcyNzcyYzI5OGNkZDNmYmQ3YmQxNmI5NTAxZDY0ODdiIn0.eyJwdWIiOiJKb2huIERvZSJ9.zNNhLDuydPHC7-YQYDhaGTaqS-efAL79pJXdWWm5Y7Fd94fVRCLvRTaA16ffQyhYPXHKcx8Q9baTB_fX0PtBuA"
List certificates response
Id that is later used to send signature requests to a person
"09440694c5c1798a23aad320abcd04b83f02f5ea12b8865df073d0e77ad5ae27"
X.509 certificate in PEM format
"-----BEGIN CERTIFICATE-----\r\nMIIDfDCCAmSgAwIBAgIQaSg0J93/hMMyFZ/DNEDM3DANBgkqhkiG9w0BAQsFADAp\r\nMScwJQYDVQQDDB5CLkVzdCBTb2x1dGlvbnMgU2lnbmluZyBQb3J0YWwwHhcNMjMw\r\nNDE0MTAzOTA5WhcNMjUwNzE3MTAzOTA5WjATMREwDwYDVQQDDAhKb2huIERvZTCC\r\nASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANU2fYwu2tz/D4GpTZZhPn4g\r\nFTH4TSbez1Ux9eMsmklYrmqdr3bBzJ4k8I1wkOBioxrXnH/s4zq7I1dJCbAsAzpd\r\niK8IBHo5XxwX2Num+HxRdU+nTOtfa4MZTGnvf4ZzLYBEK1lIsXQxAbMkPu4cBH8t\r\n9ir72GGU2qM/iMOv25eA75+cmNFj+02DohgpxXhErnZB/9mY+8oLvIFM5traf92U\r\nF4OPsepQYpJUM4u2prxbdcwVCmZ70FielcykaG7u84PRKbmAA50x2UQgsksThmxA\r\nPJlIvEoCS4BAAoLlY+ti0IFhThqYjG+FcRR5R48wa+oAJBquDG1eko6dTzp3BdEC\r\nAwEAAaOBtTCBsjAJBgNVHRMEAjAAMB0GA1UdDgQWBBR68RAciltftWZW4pAxqMQ0\r\nhigSEzBkBgNVHSMEXTBbgBRYpaezWi0heg09El0UypLU81uA4KEtpCswKTEnMCUG\r\nA1UEAwweQi5Fc3QgU29sdXRpb25zIFNpZ25pbmcgUG9ydGFsghQZ+B3m7iBv8Daf\r\nWiIkRB5NbVbQsTATBgNVHSUEDDAKBggrBgEFBQcDAjALBgNVHQ8EBAMCB4AwDQYJ\r\nKoZIhvcNAQELBQADggEBAI+5OAffnf3sn/jN58idSLUC09vWc6KPEzfZ2QLhDftq\r\nAfwSquItYFFuuQNh/x93HSprglDwL3U6sqRq0owMSSXXcLctVQr/MTEXyiRmQjUT\r\nHykwS/ovSw93E6VRnrF0qnaf6qOOAi0FfLxCV/1p3aEQBt7f/krZaW4Y33XrKi5F\r\nNnMhqQLtgZy9xXR0dNQ0ZKorEIptUrcujT8aRlEN4oqE7oo4j41TsksBQgEFfIeg\r\nljS6baoEko6n5ozyFzfeDWzd0yTzviXmUZGzOt1ZLFbd5In5+LX4Z0QwzhUA+uyt\r\nCu17qrRiPt2JzALHjbkdV3OB5sbOSZDHl3aUuqll6Dg=\r\n-----END CERTIFICATE-----"
Certificate status ACTIVE|ERROR|EXPIRED|SUSPENDED|REVOKED
"ACTIVE"
Certificate active
"Certificate active"
In order not to get the pseodonym token internally
API version
"v1"
get signature response for signatureId
"7607fa7f45b2558201baf05215521a7df63078774f0b0d1ad15ccfcb0aad9484"
Signature response
signature in base64 format
"53F4yGNsOXymuGL9JjF3Qi377pQVLqkDZuc1shPJB3xFJHJnhW8yepjhU8ILTz/wYoahXnzKj8xyT7PtbtwEA=="
X.509 certificate in PEM format
"-----BEGIN CERTIFICATE-----\r\nMIIDfDCCAmSgAwIBAgIQaSg0J93/hMMyFZ/DNEDM3DANBgkqhkiG9w0BAQsFADAp\r\nMScwJQYDVQQDDB5CLkVzdCBTb2x1dGlvbnMgU2lnbmluZyBQb3J0YWwwHhcNMjMw\r\nNDE0MTAzOTA5WhcNMjUwNzE3MTAzOTA5WjATMREwDwYDVQQDDAhKb2huIERvZTCC\r\nASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANU2fYwu2tz/D4GpTZZhPn4g\r\nFTH4TSbez1Ux9eMsmklYrmqdr3bBzJ4k8I1wkOBioxrXnH/s4zq7I1dJCbAsAzpd\r\niK8IBHo5XxwX2Num+HxRdU+nTOtfa4MZTGnvf4ZzLYBEK1lIsXQxAbMkPu4cBH8t\r\n9ir72GGU2qM/iMOv25eA75+cmNFj+02DohgpxXhErnZB/9mY+8oLvIFM5traf92U\r\nF4OPsepQYpJUM4u2prxbdcwVCmZ70FielcykaG7u84PRKbmAA50x2UQgsksThmxA\r\nPJlIvEoCS4BAAoLlY+ti0IFhThqYjG+FcRR5R48wa+oAJBquDG1eko6dTzp3BdEC\r\nAwEAAaOBtTCBsjAJBgNVHRMEAjAAMB0GA1UdDgQWBBR68RAciltftWZW4pAxqMQ0\r\nhigSEzBkBgNVHSMEXTBbgBRYpaezWi0heg09El0UypLU81uA4KEtpCswKTEnMCUG\r\nA1UEAwweQi5Fc3QgU29sdXRpb25zIFNpZ25pbmcgUG9ydGFsghQZ+B3m7iBv8Daf\r\nWiIkRB5NbVbQsTATBgNVHSUEDDAKBggrBgEFBQcDAjALBgNVHQ8EBAMCB4AwDQYJ\r\nKoZIhvcNAQELBQADggEBAI+5OAffnf3sn/jN58idSLUC09vWc6KPEzfZ2QLhDftq\r\nAfwSquItYFFuuQNh/x93HSprglDwL3U6sqRq0owMSSXXcLctVQr/MTEXyiRmQjUT\r\nHykwS/ovSw93E6VRnrF0qnaf6qOOAi0FfLxCV/1p3aEQBt7f/krZaW4Y33XrKi5F\r\nNnMhqQLtgZy9xXR0dNQ0ZKorEIptUrcujT8aRlEN4oqE7oo4j41TsksBQgEFfIeg\r\nljS6baoEko6n5ozyFzfeDWzd0yTzviXmUZGzOt1ZLFbd5In5+LX4Z0QwzhUA+uyt\r\nCu17qrRiPt2JzALHjbkdV3OB5sbOSZDHl3aUuqll6Dg=\r\n-----END CERTIFICATE-----"
Timestamp in ISO 8601
"2023-03-20T09:12:38Z"
rfc3161 asn.1 in base64
"r/PzWEEgXyubXH/GCG6fLADU9Rz4e3b0KdZuNwfX/xk="
Signature creation response OK|ERROR
"OK"
Signature creation message
"Signature generated successfully"
Update certificate status
API version
"v1"
certificateId that indicates the certificate to be updated
"09440694c5c1798a23aad320abcd04b83f02f5ea12b8865df073d0e77ad5ae27"
JWT Authentication token received from ID BB
"eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiIsImtpZCI6IjcyNzcyYzI5OGNkZDNmYmQ3YmQxNmI5NTAxZDY0ODdiIn0.eyJwdWIiOiJKb2huIERvZSJ9.zNNhLDuydPHC7-YQYDhaGTaqS-efAL79pJXdWWm5Y7Fd94fVRCLvRTaA16ffQyhYPXHKcx8Q9baTB_fX0PtBuA"
Timestamp in ISO 8601
Certificate status to be updated ACTIVATE|SUSPEND|REVOKE, Allowed transitions ACTIVE->SUSPENDED, ACTIVE->REVOKED, SUSPENDED->ACTIVE, SUSPENDED->REVOKED
"SUSPEND"
Certificate update message
"Certificate to be updated as suspended"
Update certificate response
Timestamp in ISO 8601
Certificate status ERROR|ACTIVATED|SUSPENDED|REVOKED|EXPIRED
"SUSPENDED"
Certificate supended because of user action on 02.02.2023
"Certificate suspended"
Way for users and auditors to review the signature requests made
API version
"v1"
Timestamp in ISO 8601
"2023-03-20T09%3A12%3A28Z"
Timestamp in ISO 8601
"2023-03-20T09%3A12%3A28Z"
JWT Authentication token received from ID BB
"eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiIsImtpZCI6IjcyNzcyYzI5OGNkZDNmYmQ3YmQxNmI5NTAxZDY0ODdiIn0.eyJwdWIiOiJKb2huIERvZSJ9.zNNhLDuydPHC7-YQYDhaGTaqS-efAL79pJXdWWm5Y7Fd94fVRCLvRTaA16ffQyhYPXHKcx8Q9baTB_fX0PtBuA"
Audit response
signature type ONETIME|SCD
signature in base64 format
"53F4yGNsOXymuGL9JjF3Qi377pQVLqkDZuc1shPJB3xFJHJnhW8yepjhU8ILTz/wYoahXnzKj8xyT7PtbtwEA=="
X.509 certificate in PEM format
"-----BEGIN CERTIFICATE-----\r\nMIIDfDCCAmSgAwIBAgIQaSg0J93/hMMyFZ/DNEDM3DANBgkqhkiG9w0BAQsFADAp\r\nMScwJQYDVQQDDB5CLkVzdCBTb2x1dGlvbnMgU2lnbmluZyBQb3J0YWwwHhcNMjMw\r\nNDE0MTAzOTA5WhcNMjUwNzE3MTAzOTA5WjATMREwDwYDVQQDDAhKb2huIERvZTCC\r\nASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANU2fYwu2tz/D4GpTZZhPn4g\r\nFTH4TSbez1Ux9eMsmklYrmqdr3bBzJ4k8I1wkOBioxrXnH/s4zq7I1dJCbAsAzpd\r\niK8IBHo5XxwX2Num+HxRdU+nTOtfa4MZTGnvf4ZzLYBEK1lIsXQxAbMkPu4cBH8t\r\n9ir72GGU2qM/iMOv25eA75+cmNFj+02DohgpxXhErnZB/9mY+8oLvIFM5traf92U\r\nF4OPsepQYpJUM4u2prxbdcwVCmZ70FielcykaG7u84PRKbmAA50x2UQgsksThmxA\r\nPJlIvEoCS4BAAoLlY+ti0IFhThqYjG+FcRR5R48wa+oAJBquDG1eko6dTzp3BdEC\r\nAwEAAaOBtTCBsjAJBgNVHRMEAjAAMB0GA1UdDgQWBBR68RAciltftWZW4pAxqMQ0\r\nhigSEzBkBgNVHSMEXTBbgBRYpaezWi0heg09El0UypLU81uA4KEtpCswKTEnMCUG\r\nA1UEAwweQi5Fc3QgU29sdXRpb25zIFNpZ25pbmcgUG9ydGFsghQZ+B3m7iBv8Daf\r\nWiIkRB5NbVbQsTATBgNVHSUEDDAKBggrBgEFBQcDAjALBgNVHQ8EBAMCB4AwDQYJ\r\nKoZIhvcNAQELBQADggEBAI+5OAffnf3sn/jN58idSLUC09vWc6KPEzfZ2QLhDftq\r\nAfwSquItYFFuuQNh/x93HSprglDwL3U6sqRq0owMSSXXcLctVQr/MTEXyiRmQjUT\r\nHykwS/ovSw93E6VRnrF0qnaf6qOOAi0FfLxCV/1p3aEQBt7f/krZaW4Y33XrKi5F\r\nNnMhqQLtgZy9xXR0dNQ0ZKorEIptUrcujT8aRlEN4oqE7oo4j41TsksBQgEFfIeg\r\nljS6baoEko6n5ozyFzfeDWzd0yTzviXmUZGzOt1ZLFbd5In5+LX4Z0QwzhUA+uyt\r\nCu17qrRiPt2JzALHjbkdV3OB5sbOSZDHl3aUuqll6Dg=\r\n-----END CERTIFICATE-----"
Timestamp in ISO 8601
"2023-03-20T09:12:38Z"
rfc3161 asn.1 in base64
"r/PzWEEgXyubXH/GCG6fLADU9Rz4e3b0KdZuNwfX/xk="
Signature creation response OK|ERROR
"OK"
Signature creation message
"Signature generated successfully"
Use user's SCD (Signature Creation Device) to create an eSignature
API version
"v1"
JWT pseudonym token
"eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiIsImtpZCI6IjcyNzcyYzI5OGNkZDNmYmQ3YmQxNmI5NTAxZDY0ODdiIn0.eyJwdWIiOiJKb2huIERvZSJ9.zNNhLDuydPHC7-YQYDhaGTaqS-efAL79pJXdWWm5Y7Fd94fVRCLvRTaA16ffQyhYPXHKcx8Q9baTB_fX0PtBuA"
Pre format the signature in a give format so that it can be inserted by the formatting library XAdES|CAdES|ASIC|JWS|PAdES
"PAdES"
hash as byte array encoded in base64
"53F4yGNsOXymuGL9JjF3/Qi377pQVLqkDZuc1shPJB3xFJHJnhW8yepjhU8ILTz/wYoahXnzKj8xyT7PtbtwEA=="
hash type used SHA2-256|SHA2-384|SHA2-512|SHA3-256|SHA3-384|SHA3-512|BLAKE2B
"SHA2-256"
Data to be displayed on users SCD (for ex transactionId)
"Please sign the consent form as requested (transactionId: 1234)"
hex string value of hash to mitigate replay attacks
"d2dff00401c92ca6879ef5f0938ce31580898266d59832d8531e8d04fc3898a6"
hex string value of hash used to maintain state between the request and the callback
"2569cb4125cb7303f0f16782e7e2814b2269888c734af4c90639653e4f92d3a5"
Timestamp in ISO 8601
"2023-03-20T09:12:28Z"
Signature response
signatureId that can be used to retreive the response as hex string of hash
"7607fa7f45b2558201baf05215521a7df63078774f0b0d1ad15ccfcb0aad9484"
hex string value of hash to mitigate replay attacks
"d2dff00401c92ca6879ef5f0938ce31580898266d59832d8531e8d04fc3898a6"
hex string value of hash used to maintain state between the request and the callback
"2569cb4125cb7303f0f16782e7e2814b2269888c734af4c90639653e4f92d3a5"
Use one time Certificate and keys created on the fly to make an eSignature
API version
"v1"
JWT Authentication token received from ID BB
"eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiIsImtpZCI6IjcyNzcyYzI5OGNkZDNmYmQ3YmQxNmI5NTAxZDY0ODdiIn0.eyJwdWIiOiJKb2huIERvZSJ9.zNNhLDuydPHC7-YQYDhaGTaqS-efAL79pJXdWWm5Y7Fd94fVRCLvRTaA16ffQyhYPXHKcx8Q9baTB_fX0PtBuA"
JWT Authentication token received from Payment BB
"eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiIsImtpZCI6IjcyNzcyYzI5OGNkZDNmYmQ3YmQxNmI5NTAxZDY0ODdiIn0.eyJwdWIiOiJKb2huIERvZSJ9.zNNhLDuydPHC7-YQYDhaGTaqS-efAL79pJXdWWm5Y7Fd94fVRCLvRTaA16ffQyhYPXHKcx8Q9baTB_fX0PtBuA"
Pre format the signature in a given format so that it can be inserted by the formatting library XAdES|CAdES|ASIC|JWS|PAdES
"PAdES"
hash as byte array encoded in base64
"53F4yGNsOXymuGL9JjF3/Qi377pQVLqkDZuc1shPJB3xFJHJnhW8yepjhU8ILTz/wYoahXnzKj8xyT7PtbtwEA=="
hash type used SHA2-256|SHA2-384|SHA2-512|SHA3-256|SHA3-384|SHA3-512|BLAKE2B
"SHA2-256"
Data to be displayed on users SCD (for ex transactionId)
"Please sign the consent form as requested (transactionId: 1234)"
Timestamp in ISO 8601
"2023-03-20T09:12:28Z"
Signature response
signature in base64 format
"53F4yGNsOXymuGL9JjF3Qi377pQVLqkDZuc1shPJB3xFJHJnhW8yepjhU8ILTz/wYoahXnzKj8xyT7PtbtwEA=="
X.509 certificate in PEM format
"-----BEGIN CERTIFICATE-----\r\nMIIDfDCCAmSgAwIBAgIQaSg0J93/hMMyFZ/DNEDM3DANBgkqhkiG9w0BAQsFADAp\r\nMScwJQYDVQQDDB5CLkVzdCBTb2x1dGlvbnMgU2lnbmluZyBQb3J0YWwwHhcNMjMw\r\nNDE0MTAzOTA5WhcNMjUwNzE3MTAzOTA5WjATMREwDwYDVQQDDAhKb2huIERvZTCC\r\nASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANU2fYwu2tz/D4GpTZZhPn4g\r\nFTH4TSbez1Ux9eMsmklYrmqdr3bBzJ4k8I1wkOBioxrXnH/s4zq7I1dJCbAsAzpd\r\niK8IBHo5XxwX2Num+HxRdU+nTOtfa4MZTGnvf4ZzLYBEK1lIsXQxAbMkPu4cBH8t\r\n9ir72GGU2qM/iMOv25eA75+cmNFj+02DohgpxXhErnZB/9mY+8oLvIFM5traf92U\r\nF4OPsepQYpJUM4u2prxbdcwVCmZ70FielcykaG7u84PRKbmAA50x2UQgsksThmxA\r\nPJlIvEoCS4BAAoLlY+ti0IFhThqYjG+FcRR5R48wa+oAJBquDG1eko6dTzp3BdEC\r\nAwEAAaOBtTCBsjAJBgNVHRMEAjAAMB0GA1UdDgQWBBR68RAciltftWZW4pAxqMQ0\r\nhigSEzBkBgNVHSMEXTBbgBRYpaezWi0heg09El0UypLU81uA4KEtpCswKTEnMCUG\r\nA1UEAwweQi5Fc3QgU29sdXRpb25zIFNpZ25pbmcgUG9ydGFsghQZ+B3m7iBv8Daf\r\nWiIkRB5NbVbQsTATBgNVHSUEDDAKBggrBgEFBQcDAjALBgNVHQ8EBAMCB4AwDQYJ\r\nKoZIhvcNAQELBQADggEBAI+5OAffnf3sn/jN58idSLUC09vWc6KPEzfZ2QLhDftq\r\nAfwSquItYFFuuQNh/x93HSprglDwL3U6sqRq0owMSSXXcLctVQr/MTEXyiRmQjUT\r\nHykwS/ovSw93E6VRnrF0qnaf6qOOAi0FfLxCV/1p3aEQBt7f/krZaW4Y33XrKi5F\r\nNnMhqQLtgZy9xXR0dNQ0ZKorEIptUrcujT8aRlEN4oqE7oo4j41TsksBQgEFfIeg\r\nljS6baoEko6n5ozyFzfeDWzd0yTzviXmUZGzOt1ZLFbd5In5+LX4Z0QwzhUA+uyt\r\nCu17qrRiPt2JzALHjbkdV3OB5sbOSZDHl3aUuqll6Dg=\r\n-----END CERTIFICATE-----"
Timestamp in ISO 8601
"2023-03-20T09:12:38Z"
rfc3161 asn.1 in base64
"r/PzWEEgXyubXH/GCG6fLADU9Rz4e3b0KdZuNwfX/xk="
Signature creation response OK|ERROR
"OK"
Signature creation message
"Signature generated successfully"
Create certificate on user's SCD (Signature Creation Device)
API version
"v1"
JWT Authentication token received from ID BB
"eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiIsImtpZCI6IjcyNzcyYzI5OGNkZDNmYmQ3YmQxNmI5NTAxZDY0ODdiIn0.eyJwdWIiOiJKb2huIERvZSJ9.zNNhLDuydPHC7-YQYDhaGTaqS-efAL79pJXdWWm5Y7Fd94fVRCLvRTaA16ffQyhYPXHKcx8Q9baTB_fX0PtBuA"
JWT Authentication token received from Payment BB
"eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiIsImtpZCI6IjcyNzcyYzI5OGNkZDNmYmQ3YmQxNmI5NTAxZDY0ODdiIn0.eyJwdWIiOiJKb2huIERvZSJ9.zNNhLDuydPHC7-YQYDhaGTaqS-efAL79pJXdWWm5Y7Fd94fVRCLvRTaA16ffQyhYPXHKcx8Q9baTB_fX0PtBuA"
Certificate Signing Request, in base64
Remote SCD type REMOTE_SCD_APP_APPLE|REMOTE_SCD_APP_ANDROID|REMOTE_SCD_APP_SE_APPLE|REMOTE_SCD_APP_SE_ANDROID|REMOTE_SCD_SIM|REMOTE_SCD_ESIM
Device token (Android/Apple) for REMOTE_SCD_APP* and REMOTE_SCD_APP_SE*, for other TBD
Key index to be used on SCD
Optional pseodonym chosen by user
Timestamp in ISO 8601
Certificate creation response
Id that is later used to send signature requests to a person
"09440694c5c1798a23aad320abcd04b83f02f5ea12b8865df073d0e77ad5ae27"
Unique pseudonym that can be used to lookup certificateId by external service. If not specified, will be created automatically.
"johndoe5766"
X.509 certificate in PEM format
"-----BEGIN CERTIFICATE-----\r\nMIIDfDCCAmSgAwIBAgIQaSg0J93/hMMyFZ/DNEDM3DANBgkqhkiG9w0BAQsFADAp\r\nMScwJQYDVQQDDB5CLkVzdCBTb2x1dGlvbnMgU2lnbmluZyBQb3J0YWwwHhcNMjMw\r\nNDE0MTAzOTA5WhcNMjUwNzE3MTAzOTA5WjATMREwDwYDVQQDDAhKb2huIERvZTCC\r\nASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANU2fYwu2tz/D4GpTZZhPn4g\r\nFTH4TSbez1Ux9eMsmklYrmqdr3bBzJ4k8I1wkOBioxrXnH/s4zq7I1dJCbAsAzpd\r\niK8IBHo5XxwX2Num+HxRdU+nTOtfa4MZTGnvf4ZzLYBEK1lIsXQxAbMkPu4cBH8t\r\n9ir72GGU2qM/iMOv25eA75+cmNFj+02DohgpxXhErnZB/9mY+8oLvIFM5traf92U\r\nF4OPsepQYpJUM4u2prxbdcwVCmZ70FielcykaG7u84PRKbmAA50x2UQgsksThmxA\r\nPJlIvEoCS4BAAoLlY+ti0IFhThqYjG+FcRR5R48wa+oAJBquDG1eko6dTzp3BdEC\r\nAwEAAaOBtTCBsjAJBgNVHRMEAjAAMB0GA1UdDgQWBBR68RAciltftWZW4pAxqMQ0\r\nhigSEzBkBgNVHSMEXTBbgBRYpaezWi0heg09El0UypLU81uA4KEtpCswKTEnMCUG\r\nA1UEAwweQi5Fc3QgU29sdXRpb25zIFNpZ25pbmcgUG9ydGFsghQZ+B3m7iBv8Daf\r\nWiIkRB5NbVbQsTATBgNVHSUEDDAKBggrBgEFBQcDAjALBgNVHQ8EBAMCB4AwDQYJ\r\nKoZIhvcNAQELBQADggEBAI+5OAffnf3sn/jN58idSLUC09vWc6KPEzfZ2QLhDftq\r\nAfwSquItYFFuuQNh/x93HSprglDwL3U6sqRq0owMSSXXcLctVQr/MTEXyiRmQjUT\r\nHykwS/ovSw93E6VRnrF0qnaf6qOOAi0FfLxCV/1p3aEQBt7f/krZaW4Y33XrKi5F\r\nNnMhqQLtgZy9xXR0dNQ0ZKorEIptUrcujT8aRlEN4oqE7oo4j41TsksBQgEFfIeg\r\nljS6baoEko6n5ozyFzfeDWzd0yTzviXmUZGzOt1ZLFbd5In5+LX4Z0QwzhUA+uyt\r\nCu17qrRiPt2JzALHjbkdV3OB5sbOSZDHl3aUuqll6Dg=\r\n-----END CERTIFICATE-----"
Timestamp in ISO 8601
Certificate creation response OK|ERROR
"OK"
Certificate creation message
"Certificate generated successfully"