feat(did): IdentityHub-based DidDocumentServiceClient for DID self-registration

[wahidulazam]

What

Add DidDocumentServiceIdentityHubClient — a new implementation of the DidDocumentServiceClient SPI (spi/did-document-service-spi) that registers the DSP endpoint in an IdentityHub instance via its Identity Admin API.

Why

Today only one implementation of DidDocumentServiceClient exists:

Implementation	Target	Status
DidDocumentServiceDimClient	SAP DIM / DIV	✅
DidDocumentServiceIdentityHubClient	IdentityHub	❌ missing

When tx.edc.iam.sts.dim.url is not set (DCP/IdentityHub mode), no DidDocumentServiceClient is registered. As a result, tx.edc.did.service.self.registration.enabled=true is a no-op — the DSP endpoint is never written to the DID Document and the DCP flow fails.

Discovered while testing tractusx-identityhub PR #244 against current main.

How

New module: edc-extensions/did-document/did-document-service-identity-hub/

Calls IdentityHub Identity Admin API (port 8082, X-Api-Key auth):

POST   /v1/unstable/participants/{contextId}/dids/{base64url-did}/endpoints?autoPublish=true
DELETE /v1/unstable/participants/{contextId}/dids/{base64url-did}/endpoints?serviceId={id}&autoPublish=true

New config:

tx.edc.ih.identity.api.url=
tx.edc.ih.participant.context.id=
tx.edc.ih.identity.api.key.alias=

Activates only when tx.edc.iam.sts.dim.url is unset — mutually exclusive with the DIM client.

References

• edc-extensions/did-document/did-document-service-dim — reference impl
• #tractusx-identityhub#244
• #sig-release#1609 (R26.06 IdentityHub + Connector bundle)

/cc @lgblaumeiser @arnoweiss

I have already implemented it in my company's public repo and opened a pull request there. If you find everything right, I'll be happy to contribute. Here is the pull request link:
Federity-X#7

Update: implemented a better version here: Federity-X#8

[arnoweiss]

Thanks for raising this - two comments aiming to reduce the need to introduce new config variables:

1. The way it's done for the STS-API infers the wallet implementation from the config [1]. I find this quite elegant - perhaps the DID document client should follow the same pattern.
2. I'm not too familiar with auth on the IH APIs but at least the STS client requires OAuth2 client credentials. That's convenient because it thus reuses the same helm values as for SAP DIV. What's your reasoning for using an API key here?

[1]

tractusx-edc/edc-extensions/dcp/tx-dcp-sts-dim/src/main/java/org/eclipse/tractusx/edc/iam/dcp/sts/RemoteTokenServiceClientExtension.java

Lines 73 to 82 in ba45ef3

	return ofNullable(dimUrlConfig)
	.map(PathUtils::removeTrailingSlash)
	.map(dimUrl -> {
	monitor.info("DIM URL configured, will use DIM STS client");
	return (SecureTokenService) new DimSecureTokenService(httpClient, dimUrl, dimOauth2Client, typeManager.getMapper(), monitor);
	})
	.orElseGet(() -> {
	monitor.info("DIM URL not configured, will use the standard EDC Remote STS client");
	return new RemoteSecureTokenService(oauth2Client, participantContextId -> clientConfiguration, vault);
	});

[wahidulazam]

Thanks for raising this - two comments aiming to reduce the need to introduce new config variables:

1. The way it's done for the STS-API infers the wallet implementation from the config [1]. I find this quite elegant - perhaps the DID document client should follow the same pattern.
2. I'm not too familiar with auth on the IH APIs but at least the STS client requires OAuth2 client credentials. That's convenient because it thus reuses the same helm values as for SAP DIV. What's your reasoning for using an API key here?

[1]

tractusx-edc/edc-extensions/dcp/tx-dcp-sts-dim/src/main/java/org/eclipse/tractusx/edc/iam/dcp/sts/RemoteTokenServiceClientExtension.java

Lines 73 to 82 in ba45ef3

return ofNullable(dimUrlConfig)
.map(PathUtils::removeTrailingSlash)
.map(dimUrl -> {
monitor.info("DIM URL configured, will use DIM STS client");
return (SecureTokenService) new DimSecureTokenService(httpClient, dimUrl, dimOauth2Client, typeManager.getMapper(), monitor);
})
.orElseGet(() -> {
monitor.info("DIM URL not configured, will use the standard EDC Remote STS client");
return new RemoteSecureTokenService(oauth2Client, participantContextId -> clientConfiguration, vault);
});

Thanks for the feedback and raising a valid point. But, OAuth2 for the IdentityHub Identity Admin API was first shipped in upstream v0.16.0** (~Feb 2026), via PRs #879 and #880. It is NOT available in v0.15.1 (Dec 18, 2025), which is the version this PR targets. The IH Identity Admin API at v0.15.1 exclusively uses X-Api-Key. The key is stored in the same vault infrastructure as DIM credentials, just with a different alias pattern. When we upgrade to a 0.16.0 IH version that includes OAuth2 support, we can add it as an additional auth option. Anyway, after your comment, reviewed my work and found another issue. Working on that. So, cordial thanks to you.

[lgblaumeiser]

Hi @wahidulazam , one of the upcoming topics is to move upstream to 0.16.0. So please do not implement anything, that has to solved differently with 0.16.0.

[wahidulazam]

Great. That will ease our life. Thanks. lgblaumeiser