Self Service Portal

The MATTR Self Service Portal (SSP) is built on top of MATTR VII APIs and provides an easy-to-use interface to effectively manage and oversee tenant management and configuration.

Roles and permissions

The SSP is designed to be used by different roles within an organization. The SSP UI is aligned with the user’s role and the permissions assigned to them. This means that users will only see the features and functionalities that are relevant to their role. Refer to Access control for more information on available roles and associated permissions.

Tenant-centric experience

Every action in the SSP happens within the context of a specific tenant. Tenants represent distinct instances of MATTR VII, each with its own configuration, credentials, and governance. When you sign in to the SSP, you can easily switch between all the tenants you have access to, enabling streamlined oversight without compromising clarity or security.

How to gain access to a tenant

There are two primary ways to gain access to managing a tenant in the SSP:

1. You create a tenant: When you create a tenant, you are automatically assigned the tenant’s admin role. This gives you full privileges within that tenant, including the ability to configure settings, issue credentials, and manage user access.

2. You’re invited to manage a tenant: Another user with sufficient privileges can invite you to manage a tenant they control. In this case:

   • You are assigned a specific role as part of the invitation.
   • Your permissions in that tenant are determined by the role you’re given—limiting or enabling specific actions according to that scope.
   • You can work across multiple tenants, each with different roles depending on how you’ve been invited.

Inviting other users

Just as you can be invited to a tenant, you can also invite others to manage tenants that you administer. When you invite someone:

• You select the role they will hold within that tenant.
• This role defines what they can view, modify, or manage—ensuring fine-grained access control that aligns with your trust and governance requirements.
• If the invited user already has access to the SSP, they will immediately see the new tenant in their list of accessible tenants.
• If they do not have access to the SSP, they will receive an email invitation with login instructions.

Capabilities

The SSP currently supports the following functionalities:

• Platform management: Manage your MATTR VII tenants:
  • Tenant management: Create, view and delete tenants. This capability is based on the Management APIs.
  • Users, clients & roles: Manage users and clients for your tenants. These capabilities are based on the Clients and Members endpoints in the Management API.
  • Custom domain: Configure a Custom domain for the selected tenant. This capability is based on configuring a Custom domain using an API request and verifying the Custom domain using an API request.
  • Monitoring: Query and inspect analytic events in your environment. This capability is based on the Analytic APIs.
  • Webhooks: Create a Webhook to subscribe to events. Available options are similar to those described for creating a Webhook using an API request.
  • DIDs: View Decentralized Identifiers (DIDs) available on your tenant. This includes any did:key and/or did:web available on your tenant. Note that you cannot use the SSP to create DIDs.
  • Certificates: Manage IACAs on your tenant. This includes creating new IACAs as well as viewing and deleting existing ones.
• Ecosystem: Manage your Ecosystem:
  • Create and manage participants.
  • Create and manage credential types.
  • Publish the Ecosystem’s policy.
• Credential issuance: Manage OID4VCI workflow components and configuration:
  • Authentication provider: Configure and edit an authentication provider to be used during credential issuance flows. Available options are similar to those described for configuring an Authentication provider using an API request.
  • Interaction hook: Configure an interaction hook to redirect a user to a custom component during the credential issuance journey. Available options are similar to those described for configuring an Interaction hook using an API request.
  • Claims sources: Configure and edit claims sources to fetch claims from an external endpoint and use them when issuing credentials. Available options are similar to those described for configuring a Claims source using an API request.
  • Credential configurations: Create a CWT, Semantic CWT, JSON and mDocs credentials configurations. Available options are similar to those described for creating a Credential configuration using an API request.
  • Credential offer: Create a credential offer by specifying credential configurations and request parameters. This capability is based on creating a Credential offer using an API request, with some additional capabilities to share the offer with the intended holder.
• Credential verification: Configure mDocs online verification workflows:
  • Trusted issuers: Configure and manage mDocs issuers that can be trusted when verifying mDocs presented online. Available options are similar to those described for creating a trusted issuer using an API request.
  • Supported wallets: Configure and manage digital wallet applications that can present mDocs online for verification, and how to interact with these wallets. Available options are similar to those described for creating a wallet provider using an API request.
  • Applications: Configure and manage applications that can create mDocs online verification sessions, and how to interact with these applications. Available options are similar to those described for creating a verifier application using an API request.

Additional resources

Tutorials

Guides