chore: bump core platform to 0.0.19 - #13
Merged
Merged
Conversation
jimmarino
approved these changes
Aug 19, 2026
paullatzelsperger
added a commit
that referenced
this pull request
Aug 20, 2026
* bump chart to 0.0.19 # Conflicts: # charts/cx-ve/Chart.lock * feat(api): register credential holders directly with the IssuerService Replaces the Onboarding API's tenant-manager invocation: the onboarding process now creates the holder entry in the IssuerService itself (resource "sudo", scope issuer-admin-api:admin, mirroring the CFM registration agent) and completes right there — the CONFIRMED status callback fires within the registration call. EDC resource provisioning moves downstream of that confirmation (upcoming membership hub). - new HolderRegistrationService port + IssuerService adapter (409 = already registered, so re-drives stay idempotent) - state machine runs synchronously to COMPLETED; the NATS issuance subscriber, provisioning poll loop and holder-id correlation are gone (the lifecycle-event publisher stays); OnboardingState itself is unchanged - OnboardingProcess/entity drop the tenant-manager fields; OnboardingCompleted no longer carries a participantContextId - chart: jwtlet seed maps the SA to the "sudo" context with issuer-admin-api:admin only; issuer-service.* config replaces tenant-manager/identityhub; participant.dataplane/ccm move out - orchestration definition: registration-agent/registration-rollback removed from the VPA DAG (cfm.issuer VPA properties must keep travelling with the profile — the certo activity reads the BPN from them) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017nfecB3UB91xPzX2r1fGA8 * feat(hub): introduce the Catena-X Membership Hub New Spring Boot app driving a partner's full path into the dataspace across the two halves the VE keeps apart: it submits the CX-0006 registration to the Onboarding API (as OSP client "membership-hub" against the OSP IdP) and, on the CONFIRMED status callback, provisions the EDC resources via the CFM Tenant Manager — whose client code moves here from the Onboarding API. The membership record correlates the hub-minted externalId (the id the callbacks carry) with the participantContextId provisioning assigns. - POST /api/members + GET /api/members/{externalId} (lazy Tenant-Manager refresh on read); POST /api/callbacks/registration-status for the callback - callback may arrive before the submitting call returns (the Onboarding API completes synchronously); registering() never rolls that progress back - profile deployment keeps sending the cfm.issuer VPA properties (the certo activity reads the BPN from them); BPN is therefore required on ingress - Postgres persistence (own membershiphub database, seeded by the chart) with an in-memory "test" profile, mirroring the onboarding-api layout - new charts/membership-hub (deployment/config, jwtlet seed at hook weight 230 mapping the SA to tenant-manager-api scopes, postgres seed, optional HTTPRoute), wired into the umbrella; OSP IdP gets the membership-hub client - install-ve.sh builds/loads the image; CI builds/tests and publishes it Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017nfecB3UB91xPzX2r1fGA8 * fix(hub): rename the onboarding RestClient bean off the @service's name The @bean method onboardingApiClient() collided with the OnboardingApiClient @service's default bean name, and bean-definition overriding is disabled, so the pod failed on startup. Renamed to onboardingApiRestClient. Added the missing context-load smoke test (mirroring the onboarding-api's), which catches this class of clash at build time. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017nfecB3UB91xPzX2r1fGA8 * fix(api): register holders WITH the attestation properties The seeded credential definitions attest via the holder attestation and require bpn/memberOf/contractVersion/id from the holder's properties; a holder created without them makes credential generation fail ("Failed to apply mapping definition") and leaves the credential request stuck in REQUESTED — the onboarding agent then retry-loops forever. Send the same property map the CFM registration agent used to pass (id = DID, bpn, memberOf = active agreement ids, contractVersion 1.0.0). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017nfecB3UB91xPzX2r1fGA8 * feat(hub): sequential onboard flow, gateway route on by default Provisioning now runs inside POST /api/members: the registration submission returns (the Onboarding API completes synchronously and its CONFIRMED callback is recorded meanwhile), then the tenant + participant profile are deployed and the returned profile id is stored on the record. The callback no longer triggers anything — it only records CONFIRMED/REJECTED — and the Tenant Manager poll loop is gone: GET /api/members/{externalId} resolves the stored profile id and reads the profile's current state from the TM until the membership is terminal. Provisioning still only happens on a CONFIRMED registration (a rejected one is answered with a normal 200 too); a registration without a synchronous confirmation surfaces as REGISTERING and is never provisioned. New state CONFIRMED marks the callback's outcome. The hub's HTTPRoute (/hub) is now enabled by default; install-ve.sh and redeploy-ve.sh set its hostname from -H, and redeploy-ve.sh builds/loads the hub image and restarts its deployment alongside the other apps. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017nfecB3UB91xPzX2r1fGA8 * refactor property names * docs+scripts: catch up with the hub-driven onboarding flow - root README: monorepo table and build/deploy sections cover the membership hub; new "How a member gets onboarded" walkthrough of the split flow; fixed the stale claim that install-ve.sh builds nothing (it builds and kind-loads the three app images); documented redeploy-ve.sh and the /hub route with a curl example - scripts/README: install-ve.sh/vps descriptions updated, redeploy-ve.sh documented (was missing entirely), onboard-participant.sh described as the hub-driven full journey - onboard-participant.sh now drives the Membership Hub: POST /hub/api/members and poll GET /api/members/{externalId} until PROVISIONED (REJECTED/FAILED exit non-zero, an unconfirmed REGISTERING exits immediately). OSP token machinery, kubectl log-tailing and the --cluster/--namespace flags are gone - e2e.sh onboards through the hub, gated on PROVISIONED — un-breaking its DID check under the split flow - install-ve-vps.sh: add the membership-hub host overrides (DID template + route hostname) that a real-hostname install needs - docs: issuance-flow attribution and the intra-VE component list updated; sut-verification points at the hub for ve2's wallet/data-plane obligations Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017nfecB3UB91xPzX2r1fGA8 * refactor(hub): revert the wire-field renames, keep tenantId/participantProfileId/participantContextId Restores the original membership field names across the record, entity, port, docs and the onboard-participant.sh projection — the earlier rename also broke the participant-context extraction from cfm.vpa.state (the Tenant Manager writes "participantContextId"). Plus a debug log when an OSP registers its callback address. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017nfecB3UB91xPzX2r1fGA8 * test(e2e): onboard through the Membership Hub The suite's participants now come from the hub's full journey: new MembershipHubApi submits POST /api/members and polls the membership until PROVISIONED (failing fast on REJECTED/FAILED/REGISTERING), and the provisioned identities — participant context id included — are read straight off the correlated record, guarded against wire-contract skew. That removes the WireMock-callback wait, the DID-template mirroring and TenantManagerApi (which also exchanged under the onboarding-api jwtlet mapping that no longer carries tenant-manager scopes). The OSP-facing surface keeps its own contract test: register a status callback as osp-client, submit a registration directly, pin the CONFIRMED callback — the hub-driven tests no longer touch the shared osp-client callback slot. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017nfecB3UB91xPzX2r1fGA8 * fix(hub): port the bpn claim-source change from upstream (fb216ea) The rebase dropped it: upstream added the BpnCredential claimMapping to the transfer-type mapping in ParticipantOnboardingService, a file this branch deletes — its logic now lives in the hub's CfmTenantManager, so the mapping is restated there. Siglet stamps the caller's BPN into the flow token from its credential; the e2e assets carry no static bpn property anymore. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017nfecB3UB91xPzX2r1fGA8 * fix(hub): opt the data-plane registration into DPS signaling auth The second half of upstream #13 lost in the rebase's modify/delete conflict: the cfm.dataplane VPA must carry the oauth2_token_exchange authorization profile so the control plane acquires a jwtlet token for its signaling calls — siglet 0.0.19 enforces signaling_auth, and without the profile every transfer died at flow prepare with 401 "Missing Authorization header". Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017nfecB3UB91xPzX2r1fGA8 * move e2e tests to membership-hub app --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
bump core platform to 0.0.19