Remove SKI/AKI usage

[SebastianOpriel]

Feature Request

Description

SKI/AKI is a relict of from the first days of IDS. We want to discuss, if the SKI/AKI can be removed and replaced with a custom ID coming from a data space authority in control of DAPS. For those tagged, please (if you can) edit this issue and add information on where and how SKI/AKI is used.

Which Areas Would Be Affected?

KC DAPS

Management CLI uses SKI/AKI by default to generate client ID, but can be overridden.

EDC

• SKI/AKI is used via EDC_OAUTH_CLIENT_ID field
• EDC_OAUTH_CLIENT_ID is used to receive a DAT from DAPS, who compares this ID with Subject field.
• something about which field is used for policies? @efiege
  • The Referring-Connector-Policy will check the referringConnector-Claim of the DAT. However this does not affect the connector implementation, but the configuration of the DAPS. DAPS implementations which are not capable of setting the referringConnector-Claim may be incompatible afterwards. @SebastianOpriel

Broker

At its base, the Broker is an EDC connector which means that same rules apply. A client ID is needed to register the Broker in DAPS, but it's not generated in the Broker itself but rather provided by the host via environment variables.
Since the clientID is just an identifier for DAPS, dropping the AKI/SKI generation method should not affect the Broker in any way

Clearing House

We are currently exploring replacing the SKI/AKI as the client_id in the clearing-house-server with the participantId. The clearing-house-server, if possible, should no longer depend on the SKI/AKI.

Authority Portal

In the AP, we use AKI and SKI to generate the client ID (for registering the connector at the DAPS) of self-hosted connectors. Since we already use a different method (deriving it from the connector ID/participant ID) to generate client IDs for CaaS connectors, which is also applicable to self-hosted connectors, this would be a very quick adjustment.

Addition (April 9th): We use the client ID (AKI/SKI), which is stored in our database, to check if a connector with the given certificate is already registered. So in some form, this information would still be needed to be saved, though not used as the client ID.

Why Is the Feature Desired?

SKI/AKI is always an issue. The overall trust chain might simply rely on another ID, as SKI/AKI coming from the X509 certificate is not used for checks.

Solution Proposal and Work Breakdown

EDC

• Remove mandatory field EDC_OAUTH_CLIENT_ID and by default preset it with MY_EDC_PARTICIPANT_ID
•  Remove documentation about SKI/AKI

Authority Portal

• Adjust "Add Connector" process (ONLY if EDC is available who supports above's feature)
  • Remove logic to calculate SKI/AKI
  • Remove EDC_OAUTH_CLIENT_ID field
•  Adjust function to check if same connector is already registered to make use of another field
• Change Client ID generation for CaaS and service provided authority-portal#327

[dhommen]

We are currently exploring replacing the SKI/AKI as the client_id in the clearing-house-server with the participantId. The clearing-house-server, if possible, should no longer depend on the SKI/AKI.