Portal Roles and Permissions
The Verification portal uses a role-based access control model to scope what each team member can do across your organization and projects. This page describes the four roles, the two project-level permissions, and the rules that govern who can grant access to others.
Roles
There are four roles. Think of them as access tiers — each one is strictly more powerful than the one below it.
org.owner
Full access to everything in the organization: edit organization details, manage keys and certificates, create and delete projects, invite and remove users, assign any role. Only org.owner can delete users from the organization or edit organization-level settings.
org.projects
Nearly identical to org.owner, with three exceptions:
Cannot edit organization details
Cannot delete users from the organization
Can only assign the
project.managerrole to others — notorg.ownerororg.projects
project.manager
Scoped to the specific projects they've been assigned to. A project manager with no project assignments can't see or do anything. What they can do within an assigned project depends on which of the two project-level permissions they hold — see Project Manager Permissions.
tl.admin
Manages trust lists: the directories of public keys registered on the trust registry. Within the areas covered on this page, tl.admin has limited read access — they can view the organization and see which projects a user belongs to, but cannot take action on projects, verification rules, or users.
Project Manager Permissions
The project.manager role does nothing on its own. It requires one of two permissions, assigned per project. A project manager can hold different permissions in different projects — or no permissions at all in a project they haven't been assigned to.
admin_project_child — Project Admin
Full control over the assigned project:
Edit project settings
View and manage project users
Create, edit, and delete verification rules
Accept and reject verifiers
Upload verifiers in bulk
Manage benefits
View verification history
manage_project_pov_verifiers — Verification Rule Manager
Day-to-day management of verifiers within a project's verification rules:
View verification rules and their details
Accept and reject verifiers
Upload verifiers in bulk
This permission does not allow creating, editing, or deleting verification rules, and does not provide access to benefits or verification history.
Example: Ana is a project.manager.
In Project Alpha she has
admin_project_child→ she can do everything in Alpha, including creating and editing verification rules.In Project Beta she has
manage_project_pov_verifiers→ she can accept and reject verifiers in Beta, nothing else.In Project Gamma she has no assignment → she can't see Gamma at all.
If a project manager holds both permissions on the same project, admin_project_child takes full effect and manage_project_pov_verifiers is redundant.
Access Matrix
Organization
View organization
✅
✅
✅
Edit organization
✅
❌
❌
View organization keys
✅
✅
❌
Renew organization key
✅
✅
❌
View certificates
✅
✅
❌
Projects
List projects
✅ all
✅ all
✅ assigned only
✅ assigned only
View project detail
✅
✅
✅
✅
Create project
✅
✅
❌
❌
Edit project
✅
✅
✅
❌
Delete project
✅
✅
❌
❌
View project users
✅
✅
✅
❌
View approver credentials
✅
✅
✅
❌
Adding or removing users from a project is done through the organization user management area, not from the project view directly. A project manager with admin_project_child can assign users to their projects from that section.
Benefits
List benefits
✅
✅
✅
❌
View benefit detail
✅
✅
✅
❌
Create benefit
✅
✅
✅
❌
Edit benefit
✅
✅
✅
❌
Delete benefit
✅
✅
✅
❌
Verification Rules
List verification rules
✅
✅
✅
✅
View verification rule detail
✅
✅
✅
✅
View verifiers on a rule
✅
✅
✅
✅
Accept verifier
✅
✅
✅
✅
Reject verifier
✅
✅
✅
✅
Upload verifiers in bulk
✅
✅
✅
✅
Create verification rule
✅
✅
✅
❌
Edit verification rule
✅
✅
✅
❌
Delete verification rule
✅
✅
✅
❌
View verification history
✅
✅
✅
❌
Organization Users
List organization users
✅
✅
✅
✅
View user detail
✅
✅
✅
✅
View user's projects
✅
✅
✅
✅
Edit user
✅
✅
❌
❌
Remove user from organization
✅
❌
❌
❌
Add user to organization
✅
✅ ¹
✅ ¹
❌
Assign role to user
✅
✅ ¹
✅ ¹
❌
Remove role from user
✅
✅ ¹
✅ ¹
❌
Revoke permission from user
✅
✅
✅
❌
¹ Subject to privilege escalation rules — see Privilege Escalation Rules.
Privilege Escalation Rules
No role can grant more access than it holds. The system enforces this at the API level: attempts to assign a higher role or permission are rejected regardless of how the request is made.
org.owner
Any role
Any permission
org.projects
project.manager only
Any project permission
project.manager (admin)
project.manager only, in projects where they hold admin_project_child
manage_project_pov_verifiers only — cannot grant admin_project_child to others
project.manager (verif. manager)
No one
Nothing
Example: Carlos is org.projects. He tries to promote another user to org.owner. The system rejects this — org.projects cannot assign a role above its own level.
Example: Sofia is a project.manager with admin_project_child in Project Alpha. She can add another user as project.manager with manage_project_pov_verifiers in Project Alpha. She cannot grant them admin_project_child, and she cannot make assignments in any project where she herself has no active permission.
Verification Rules and Assurance Tiers
Who can manage a verification rule is separate from what the rule does. The role model controls access; the rule itself controls the security level of each verification flow.
When a user with admin_project_child or higher creates a verification rule, they configure:
What credentials to request — the credential type and the specific claims to ask for
What assurance tier to require — Basic, Standard, or Premium — which determines what validation and attestation evidence Blerify collects during the verification
Which wallets to accept — only wallets from Blerify's certified registry are available
Transport policy — whether to require DC-API (with proximity enforcement) or accept a QR fallback
Users with only manage_project_pov_verifiers can accept and reject verifiers against existing rules, but they cannot change any of these settings. This separation is intentional: the security parameters of a rule are a policy decision; day-to-day verifier onboarding is an operational one.
For a full explanation of how assurance tiers map to validation guarantees, see Assurance Tiers.
Frequently Asked Questions
Can a project manager see projects they haven't been assigned to?
No. The system automatically filters the project list to show only projects where they have an active permission. There is no way to browse projects outside their assignments.
Who can delete a project?
Only org.owner and org.projects. No project manager can delete a project regardless of their permissions.
Who can delete a user from the organization?
Only org.owner. This action is not available to any other role.
What happens if a project manager has both permissions on the same project?
admin_project_child takes full effect. manage_project_pov_verifiers is redundant in that project since admin already includes everything the verifier manager permission allows.
Can a project manager create new projects?
No. Creating projects is restricted to org.owner and org.projects.
Can a project manager change the assurance tier on a verification rule?
Yes, if they hold admin_project_child on that project. manage_project_pov_verifiers does not allow editing verification rules — only managing the verifiers attached to them.
Next steps
Continue to Assurance Tiers — what each tier proves and how to configure one in a verification rule.
See also: Get Started with Verification · API Reference
Last updated