2 | X-Road 8 PoC status | A blog post about the X-Road 8 PoC status is available here. The following items have been implemented since the previous TC meeting: Support for SOAP services. Both REST and SOAP services are supported now. requestHash is an optional SOAP header which is not being created in POC.
Custom request headers are not forwarded to the provider information system, because the EDC does not support it.
Support for signing messages using JAdES-B-LT signatures. Currently, X-Road uses XADeS signatures. Implementation uses the Digital Signature Services (DSS) Java library provided by the European Commission. Signatures and sign cert OCSP responses are passed in HTTP headers. Limitations compared to the current implementation: Message body and most of the HTTP headers signed. HTTP verb, request path and URL parameters are not signed. No support for batch signing - every message is signed separately. Message logging is not supported, because timestamping code is not compatible with JAdES signatures. Support can be added, but it requires additional work.
Support for defining access permissions using ODRL. X-Road-specific ODRL profile that enables using X-Road identifiers and REST service request paths in the ODRL policies has been implemented. Individual clients and global groups are supported. Local groups are not supported yet.
Support for TLS between (control + data plane). Consumer verifies provider's TLS certificate just like now. Provider does not require client TLS certificate from consumer (=mTLS disabled). The current way to handle TLS certificates is X-Road specific. Data space specifications don't currently include a similar mechanism. Instead, by default, the system trust store is used. In X-Road 8, at least the control plane level should follow common practices to remain interoperable with other data spaces and connector implementations. Any X-Road-specific details should be kept on the data plane level. Further analysis is required in the next stages.
Support for caching and reusing the JWT token that's generated as a result of the contract negotiation process. New contract negotiation is required when the token expires (every 10 minutes by default). Consuming X-Road services without a consumer side Security Server (so called “light context) can be implemented. The consumer organisation must be registered as an X-Road member. Authenticating the client is based on an access token that must be generated using some alternative channel, e.g., service catalogue.
An internal instance of Gaia-X Digital Clearing House (GXDCH) services has been installed and configured.
Coming up next: Improve automated test coverage of the changes that have been implemented. Look into proper key management and HSM support in the EDC. Make the EDC Minimum Viable Dataspace (MVD) example setup work with the latest version of the GXDCH services. Integrate the Gaia-X trust framework with the control and data plane level changes that have already been implemented. Look into supporting X-Road's current trust framework and Gaia-X trust framework in parallel.
|
| Next meetings | Meeting 22, April 22 2024, 15:00-16:00 (EEST, UTC +3) Meeting 23, May 25 20 2024, 15:00-16:00 (EEST, UTC +3) Meeting 24, June 19 2024, 15:00-16:00 (EEST, UTC +3) Meeting 25, August 21 2024, 15:00-16:00 (EEST, UTC +3) Meeting 26, September 18 2024, 15:00-16:00 (EEST, UTC +3) Meeting 27, October 23 2024, 15:00-16:00 (EEST, UTC +3) Meeting 28, November 20 2024, 15:00-16:00 (EET, UTC +2) Meeting 29, December 18 2024, 15:00-16:00 (EET, UTC +2) Meeting 30, January 22 2025, 15:00-16:00 (EET, UTC +2) Meeting 31, February 19 2025, 15:00-16:00 (EET, UTC +2) Meeting 32, March 19 2025, 15:00-16:00 (EET, UTC +2)
|