Skip to content

feat: make ParticipantSecureTokenService a default provider - #1058

Open
paullatzelsperger wants to merge 3 commits into
mainfrom
feat/sts_default_provider
Open

feat: make ParticipantSecureTokenService a default provider#1058
paullatzelsperger wants to merge 3 commits into
mainfrom
feat/sts_default_provider

Conversation

@paullatzelsperger

Copy link
Copy Markdown
Member

What this PR changes/adds

Marks the ParticipantSecureTokenService provider in EmbeddedStsServiceExtension as a default provider (@Provider(isDefault = true)).

Moves the StsClientTokenGeneratorService provider out of EmbeddedStsServiceExtension into a new StsClientTokenGeneratorExtension (same module), which injects the resolved ParticipantSecureTokenService instead of calling the embedded implementation directly.

Why it does that

The self-issued token claims (e.g. for DCP credential requests to an issuer) are fixed by the callers of ParticipantSecureTokenService, and there is no decorator hook in the token generation chain. Previously, customizing the token (e.g. adding a claim) required excluding the entire sts-core module from the runtime, because the service was registered via a plain @Provider. With a default provider, downstream extensions can simply out-provide ParticipantSecureTokenService with their own implementation.

Splitting off the StsClientTokenGeneratorService provider ensures consistency: it was previously hard-wired to the embedded STS, so an out-provided ParticipantSecureTokenService would have been used by the DCP flows but silently bypassed by the STS API token endpoint.

🤖 Generated with Claude Code

The embedded STS was registered via a plain @Provider, so replacing the
ParticipantSecureTokenService (e.g. to add custom claims to self-issued
tokens) required excluding the sts-core module from the runtime. It is
now a default provider, so any extension providing the service takes
precedence.

The StsClientTokenGeneratorService provider is moved to a separate
extension that injects the resolved ParticipantSecureTokenService, so
the STS API uses a replacement implementation as well instead of being
hard-wired to the embedded one.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@paullatzelsperger
paullatzelsperger requested a review from a team as a code owner August 14, 2026 11:49
@paullatzelsperger paullatzelsperger added the enhancement New feature or request label Aug 14, 2026
@paullatzelsperger paullatzelsperger added refactoring Changing directories, modules, structures, etc. without functional changes and removed enhancement New feature or request labels Aug 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

refactoring Changing directories, modules, structures, etc. without functional changes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants