Roles

Benefit from the hierarchical structure of a Trust Framework. Get assigned regulatory roles that govern the classification for your organisation, API access, available access scopes, and more.

---

Roles are regulatory roles associated with a specific Domain. They can dictate what rights and permissions your organisation has, such as the ability to register certain APIs or specific types of servers. Roles can also define the set of APIs an organisation can consume and access scope its application can request.

For example, if an organisation is assigned a role defined in the Open Banking Domain, it is able to publish or access the finance-related APIs but not health-related APIs.

Roles help to distinguish between different organisations by being a mean of classification. They can differentiate Data Providers from Data Receivers, or common organisations and technical service providers.

Additionally, roles are used to control access to Raidiam Connect APIs. By default, any organisation and their application registered in Connect is assigned a role enabling access to application- and software-statement- related APIs.

Organisations are assigned roles by Trust Framework Administrators only and cannot be self-assigned by Organisation Administrators. However, you can control which role is available to your application. If you register more than one application, it is recommend only to claim the roles the application needs within its Software Statement.

note

If your organisation does not have any Domain Role assigned, contact with your Trust Framework Administrator.

Role Metadata

Trust Framework Administrators have the ability to link specific Roles to technical authorisations within applications. This process involves associating these roles with technical OAuth scopes and grant types.

Each Role can be associated with specific OAuth metadata types, dictating the permissions and access levels within the role.

Example Application

In the Open Banking Domain, the PISP (Payment Initiation Service Provider) role might be linked with OAuth scopes like openid and payments, and an OAuth grant type of authorization_code. This linkage defines the technical permissions and capabilities associated with the role.

Here is a table detailing various examples of how Roles are linked with specific technical metadata:

Domain	Role	Technical Metadata Type	Technical Metadata Value
PSD2	PISP	scope	openid payments
PSD2	PISP	grant_type	authorization_code
Open Banking	DADOS	response_type	code id_token
Retail Banking	Data Provider	scope	make:payments
Commercial Banking	Data Receiver	grant_type	authorization_code

1. Scope (PSD2 - PISP)

   • The openid payments scope allows the PISP role to access open banking identity and payment services within the PSD2 framework.

2. Grant Type (PSD2 - PISP)

   • The authorization_code grant type is used for obtaining an authorization code as part of the authentication process.

3. Response Type (Open Banking - DADOS)

   • The code id_token response type specifies that the application will receive an authorization code and an ID token upon successful authentication.

4. Scope (Retail Banking - Data Provider)

   • The make:payments scope enables the Data Provider role in Retail Banking to initiate payment transactions.

5. Grant Type (Commercial Banking - Data Receiver)

   • Similar to the PSD2's PISP role, the authorization_code grant type in Commercial Banking facilitates the authorization process for data receivers.