Skip to main content

Offer Data to Other Organizations in Trust Framework

Advertise data and services to trusted organizations. Add authorization servers enabling client applications to authenticate themselves and obtain tokens. Publish your APIs for all federation participants to discover. Request certificates for mTLS.

Prerequisites​

  • Your organisation is onboarded within Raidiam Connect.

  • Roles are assigned to your Organization.

note

When your organization is registered in an ecosystem, the Trust Framework Administrator provides you with URLs:

  • Sandbox URL for Raidiam Connect and its OIDC Discovery API

  • Production URL for Raidiam Connect and its OIDC Discovery API


Both environments are functionally identical. The Sandbox environment is used for testing prior to consuming or publishing APIs in Production. Always validate your configuration and changes in Sandbox before moving to Production.

Required Actions for Organizations Offering Data​

Organizations offering data, or users acting on their behalf, need to perform the following actions on the Trust Framework:

  • Sign Participation Documents - optional depending on the ecosystem's requirements

    To fully onboard on the ecosystem, all participants–including organizations offering data, TPPs, and VASPs–must issue and sign the Ecosystem Participation Document via DocuSign.

  • Ensure Server Certificates are Valid

    • Generate transport, signing, and encryption certificates on the Trust Framework.

    • Rotate certificates at least once every 12 months (certificate expiration is set at 13 months).

  • Ensure Published APIs are Valid and Certified

    • Publish API endpoints and ensure the correct version is available before any defined ecosystem go-live date.

    • Keep server metadata up to date, including server logo, description, and customer-facing name.

  • Integrate with Directory for Onboarding

    • Integrate with the Trust Framework registration endpoints, ensuring all clients are onboarded and validated following the ecosystem requirements

  • Integrate Authentication

    • Use the Trust Framework JWKS endpoints to retrieve client public keys for message signature validation and encryption.

    • Use Directory OCSP/CRL services to verify that certificates are valid and up to date.

Points 1 and 2 require active directory usage and are covered in this guide.

Points 3 and 4 are programmatic and detailed in the Ecosystem API Security Documentation.

Add Server​

