In order to operate on Velocity network, any entity (regardless of scope - issuer, relying party or credential agent operator) has to register with the network.
The onboarding is currently done manually and will custody a DID on the DID:ION network:
get an account with the registrar
by sending an email to support@velocitynetwork.foundation
set up the organization(s)
set the required services according to the use case:
issuer - VlcCareerIssuer_v1
verifier - VlcInspector_v1
agent operator - VlcCredentialAgentOperator_v1
configure the tenants
add the required keys according to the use case:
issuer - ISSUING_METADATA
verifier - EXCHANGES
agent operator - DLT_TRANSACTIONS
The configuration steps from above can be completed either using:
or Rest API
More information on Velocity onboarding can be found at https://docs.velocitynetwork.foundation/docs/developers/developers-guide-getting-started.
This section describes the main steps required to interact with Velocity network:
Issuing involves an exchange between a Holder and an Issuer, by which the Holder receives a set of offers from the Issuer. Once the Holder accepts the offers, the Issuer converts them into verifiable credentials and supplies them to the Holder.
Depending on data source location and process initiating party, the following issuing types are supported:
custom - credential agent loads offers from itself as well as calling out webhooks
demand triggered - Holder initiates the credential claiming process
Issuer responds with the available credential offers according to Holder’s criteria
supply triggered - Issuer initiates the credential claiming process
offers are made available to the Holder using a notification mechanism by sending a deep-link or qr-code to claim the credentials
batch - credential agent loads offers only from itself
a specialized version of supply triggered custom issuing
More information on issuing can be found at https://docs.velocitynetwork.foundation/docs/developers/developers-guide-issuing.
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
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.