Authorisation Server under Service Provider

Delegating Authentication in Data Sharing

Authentication is a fundamental element of trust in data sharing. As previously mentioned, in the iSHARE Trust Framework, this is achieved through dynamic, certificate-based mechanisms that remove the need for preregistration at each Service Provider. While effective, this approach requires every Service Provider to implement its own authentication endpoint. For some organisations, this can create operational challenges, increase maintenance effort, and raise the barrier to entry.

To address this, RFC051 introduced the option of delegating authentication to an Authorisation Server operating under the responsibility of the Service Provider. This article clarifies how such a role fits within the iSHARE Trust Framework and what it means for participants across the ecosystem.

Authorisation Servers in the iSHARE Trust Framework

The concept of an Authorisation Server is well established in OAuth 2.0. It is responsible for validating credentials and issuing bearer tokens that clients can present to access protected resources. Within iSHARE, the same principle can apply, but adapted to certificate-based authentication and the Participant Registry.

In this option, a Service Provider may rely on an Authorisation Server (sometimes also referred to as a Security Token Service, STS) within its trusted zone. The Authorisation Server validates client assertions, checks the certificate against the iSHARE Participant Registry, and issues an access token. The Service Provider then accepts this token as proof of authentication, reducing the need to implement these steps directly.

From the perspective of the Service Consumer, the process remains unchanged. It generates a signed client assertion with its certificate and submits this to the Service Provider’s /token endpoint. What happens next differs: rather than the Service Provider validating everything itself, it forwards the assertion to its Authorisation Server. The Authorisation Server performs the cryptographic checks, validates the certificate against the Participant Registry, and exchanges its own client assertion with the Registry to confirm the Service Consumer’s details and compliance. Only once this chain of validation succeeds does the Service Provider receive a bearer token that it can safely issue to the Service Consumer.

The diagram below illustrates this end-to-end flow in a machine-to-machine (M2M) scenario, showing the interactions between the Service Consumer, Service Provider, Authorisation Server, and the iSHARE Participant Registry.

Figure 1: iSHARE Authentication flow with Authorisation Server under SP - M2M

This separation of responsibilities allows Service Providers to rely on specialised, standards-based infrastructure for token issuance and validation, while preserving iSHARE’s decentralised trust model.

Benefits and Implications

Delegating authentication to an Authorisation Server offers significant advantages. First, it lowers the complexity for Service Providers. Instead of maintaining custom implementations of the /token endpoint, they can make use of an Authorisation Server that is already configured to handle JWT-based client assertions and certificate validation. This reduces the risks of errors and ensures a more consistent security posture.

Second, the Authorisation Server role is transparent to other participants in the ecosystem. From the outside, nothing changes: the Service Consumer interacts with the Service Provider as before, unaware that the Service Provider is relying on an Authorisation Server internally. This means no additional coordination or onboarding is needed with other parties.

Third, this option creates flexibility in how Service Providers adopt iSHARE. They can choose to run their own Authorisation Server, or contract a third party to provide one, as long as it is iSHARE-compliant. In such cases, the Service Provider and the Authorisation Server provider bilaterally agree on service conditions, but the Service Provider remains fully responsible within the iSHARE framework.

Fourth, using an Authorisation Server under the Service Provider role preserves the neutrality of the Participant Registry. Unlike other models where the Participant Registry would act itself as the central token service, this option avoids introducing additional liabilities or centralisation at the registry level. This keeps iSHARE aligned with its decentralised design principles.

Finally, Authorisation Servers may also act as bridges between different data spaces. By verifying assertions and issuing tokens across boundaries, they can enable interoperability without requiring every Service Provider to directly manage cross-space authentication. In some scenarios, privacy may even improve. Since the Service Consumer interacts only with the Service Provider, details of its activities may not be directly visible to other infrastructure components.

These benefits come with clear boundaries: accountability does not shift. Service Providers remain responsible for the authentication processes they rely on, even if they delegate the technical implementation to an Authorisation Server. They must ensure that certificate validation against the Participant Registry is correctly performed, and that the Authorisation Server operates within agreed compliance levels.

Maintaining Alignment with Standards

Introducing an Authorisation Server under the Service Provider role brings iSHARE even closer to mainstream OAuth practices while retaining its distinct approach to decentralised trust. By leveraging RFC 7521 and RFC 7523, Service Providers can configure existing identity and access management tools to support iSHARE’s certificate-based model. This creates opportunities to scale implementations more efficiently while maintaining full compliance with the Trust Framework.

A Continued Commitment to Secure Data Sharing

The approval of RFC051 confirms that using an Authorisation Server under the Service Provider role is fully compatible with iSHARE principles. It is not a replacement for iSHARE’s existing model but an option that participants can adopt to reduce complexity and improve alignment with OAuth standards depending on the specific use-case scenario. This clarification reflects once again iSHARE’s ongoing commitment to lowering entry barriers, supporting flexible implementation choices, and maintaining a robust foundation for trusted data sharing.