Partner access to shared services

Overview

Government and large enterprises can give partner organizations controlled access to shared services using Verifiable Credentials that prove role, scope, and authority.

The shared service does not need a bespoke integration for every partner identity system. It needs to verify that the presenting person has current authority from an accepted partner or host agency.

Why it matters

Partner access is often negotiated manually and stitched into systems one by one. Each new partner can introduce duplicated onboarding, static allow lists, and difficult offboarding.

Verifiable Credentials create a cleaner model:

• the host agency or accredited partner issues role and scope credentials
• partner staff present credentials at the point of access
• the service verifies issuer trust, scope, and status
• access can be time-bound, auditable, and revoked without rewriting every integration

Ecosystem roles

• Issuer: The host agency or enterprise issuing partner authority credentials.
• Holder: Partner staff who need access.
• Verifier: The service or platform granting access.
• Partner organization: The organization whose staff require delegated or federated access.
• Trust governance: The accreditation, issuer trust, scope, and revocation rules for the partner ecosystem.

Trust decision

The verifier decision is narrow: can this partner staff member access this shared service for this purpose right now?

That decision may depend on partner accreditation, staff role, scope, expiry, service sensitivity, and current credential status.

Privacy and assurance

The verifier should request only the partner authority and role claims needed for the service. It should not need to import the partner’s whole user profile or employment record.

Assurance depends on checking issuer trust, credential status, scope, expiry, and whether the service action is allowed by the credential and local policy.

Implementation notes

• Separate partner accreditation from individual staff authority where the lifecycle differs.
• Define role and scope claims in a way services can enforce consistently.
• Record access decisions with enough detail for audit and incident response.
• Include rapid revocation paths for partner offboarding, contract changes, and compromised accounts.

Objective

Allow approved partners to access shared services.

Description

Issue role and scope credentials to partner staff and verify them at access time.

Actors

Host agency or enterprise; partner organization; partner staff; shared service verifier.

Dependencies

Partner accreditation rules, issuer trust registry, role and scope credential schemas, status endpoint, and service access policy.

Preconditions

The partner organization is accredited and the staff member holds a current authority credential.

Postconditions

Access is granted, denied, or escalated within defined scope and time.

flowchart LR
    HOST@{icon: "tabler:building-bank", label: "Host agency", pos: "b"} -->|Issues partner VC| WAL@{icon: "tabler:wallet", label: "Wallet", pos: "b"}
    REG@{icon: "tabler:book", label: "Trust registry", pos: "b"} -->|Publishes issuer trust| VER@{icon: "tabler:id-badge", label: "Access service", pos: "b"}
    WAL -->|Present VC| VER
    VER -->|Grant scoped access| SYS@{icon: "tabler:server", label: "Shared service", pos: "b"}

sequenceDiagram
    participant Host as Host agency
    participant Wallet
    participant Partner as Partner staff
    participant Verifier as Access service
    participant Registry as Trust registry

    Host-->>Wallet: Issue partner authority VC
    Partner->>Verifier: Present VC
    Verifier->>Registry: Validate issuer, scope, status
    Registry-->>Verifier: Valid
    Verifier-->>Partner: Access granted