IDSCP2 Application Layer
The following document describes the serialization of IDS Messages, consisting of header and payload. In many cases, this IDSCP2 Application Layer protocol it is run on top of the IDSCP2 Transport Layer, but the application layer protocol is agnostic to the concrete implementation of the transport layer.
Context
IDS messages consist of header and payload.
The header typically contains the "actual IDS message" as a JSON-LD serialization of a Message class as defined in the IDS Infomodel.
The payload of an IDS message contains data structures or arbitrary other data, textual or binary, whose semantics depend on the type of the message as defined by the header contents. Typical examples are serializations of contract offers, contract agreements, or data artifacts.
Implementation in Protobuf
A well-known framework that supports all of these criteria is the open source solution protobuf. It has been developed and is currently maintained by Google, but also supported by a large community.
Protobuf defines a message-format for platform-independent definition of message formats, which can be used to serialize common data fields like strings (as UTF-8), binary data, various kinds of fixed size or variable size integers, floating point values etc. into plain byte arrays that can be sent/received via any reliable binary communication protocol. More information is found in the official documentation: https://developers.google.com/protocol-buffers
A message definition for IDS messages looks as follows:
The IDSCP2 App Layer Protocol uses exactly this message definition for IDS messages, plus an identically structured message definition for generic messages without a JSON-LD header, for more generic use cases. The IDSCP2 App Layer definitions are found in idscp2-app.proto.
IDSCP2 Message Types
The message type is held within the header field called ‘idscp2.type’. Since it simply contains a serialization for the IDS Information Model Messages in JSON-LD, any defined IDS Message types can be supported. Some examples for headers and payloads can be found here.
Clearing House Interactions
Connectors can interact with the Clearing House using the IDSCP2 App Layer Protocol. The Clearing House accepts the IDS message types LogMessage, QueryMessage and RequestMessage. In most cases, the Clearing House expects additional headers. The following sections detail the possible interactions and list the expected headers as well as the results.
Creating a Processes
The IDS Clearing House structures its logs into processes and requires that all messages are logged under a process id. Processes are meant to represent agreed upon data exchanges that include the storage of the contract agreement and all messages that document the data exchange. Processes can be created by any IDS connector with a valid DAT, who becomes the owner of the process. Additional owners can be defined in the parameters of the request. Only owners of the process may read or write log entries for the process. The Clearing House expects a RequestMessage to create a process id.
Additional Headers
Name | Type | Required | Description |
---|---|---|---|
ch-ids-pid | string | true | The unique identifier of the process that will be used for logging all information connected to the process |
Content-Type | string | true | The Clearing House expects the content type "application/json" |
Expected Response
Message | Meaning | Description |
---|---|---|
Created | The unique identifier has been created and is sent back as the payload. | |
Error | An error occurred. The payload contains an HTTP error code. |
Logging messages
To log information in the Clearing House a LogMessage must be sent. The payload contains the information that should be logged. The log entry stored in the Clearing House under the given process pid. Returns a signed receipt of the logged data in form of a JSON Web Token (JWT) as payload of the response.
Additional Headers
Name | Type | Required | Description |
---|---|---|---|
ch-ids-pid | string | true | The unique identifier of the process under which the data should be logged |
Expected Response
Message | Meaning | Description |
---|---|---|
Created | The payload contains the signed receipt of the logged data in form of a JWT. | |
Error | An error occurred. The payload contains an HTTP error code. |
Query multiple messages of a process
The Clearing House expects a QueryMessage to retrieve multiple log entries. Pagination is enforced, so retrieving all log entries might require multiple requests. When querying the Clearing House the query may contain the requested page of data, the size of the requested page, and the sorting order of the results. The Clearing House answers the request with a ResultMessage. The payload contains the log entries found, as well as the pagination information page, size and order that were used in the request. Each log entry is returned as a LogMessage.
Additional Headers
Name | Type | Required | Description |
---|---|---|---|
ch-ids-pid | string | true | The unique identifier of the process under which the log entry was created |
ch-ids-page | string | false | The requested result page. Defaults to 1 |
ch-ids-size | string | false | The size of the requested result page. Defaults to 100 |
ch-ids-sort | string | false | The order of the requested results. Defaults to "desc" |
ch-ids-date_to | string | false | Only results before given date. Date format: YYYY-MM-DD |
ch-ids-date_from | string | false | Only results after given date. Date format: YYYY-MM-DD |
Content-Type | string | true | The Clearing House expects the content type "application/json" |
Expected Response
Message | Meaning | Description |
---|---|---|
Ok | The Clearing House sends back a JSON containing both pagination information and an array of log entries in the form of LogMessage | |
Error | An error occurred. The payload contains an HTTP error code. |
The following example illustrates the payload sent by the Clearing House as an answer to a QueryMessage for multiple log entries:
Query a single message of a process
Retrieves the log entry that is stored under the given id and the given process pid in the Clearing House. The Clearing House answers the request with a ResultMessage that contains as the payload the log entry found. The log entry is returned as a LogMessage, i.e., the payload of the ResultMessage contains a LogMessage.
Additional Headers
Name | Type | Required | Description |
---|---|---|---|
ch-ids-pid | string | true | The unique identifier of the process under which the log entry was created |
ch-ids-id | string | true | The unique identifier of the log entry requested |
Content-Type | string | true | The Clearing House expects the content type "application/json" |
Expected Response
Message | Meaning | Description |
---|---|---|
Ok | The Clearing House sends back the requested log entry in the form of LogMessage | |
Error | An error occurred. The payload contains an HTTP error code. |
Last updated