Add an Authorisation Server -- sometimes referred to as OpenID Provider -- to publish your APIs for external consumption. It makes it possible for Data Receivers to discover its configuration using OIDC Discovery (/.well-known endpoint) and obtain data, after properly onboarded, using their client applications credentials.

  1. Select Servers > New Server.

  2. Fill in the details of the organization's authorization server.

    Field nameRequiredField descriptionExample
    Customer friendly server nameYesShould be equal to the brand name that can be easily identifiable by the customer on the consent flowAdd the name without abbreviations so that it can be recognized by the customer that is to provide their consent to share data. Maximum of 256 charactersRaidiam
    OpenID discovery document URIYesThe URI that points to the OpenID discovery document (/.well-known endpoint.https\://raidiam.com/openid-configuration/.well-known
    Payload signing certificate URIYesURI points to the Signature Certificates and Public Keys used to payload signatures by Data Receivers.Should point to the certificate you uploaded to the authorization server in the previous section of this article.https\://raidiam.com/payload-uricertificate
    Customer friendly logo URIYesThe Logo that represents the Brand Name added on the Customer Friendly Namehttps\://raidiam.com/logo.svg
    Developer Portal URINoURI for the Server developer portalhttps\://developers.raidiam.com
    Terms of service URINoURI that points to the server terms of service URIhttps\://raidiam.com/tos
    Notification webhook endpointNoEndpoint of the webhook notification URI that will be used to receive notifications from the Directory.Note this endpoint needs confirmation. Visit the URL sent to endpoint within 3 days to confirm the subscription. This URI is optional and allows the server to receive notification in case any relevant information on Connect is added or updated.webhook.site/97askmbf-c320-4982-b0ff-f7728893aa
    DescriptionYes1. Character limit: 256 characters
    2. Description cannot have links.
    3. Should contain a description of the brand with any additional information the user should know.
    Can also contain:
    * Organization introductory text
    * Organization Start Date
    * Institution Differences
    * Contact Channels    		This is where you can describe your brand, bringing any additional information to help the user make the right choice while providing their authorization to access the APIs.

  3. Save.

Some organizations may have different authorization servers responsible for issuing access tokens that give access to different APIs or services. In such cases, add additional authorization servers your organization has.

Authorization Server Requirements for Client Registration​

To ensure that your published APIs can be accessed by authorized applications, your authorization server must support the client registration method mandated by your ecosystem's Registration Framework. This is essential for enabling client applications (e.g., TPPs, relying parties, partner services) to obtain the credentials required to request access tokens.

Depending on your ecosystem’s policies, your authorization server must support at least one of the following registration mechanisms:

  • OAuth Dynamic Client Registration (DCR) The server exposes a standards-based API that allows clients to register programmatically and obtain their credentials.

  • OpenID Federation

    • Automatic Client Registration

      In automatic mode, the RP simply initiates an OpenID Connect flow using its entityID as client_id. The AS fetches the RP’s entity configuration, retrieves subordinate and anchor statements, validates signatures and expirations, and enforces policy before creating or updating the client record.

    • Explicit Registration

      The RP POSTs its entity statement (as a JWT or JSON trust chain). The AS validates the chain against the Trust Anchor, enforces registration policy, and responds with confirmation.

Optionally, your authorization server may also provide Manual Client Registration capabilities where Administrators can onboard clients directly via the server’s management UI or the organisation’s developer portal.

Whichever method your ecosystem requires, it is important that your authorization server implements it consistently so that all compliant client applications can be registered and issued credentials without friction.

Add Organisation Transport Certificate for mTLS: Optional​

mTLS certificates–both the Data Providers and Data Receivers trust–empowers your technical assets, such as the authorization server and resource server, enabling them to engage in secure TLS handshakes during communication with client applications.

  1. Navigate to your organization.

  2. Select Organization Certificates > New Certificate.

  3. Select TRANSPORT as the Certificate Type and continue.

  4. In your terminal, execute the provided command to generate a Certificate Signing Request (CSR).

  5. Upload the generated CSR/PEM.

    Your CSR/PEM is sent to the Registration Authority which checks its validity and passes the request further to the Certificate Authority for certificate issuance.

  6. Download the issued certificate and add it to the organization's authorization server and resource server configuration.

Optionally, you can also view the Signing Key associated with the issued certificate in a form of a JWKS.

Publish APIs for Data Receivers to Discover​

  1. Select Servers and choose one of the available authorization servers for which you wish to publish the APIs.

  2. Select API Resources > New API Resource.

  3. Select the API Family Type available within your ecosystem and its Version.

  4. Provide a Start date configuring when your APIs start to be available for the Data Receivers to integrate with.

  5. Provide the Certification URI if required.

    The requirement for providing the certification URI can behave in the two following ways:

    • If the ecosystem has the automatic API certification process available, the conformance tests run for the APIs.

    • If the ecosystem does not have the automatic API certification process available, you need to provide a valid certification URI serving as a proof that your APIs are implemented according to the required standard.

  6. Select Save.

  7. Expand the dropdown next to the APIs you added and add API Discovery Endpoints.

    By adding API Discovery endpoints, you can provide a base URL for the API and the rest is automatically filled in according to the requirements for the given API that come from your trust framework. Such requirements are defined by the Trust Framework Participants and their Data APIs profile.

  8. Provide the API Base URL and API Version and Generate Endpoints.

    Do not add a slash at the end of the base URL -- it is added automatically for you during the API Discovery. The API version is also automatically appended into the resulting API endpoint.

  9. Select all of the available discovered APIs or select the ones you want to publish and save.

Next Steps​

  1. Get Data from other organizations to enhance your services.

  2. Publish Authorisation Server Certification.

  3. Manage APIs for Discovery and Integration.

  4. Validate Certs in incoming requests.

  5. Manage Certificates

Open Book IconTABLE OF CONTENT