Protocol

Overview

The Notifier provides functionality for delivering notifications containing information to be shared between data providers and consumers regarding updates and receipt status related to data transactions.

This layer covers the following domains:

• Notification Destination List Management Provides functionality for managing notification destination lists required when a Data Provider notifies Data Consumers of the registration, update, or deletion of provided data.

• Notification Management Provides functionality for managing notifications issued by Data Providers and for enabling Data Consumers to review notification information.

Abstract Normative Specification

Concepts and Roles

The following concepts are required for this protocol.

Concept	Description
Data Provider	An entity that sends data stored in a data store to a Data Consumer.
Data Consumer	An entity that receives data from a Data Provider.

Scope

• Management of notification destination lists related to data provision within Open Dataspaces

• Management of notifications related to data provision within Open Dataspaces

Normative Requirements

Notification Destination List Management

• Notification destination lists SHALL be managed per Data Provider, and SHALL NOT be shared or mixed between different Data Providers.

  • Rationale: To ensure independence and security of notification configurations for each Data Provider.

• The system MAY provide functionality to register, update, or delete multiple notification destinations in bulk, as necessary.

  • Rationale: To reduce operational burden and improve administrative efficiency.

• If stored data is encrypted, standard cryptographic techniques, including those recommended by CRYPTREC, MAY be referenced and adopted as necessary.

  • Rationale: To allow consideration of encryption technologies in accordance with operational requirements.

Notification Management

• Notification management SHOULD be performed based on authentication and authorization using identity information of Data Providers and Data Consumers derived from authentication credentials.

  • Rationale: To ensure consistency with the requirements of the L2 and L3 layers and to enforce access control for notification information.

• The system MAY provide functionality to register, update, or delete multiple notifications in bulk, as necessary.

  • Rationale: To reduce operational burden and improve administrative efficiency.

• If stored data is encrypted, standard cryptographic techniques, including those recommended by CRYPTREC, MAY be referenced and adopted as necessary.

  • Rationale: To allow consideration of encryption technologies in accordance with operational requirements.

Non-functional / Cross-layer Requirements

• This function is assumed to be used via Transaction（L2）.

• This function is assumed to use tokens issued by the Identity & Trust（L3）t.

Message Types

Type	Sender ⇒ Receiver	Description
Request	Client (Transaction（L2）) ⇒ Server (Notifier)	A message sent by the client to execute functions of the Notifier. Includes authentication information and request parameters.
Response	Server (Notifier) ⇒ Client (Transaction（L2）)	A message sent by the server in response to a request. Includes processing results and error information.

Protocol Flow

The message exchange sequence when using the Notifier is shown below.

Error Handling

This section describes the error handling used in this protocol.

Error Type	Description	Handling
Invalid Request	Returned when parameters are invalid or required fields are missing.	Verify input values, correct them, and resend the request.
Token-related Error	Returned when the access token is not set or is invalid.	Reacquire and reset the access token (re-login or token refresh if necessary) and resend the request.
Insufficient Authorization	Returned when required permissions are lacking.	Notify that the operation is not permitted. Do not resend, as it will not succeed.
Resource Not Found	Returned when the specified resource does not exist.	Notify that the resource does not exist. Do not resend, as it will not succeed.
Data Inconsistency Error	Returned in cases such as duplicate data or concurrency control conflicts.	Retrieve the latest data, resolve conflicts, and resend the request.
Invalid Request Format	Returned when an unsupported request format is specified.	Set the correct Content-Type and resend the request.
System Error	Returned when an internal server error occurs.	If it occurs continuously, notify the system administrator. Whether to resend depends on the operation performed.

References

• CRYPTREC Cryptographic List: https://www.cryptrec.go.jp/list/cryptrec-ls-0001-2022r1.pdf