monitoring

POST /echo

Test the availability of the web service. Timestamps are exchanged between the client and the server.

Request

Request body

signaturestring

The signature of the message.

The signature is optional and is only filled and/or checked if explicitly required. Otherwise, signature value is ignored in responses and left empty in requests. Signatures can be activated for each issuer, sub-issuer individually and at a method level.

To pass validation, the signature format must be RFC 7515 (JSON Web Signature) and RFC 7797 (Unencoded or detached payload) compliant. As such, a typical signature should look like this: [header]..[signature], where:

  • [header] is the Base64 URL encoded value of the JOSE header which contains the key ID, algorithm and object type. For example: eyJraWQiOiJzaWduIiwidHlwIjoiSk9TRStKU09OIiwiYWxnIjoiUlMyNTYifQ, which gives, in clear JSON: {"kid":"sign","typ":"JOSE+JSON","alg":"RS256"}. The kid (Key ID) and alg header fields are both required to perform the check. An additional jku parameter (JWKS URL where to retrieve the public key) can also be specified. Otherwise, it should be expected for public keys to have been exchanged beforehand. The typ is only there by convention and should only be set to JOSE or JOSE+JSON since were are not dealing JWT (tokens) here.
  • [signature] is the Base64 URL encoded value representation of the signature output. The payload used to generate the signature consists of the JSON serialization of the whole object, excluding old signatures and null values, which is then Base 64 URL encoded as well.

If the signature from the response contains a payload value, then it will be ignored in favor of the actual object.

Currently supported algorithms are:

  • RS256
  • RS384
  • RS512
  • ES256
  • ES256K
  • ES384
  • ES512

Example request

{
  "header": {
    "service": "ACS_H0A",
    "issuerCode": "66666",
    "subIssuerCode": "66666",
    "requestId": "d6156f8a-a504-48c4-8f5a-722606bd3d91",
    "keyTag": "01",
    "iv": "d6156f8aa50448c48f5a722606bd3d91"
  },
  "body": {
    "timestamp": "20250215174159"
  },
  "signature": "eyJraWQiOiJzaWduIiwidHlwIjoiSk9TRStKU09OIiwiYWxnIjoiUlMyNTYifQ..QslvRsAf7favTzmZACC6l1UbjySjezKwCIJ0T-qxWkla0GjACsp-5TzannnBoTYzpZfa9BasNVRe1UZyTKEF8ViQX_LL_XnMoDttzB15zCoKkLhgcTOqSmrUa2p_hPOTnmL40TAnlykqNA0MlOQ9nox3K7a-rlfAG4FVXypyaHN71rCBfMQiw5eY-57e3DEdcjDAIWMxKh2zaM4HZ43K2fc1DQHGB-k9aTljOZAEhe6D7dgTYV0EGAHzRw51x15xnPD7_z-sJGpun9iVZpf8fHu9dTn5lhMChQvEBqElxWpm6fET7Izm8hqMa1oUkf2l5ue9h-WotzIbzE4PQuLOxw"
}

Response

Echo response.

signaturestring

The signature of the message.

The signature is optional and is only filled and/or checked if explicitly required. Otherwise, signature value is ignored in responses and left empty in requests. Signatures can be activated for each issuer, sub-issuer individually and at a method level.

To pass validation, the signature format must be RFC 7515 (JSON Web Signature) and RFC 7797 (Unencoded or detached payload) compliant. As such, a typical signature should look like this: [header]..[signature], where:

  • [header] is the Base64 URL encoded value of the JOSE header which contains the key ID, algorithm and object type. For example: eyJraWQiOiJzaWduIiwidHlwIjoiSk9TRStKU09OIiwiYWxnIjoiUlMyNTYifQ, which gives, in clear JSON: {"kid":"sign","typ":"JOSE+JSON","alg":"RS256"}. The kid (Key ID) and alg header fields are both required to perform the check. An additional jku parameter (JWKS URL where to retrieve the public key) can also be specified. Otherwise, it should be expected for public keys to have been exchanged beforehand. The typ is only there by convention and should only be set to JOSE or JOSE+JSON since were are not dealing JWT (tokens) here.
  • [signature] is the Base64 URL encoded value representation of the signature output. The payload used to generate the signature consists of the JSON serialization of the whole object, excluding old signatures and null values, which is then Base 64 URL encoded as well.

If the signature from the response contains a payload value, then it will be ignored in favor of the actual object.

Currently supported algorithms are:

  • RS256
  • RS384
  • RS512
  • ES256
  • ES256K
  • ES384
  • ES512

Example response

{
  "header": {
    "service": "ACS_H0A",
    "issuerCode": "66666",
    "subIssuerCode": "66666",
    "requestId": "d6156f8a-a504-48c4-8f5a-722606bd3d91",
    "keyTag": "01",
    "iv": "d6156f8aa50448c48f5a722606bd3d91"
  },
  "body": {
    "timestamp": "20250215174159"
  },
  "signature": "eyJraWQiOiJzaWduIiwidHlwIjoiSk9TRStKU09OIiwiYWxnIjoiUlMyNTYifQ..QslvRsAf7favTzmZACC6l1UbjySjezKwCIJ0T-qxWkla0GjACsp-5TzannnBoTYzpZfa9BasNVRe1UZyTKEF8ViQX_LL_XnMoDttzB15zCoKkLhgcTOqSmrUa2p_hPOTnmL40TAnlykqNA0MlOQ9nox3K7a-rlfAG4FVXypyaHN71rCBfMQiw5eY-57e3DEdcjDAIWMxKh2zaM4HZ43K2fc1DQHGB-k9aTljOZAEhe6D7dgTYV0EGAHzRw51x15xnPD7_z-sJGpun9iVZpf8fHu9dTn5lhMChQvEBqElxWpm6fET7Izm8hqMa1oUkf2l5ue9h-WotzIbzE4PQuLOxw"
}

Changes

No recorded changes to this operation across all 1 revision of this API.