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.
Logging implementation details require further analysis in the next stages.
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.
An instance of the X-Road Test CA has been configured as the trust anchor for the services.
The services can be used to issue Gaia-X credentials.
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.
Use the EDC Identity Hub component to store Gaia-X credentials.
Use Gaia-X credentials in contract negotiation and access control.
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.