Concepts

A Scope represents a specific type of access to a protected Resource. Each Scope defines the boundaries of what a Client can do with the Resource. Each Scope name must be unique within a Resource.

For example, a banking Resource named accounts may define Scopes such as accounts.read and accounts.transfer. These Scopes define the operations a Client may request during authorization.

A Permission represents a unique combination of a Resource and one of its Scopes. Each Permission defines the specific actions and data access rights that can be granted to a Client. Permissions are the fundamental building blocks for authorization, determining what operations and data a Client can perform on behalf of a user.

For example, for a Native Application Client named Banking Mobile App a Permission may grant access to the accounts.transfer Scope of the accounts Resource. Permissions are granted to Clients and later evaluated against the User's Roles.

Contexts provide additional information for the MCP authorization requests beyond the basic Scope model. Each Context is represented as a key-value pair. Contexts enable the implementation of complex authorization scenarios by adding dimensionality to the Permission evaluation process.

While Scopes define what actions a Client may perform, Contexts define which subset of data or environment those actions apply to. Contexts can be used to represent dimensions such as organization, region, environment, or tenant.

For example, a banking application may include Contexts such as region=eu or account_type=business. Contexts allow authorization decisions to consider dimensions beyond the requested Scope.

Similar to Permission, a Context Visibility represents a unique combination of an MCP Server Resource and one of its Contexts. Context Visibility determines the complete set of Contexts a Client can access on behalf of a user.

For example, a Client may be allowed to access Contexts for region=eu while being restricted from accessing region=us. This mechanism helps prevent Clients from accessing contextual information outside their intended authorization boundaries.

Roles are authorization labels used during permission evaluation. In Mekarge A3, a Client does not receive Scopes or Contexts solely because they have been granted them. During authorization, Mekarge A3 Authorization Server evaluates the Roles associated with the User's current User Group and compares them with the Roles attached to the Client's granted Permissions and Context Visibility.

Only Permissions that share at least one Role with the User's current User Group become effective.

For example, the premium_customer Role may allow access to investment-related Permissions, while the standard_customer Role may only allow basic account operations.

The same logic applies to Context Visibility for MCP Host application Clients. During authorization, Mekarge A3 first evaluates the Permissions and Context Visibility granted to the Client. The Authorization Server then filters these entries using the Roles associated with the User’s current User Group. For Native Application Clients, additional filtering may be applied through Attestation Profiles and their Appraisals.

An Attestation Profile defines a set of Appraisal criteria for evaluating Device and Native application trustworthiness. These profiles can be used by Native application Clients needing enhanced security controls.

Similar to Roles, Attestation Profiles are associated with the Permissions. During authorization, Mekarge A3 Authorization Server evaluates all the Appraisals defined for the Attestation Profile and filters the Client's granted Permissions that are associated with the particular Attestation Profile.

For example, a financial application handling money transfers may require an Attestation Profile that validates device integrity and verifies that the application is running on an authentic, non-tampered device. Less sensitive operations, such as viewing public financial information, may not require Attestation evaluation.

Appraisals are the basic blocks of trust evaluation within the Mekarge A3 Authorization Server. Each appraisal consists of:

• An overall status (i.e. Affirming)
• A Trustworthiness Vector that defines the evaluation criteria

The elements of Trustworthiness Vector, Trustworthiness Claims specify the particular Device and Native Application's attributes being evaluated.

For example, an Appraisal may require that the device is not rooted, the application signature is valid, and the operating system satisfies minimum integrity requirements. Multiple Appraisals can be combined within a single Attestation Profile.

Data Sources are logical repositories where user information is stored and managed. Each Client requiring user authentication must be configured to use a Data Source. This abstraction allows for flexible integration with existing identity systems.

A UI Collection aggregates multiple Web Components into a cohesive user interface package. UI Collections are used by Clients requiring user authentication and provide a complete set of user interface elements needed for the authentication process.

Web Components are the building blocks of user interfaces for the Client applications that require end user interaction. Web Components are designed to be responsive across different screen sizes. Each Web Component is localized for a single Locale.