Electronic Signature Provider API

The Electronic signature API generates digital signatures (PKCS #1) with the signing identities managed by the platform.

Obtain Signing Identity Information

There is two types of signing identity, one for electronic signing and one for authentication

Request

GET /trustedx-resources/esigp/v1/sign_identities/{sign_identity_id}

Authorization

The request must contain a bearer access token generated by a trusted authorization server of the service from which the information on the signing identity is requested and that is associated to the domain to which the identity belongs. This token must be used as explained in RFC 6750. It must have the urn:safelayer:eidas:sign:identity:profile scope.

Basically, the token must be included in an HTTP Authorization header as follows:

Authorization: Bearer <token>

The access token can be obtained via an authorization code grant or Service provider's credentials grant OAuth 2.0 flow.

Example

GET /trustedx-resources/esigp/v1/sign_identities/12345678 HTTP/1.1
Authorization: Bearer mF_9.B5f-4.1JqM

Response

Response body representation in JSON as follows

{
 "id" : {string},
 "self" : {string},
 "description" : {string},
 "labels" : [ {string} ],
 "type" : {string},
 "device_id" : {string},
 "domain" : {string},
 "access" : [ {
     "user_id" : {string}
 } ]
 "details" : {
      "certificate" : {string},
      "activation_mode": {string},
      "public_key" : {string}
 },
 "links" :  {
      <operation_alias> : {
           "auth" : {
               "oauth2": {
                  "scopes": [ {string} ]
               }
           }
      }   
      },
 "status" : {
    "value" : {string},
    "reason" : {string}
 }
}

👍

For receiving signing certificate, labels array shall contain serverid tag.

For receiving authentication certificate, labels array shall contain mobileid tag.

Create a Digital Signature on the Server

Description

Creates a digital signature (PKCS #1) of data using a signing identity on server. As input, the hash of the data or a byte string to be signed raw can be received.

The signature is created with the signing identity on server specified in the request. This identity must belong to the end-user on behalf of whom the operation is performed.

Request

POST /trustedx-resources/esigp/v1/signatures/server/raw

Content-Type Header

Content-Type: application/json

Body

{
 "digest_value" : {string},
 "signature_algorithm" : {string},
 "sign_identity_id" : {string}
}

Example

POST /trustedx-resources/esigp/v1/signatures/server/raw
Host: eidas.eparaksts.lv
Content-Type: application/json
Authorization: Bearer cbc...6daf
Content-Length: 213
{
   "digest_value" : "n4bQgYhMfWWaL+qgxVrQFaO/TxsrC4Is0V1sFbDwCgg",
   "signature_algorithm" : "rsa-sha256",
   "sign_identity_id" : "nio...omq"
}

Response

Response contains the binary value of the PKCS #1 signature.

🚧

If you are using Sign API service, PKCS#1 shall be base64 encoded (hexToBase64)

Create a Digital Signature Batch on the Server

Description

Creates a batch of digital signatures from the hashes of the data to be signed using a server signing identity.

The signature is created with the signing identity on server specified in the request. This identity must belong to the end-user on behalf of whom the operation is performed.

🚧

This method can be used for single signing as well. Main differences: Batch method response with base64 encoded Signed data, but single signing method response with PKCS#1 raw signature.

Request

POST /trustedx-resources/esigp/v1/signatures/server/raw/batch

Content-Type Header

Content-Type: application/json

Body

{
    "sign_identity_id" : {string},
    "signature_algorithm" : {string},
    "requests" : [
        {
            "digest_value" : {string},
            "signature_algorithm" : {string}
        }
    ]
}

Access Control

The request must contain a bearer access token generated by a trusted authorization server associated to the domain of the signing identity to be used for generating the signature. This token must have a scope that includes the value configured for the signing identity (by default, urn:safelayer:eidas:sign:identity:use:server) and must be used as explained in RFC 6750. Basically, the token must be included in an Authorization header as follows:

Authorization: Bearer <token>

The access token must be obtained via an authorization code grant OAuth 2.0 flow.

Example

POST /trustedx-resources/esigp/v1/signatures/server/raw/batch
Host: eidas.eparaksts.lv
Content-Type: application/json
Authorization: Bearer cbc...6daf
Content-Length: 213
{
    "sign_identity_id": "12345678",
    "signature_algorithm": "rsa-sha1",
    "requests": [
        {
            "digest_value": "RXN0byBlcyB1biBoYXNoIFNoYTE=",
            "signature_algorithm": "rsa-sha1"
        },
        {
            "digest_value": "siHZ27CDp/M0KNfCo8MZiuklYU1wIQ4ocWzKp81N23k",
            "signature_algorithm": "rsa-sha256"
        }
    ]
}

Response

Body

{
    "signatures" : [ {string} ]
}