# Create a Digital Signature on the Server

# Alias

`SignatureWithServerCreation`

# Description

Creates a digital signature (PKCS #1) of data using a signing identity on the server. As the input, either the hash of the data or a `DigestInfo` containing this hash can be sent, and that input is encoded in base64.

The signature is created with the signing identity on server specified in the request. This identity must belong to the 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

The body of the request contains the following JSON object.

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

Property | Usage | Description
`digest_value` | Optional | Hash of the data to be signed encoded in base64. This property can only be used if the value of the `signature_algorithm property` is something other than `"rsa-pkcs1"` (it is mandatory in that case) `.`
`data` | Optional | Base64 encoding of the `DigestInfo` structure containing the hash of the data whose digital signature (`rsa-pkcs1`) is to be generated. This property can only be used if the value of the `signature_algorithm` property is `"rsa-pkcs1"` (it is mandatory in that case) .
`signature_algorithm` | Required | Algorithm that must be used to generate the digital signature `("rsa-pkcs1"`, `"rsa-sha1"`, `"rsa-sha256"`, `"rsa-sha384"`, `"rsa-sha512"` and "`ecdsa`"`)`. The `"rsa-pkcs1"` value indicates that the hash to generate the signature is encapsulated in a `DigestInfo` structure, which is the value of the `data` property. Therefore, the signature algorithm that is effectively requested is the one that results from combining RSA with the PKCS #1 v1.5 padding and the hash algorithm indicated by the `DigestInfo` structure.
`sign_identity_id` | Required | Identifier of the signing identity that must be used for generating the signature (it must be a server signing identity that belongs to the user on behalf of whom the signature is performed).

## Authorization

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.

## Additional Requirements If the Signing Identity Is Enabled Via Password in the HSM or Via the SAM

If the signing identity to be used to create the digital signature is enabled via a password validated by the HSM or via the SAM, in the authorization request of the OAuth 2.0 flow:

- The `sign_identity_id` parameter must be included and its value must be the identifier of the signing identity.

- The `digests_summary` parameter and its value must be one of the following:

  - If the `data parameter` is used, the base64-encoded cryptographic hash of the data to be digitally signed.

  - If the `digest-value` parameter is used, the base64 encoded cryptographic hash of the cryptographic hash of the data to be digitally signed. This last hash must be the same as the one indicated later in the operation request.

- The `digests_summary_algorithm` parameter and its value must be the algorithm for obtaining the previous cryptographic hash.

## Example

`POST /trustedx-resources/esigp/v1/signatures/server/raw HTTP/1.1`
`Host: www.example.org`
`Content-Type: application/json`
`Authorization: Bearer mF_9.B5f-4.1JqM`
``
`{`
`"digest_value" : "RXN0byBlcyB1biBoYXNoIFNoYTE=",`
`"signature_algorithm" : "rsa-sha1",`
`"sign_identity_id" : "12345678"`
`}`

# Response

## Status-Line

If the signature is created successfully, the HTTP response will contain the following `Status-Line` (see HTTP Response Status for all the possible cases).

`HTTP/1.1 200 OK`

## Content-Type Header

`Content-Type: application/octet-string`

## Body

Contains the binary value of the signature.