Should RemoteSecureTokenService be marked and loaded as default?

[arnoweiss]

The STS-API is implementation-specific and non-standardized. The StsRemoteClientExtension [1] provides an implementation of SecureTokenService into the IoC container. It's not marked with isDefault = true so as soon as another SecureTokenService is injected, there's a warning [2] and load-order-dependent behavior. That's why using a different STS implementation requires a gradle exclusion [3].

Let's discuss if it makes sense to

1. mark the provider extension as default.
2. include the Provider in the extension that loads defaults for DCP [4].

[1]
https://github.com/eclipse-edc/Connector/blob/main/extensions/common/iam/decentralized-claims/decentralized-claims-sts/decentralized-claims-sts-remote-client/src/main/java/org/eclipse/edc/iam/decentralizedclaims/sts/remote/client/StsRemoteClientExtension.java

[2]

{"timestamp":"2026-03-23T13:38:19.2373343","level":"WARNING","message":"A service of the type org.eclipse.edc.iam.decentralizedclaims.spi.SecureTokenService was already registered and has now been replaced with a RemoteSecureTokenService instance."} 

[3]
https://github.com/eclipse-tractusx/tractusx-edc/blob/096ed9b2bcd1470c357c21b128175f315de9227a/edc-controlplane/edc-controlplane-base/build.gradle.kts#L30-L31

[4]

Connector/extensions/common/iam/decentralized-claims/decentralized-claims-core/src/main/java/org/eclipse/edc/iam/decentralizedclaims/core/DcpDefaultServicesExtension.java

Lines 71 to 110 in 87b33ad

	@Provider(isDefault = true)
	public TrustedIssuerRegistry createInMemoryIssuerRegistry() {
	return new DefaultTrustedIssuerRegistry();
	}
	@Provider(isDefault = true)
	public SignatureSuiteRegistry createSignatureSuiteRegistry() {
	return new InMemorySignatureSuiteRegistry();
	}
	@Provider(isDefault = true)
	public DefaultParticipantIdExtractionFunction defaultParticipantIdExtractionFunction() {
	return new DefaultDcpParticipantIdExtractionFunction();
	}
	@Provider(isDefault = true)
	public ScopeExtractorRegistry scopeExtractorRegistry() {
	return new DcpScopeExtractorRegistry();
	}
	// Default audience for DCP is the counter-party id
	@Provider(isDefault = true)
	public AudienceResolver defaultAudienceResolver() {
	return (msg) -> Result.success(msg.getCounterPartyId());
	}
	// Default ClaimToken creator function, will use "vc" as key
	@Provider(isDefault = true)
	public ClaimTokenCreatorFunction defaultClaimTokenFunction() {
	return credentials -> {
	var b = ClaimToken.Builder.newInstance()
	.claims(Map.of(CLAIMTOKEN_VC_KEY, credentials));
	return success(b.build());
	};
	}
	@Provider(isDefault = true)
	public DcpScopeStore scopeStore() {
	return new InMemoryDcpScopeStore(criterionOperatorRegistry);
	}

[paullatzelsperger]

Technically, you don't need to define any exclusions, all you need to do is not include the decentralized-claims-sts module (or more specifically: the decentralized-claims-sts-remote-client) in your build file.

That being said, when using EDC BOMs the STS Remote Client is indeed on the classpath and an exclusion would be necessary.

BOMs are intended to provide a sensible runtime from the perspective of EDC committers, and that would naturally include other EDC components such as STS.

Default providers are really more intended for fallback implementations, such as in-mem stores or registries. EDC's STS implementation is not a fallback, it was a conscientious decision to include it.

I saw that in the build file you linked there are other exclusions as well, so my recommendation would be to define a custom Tractus-X BOM that does not contain the STS module (and any of the others). This will provide the most flexibility down the road.