LogoLogo
ProductsCommunityGitHubShare Feedback
SSI Kit
SSI Kit
  • General
    • Introduction
    • Transition To The Community Stack
    • SSI Kit | Basics
      • Overview
      • Functionality
      • Components
    • SSI Kit
      • SSI Flavors & Ecosystems
        • Trust Registries
        • Keys
        • Decentralized Identifiers (DIDs)
        • Verifiable Credentials (VCs)
        • Data Exchange Protocols
      • Architecture
        • Low-Level Service Abstraction
        • Ecosystem Abstraction
        • High-Level Interfaces / APIs
      • Use Cases
      • Self-Sovereign Identity (SSI)
        • SSI | Basics
        • Technologies & Concepts
          • Registries
          • Decentralised Identifiers (DIDs)
          • Verifiable Credentials (VCs)
          • Verifiable Presentations (VPs)
          • Data Exchange (Protocols)
  • Getting started
    • Quick Start
    • REST API
      • Signatory API - For Issuers
      • Custodian API - For Holders
        • Key management
        • Did management
        • Credentials management
      • Auditor API - For Verifiers
      • Core API
        • Cryptographic keys
        • Decentralised-Identifiers
        • Verifiable-Credentials
      • API Serving Configs
    • Dependency (JVM)
      • Java Examples
      • Kotlin Examples
    • CLI | Command Line Interface
      • Key Management
      • Decentralized Identifiers
      • Verifiable Credentials
      • OpenID Connect (OIDC)
    • Building the Project
      • Docker Build
      • Local Build
    • Project Configurations
    • Demo
  • Ecosystems
    • EBSI
      • Basics
      • Use Cases & Flow Diagrams
      • Command line interface
        • DID Registration
      • REST API
      • Usage / examples
        • Onboarding & DIDs
        • Build end-to-end use cases
    • IOTA
      • OIDC4VP profile for Login-with-IOTA
      • Login With IOTA Demo
    • Velocity
      • Basics
        • Onboarding
        • Issuing
        • Inspection
      • Integration with SSIKit
      • Command line interface
        • Onboarding
        • Issuing
        • Inspection
    • cheqd
      • Integration architecture
      • Create DID
      • Issue VC
      • Verify VC
  • Tutorials
    • My First VC
    • Advanced VC
  • Concepts
    • Credential Templates
    • Verification Policies
      • Static Policies
      • Parameterized Policies
      • Dynamic/Custom Policies
        • Creating Dynamic Policies
        • Using Dynamic Policies
        • Removing Dynamic Policies
        • Dynamic Policies | Data Classes
    • Selective Disclosure
      • Intro
      • Issuing a SD-JWT Credential
      • Verifying a SD-JWT Credential
    • Credential Statuses
      • StatusList2021Entry
      • SimpleCredentialStatus2022
      • Issue credentials with credentialStatus
      • REST API
        • Check the status of a credential
        • Revoke a credential
      • CLI
        • Check the status of a credential
        • Revoke a credential
    • DID Web
    • Open Policy Agent (OPA)
      • Setup
    • OpenID Connect (OIDC)
      • Credential Issuance
        • OIDC4CI | Example
      • Presentation Exchange
        • OIDC4VP | Example
    • Delegation and Mandates
  • Community
    • Discord
    • Twitter
    • Newsletter
    • GitHub Discussions
  • DEVELOPER RELATIONS
    • Contribute
    • Roadmap
    • Share Feedback
    • Contact
  • Product Editions
    • Open Source | Always Free
    • Enterprise | Self-Managed
    • Cloud Platform | Managed
Powered by GitBook
On this page

Was this helpful?

Export as PDF
  1. Ecosystems
  2. Velocity
  3. Basics

Inspection

PreviousIssuingNextIntegration with SSIKit

Last updated 1 month ago

Was this helpful?

The verification process (inspection) is initiated by disclosure exchanges where the Relying Party requests credentials from Holder. These exchanges can be encoded in the following ways:

  • deep links - a URI that matches the spec:

  • QR-codes - a visual representation of a deep link

Depending on the use case, the Relying Party can request either:

  • verified credentials

    • requires payment in tokens

    • returns the verification checks (policies) result

  • unverified credentials:

    • requires no payment in tokens

    • can be verified later

Verification policies

The verification checks performed against the credential are the following:

  • UNTAMPERED

    • pass - hasn't been tampered

    • fail - has been tampered

    • voucher_reserve_exhausted - a voucher is required for verification

  • TRUSTED_ISSUER

    • pass - issuer is trusted

    • fail - issuer is not a member of Velocity

    • self_signed - data attested by the Holder

    • voucher_reserve_exhausted - a voucher is required for verification

  • UNREVOKED

    • pass - hasn't been revoked

    • has been revoked

    • voucher_reserve_exhausted - a voucher is required for verification

  • UNEXPIRED

    • pass - hasn't expired

    • fail - has expired

More details on credential verification checks can be found at https://docs.velocitynetwork.foundation/docs/developers/developers-guide-disclosure-exchange#credential-verification-checks.

More on credential verification at https://docs.velocitynetwork.foundation/docs/developers/developers-guide-disclosure-exchange.

velocity-network://inspect?request_uri=[REQUEST_URI]&inspectorDid=[INSPECTOR_DID]&vendorOriginContext=[VENDOR_ORIGIN_CONTEXT]