Schemas
The did-auth library uses a set of robust schemas, built with Joi, to validate the structure and data types of configuration and request objects. This ensures that communication between your application and the user's wallet is reliable and predictable. This guide provides a comprehensive reference for the appInfo, chainInfo, and all supported claim type schemas.
appInfo Schema#
The appInfo object describes your application to the DID Wallet, which typically displays this information to the user for confirmation. It helps users understand which application is requesting their information.
Field | Type | Required | Description |
|---|---|---|---|
| string | Yes | The name of your application. |
| string | Yes | A brief description of your application. |
| string (URI) | Yes | A URL to your application's icon. Must be an |
| string (URI) | No | A URL to your application's homepage. |
| string (URI) | No | The base URL for the wallet to display when linking back. Defaults to |
| string (DID) | No | The DID of the application publisher. |
| boolean | No | Flag to indicate if the subscription endpoint should be updated. |
| string | No | The endpoint for subscription updates. |
| string (DID) | No | The DID of the node associated with the application. |
| string (DID) | No | The DID of the agent handling requests. |
Example appInfo Object
{
"name": "My Awesome App",
"description": "This app demonstrates DID authentication.",
"icon": "https://myapp.com/icon.png",
"link": "https://myapp.com",
"publisher": "z1S...ApplicationPublisherDID...s9B"
}chainInfo Schema#
The chainInfo object specifies the blockchain context for an authentication request. This is crucial for multi-chain applications, as it tells the wallet which network to target for operations like transaction signing or asset verification.
Field | Type | Default | Description |
|---|---|---|---|
| string |
| The type of blockchain. Supported values: |
| string |
| The chain ID. For |
| string |
| The endpoint of the chain's RPC/API. For |
Schema Logic
- If no
chainInfois provided, it defaults to{ "type": "arcblock", "id": "none", "host": "none" }. - For
ethereumandsolonatypes, theidfield is required and must be a numeric string.
Example Configurations
// Default (ArcBlock)
{
"type": "arcblock",
"id": "beta",
"host": "https://beta.abtnetwork.io/api/"
}
// Ethereum Mainnet
{
"type": "ethereum",
"id": "1",
"host": "https://mainnet.infura.io/v3/YOUR_PROJECT_ID"
}
// Solana Mainnet
{
"type": "solona",
"id": "101",
"host": "https://api.mainnet-beta.solana.com"
}claims Schemas#
Claims define the specific information or actions you are requesting from the user's wallet. You can request one or more claims in a single authentication request. Each claim object must include a type field that specifies the kind of claim.
Common Fields#
All claim types share a set of common fields that are added by the createStandardFields factory function.
Field | Description |
|---|---|
| The type of the claim (e.g., 'profile', 'signature'). |
| A human-readable text displayed to the user in the wallet. |
| An optional |
| An optional field to pass any extra metadata. Defaults to |
authPrincipal#
Requests the user to select an account (DID) from their wallet to authenticate and continue.
Field | Type | Default | Description |
|---|---|---|---|
| string (DID) |
| Suggest a specific DID for the user to select. |
| boolean |
| Indicates if the requested DID should be supervised (e.g., a child account). |
| object |
| Specifies the cryptographic properties (key, hash, role, encoding) of the desired DID. |
Example authPrincipal Claim
{
"type": "authPrincipal",
"description": "Please select your main account to sign in."
}profile#
Requests specific pieces of profile information associated with the user's DID.
Field | Type | Default | Description |
|---|---|---|---|
| array of strings |
| An array specifying the profile items to request. The property was previously named |
Available items did, fullName, email, phone, signature, avatar, birthday, url
Example profile Claim
{
"type": "profile",
"description": "Please share your name and email to create an account.",
"items": ["fullName", "email"]
}signature#
Requests the user to sign a piece of data, such as a message, transaction, or delegation.
Field | Type | Required | Description |
|---|---|---|---|
| string | Yes | Specifies the type of data being signed. Determines how the wallet interprets and displays the data. See valid values below. |
| string | No | A human-readable string representation of the data to be signed. |
| string | No | The hashing algorithm to use before signing. Defaults to |
| string | No | The pre-computed digest of the data to be signed. |
| string | No | The origin URL of the request, for display and security purposes. |
| string | No | A nonce to prevent replay attacks. |
| object | No | Specifies token or asset requirements the user must meet to perform the signature. |
Valid typeUrl Values
fg:x:delegationfg:t:transactionmime:text/plainmime:text/htmleth:transactioneth:standard-dataeth:personal-dataeth:typed-dataeth:legacy-data
Example signature Claim
{
"type": "signature",
"description": "Sign this message to confirm your agreement.",
"typeUrl": "mime:text/plain",
"display": "I agree to the terms and conditions of service.",
"method": "sha3"
}verifiableCredential#
Requests the user to present one or more Verifiable Credentials (VCs) that match specified criteria.
Field | Type | Default | Description |
|---|---|---|---|
| boolean |
| If true, the user can skip this step. |
| array of objects |
| An array of filter objects. The user must provide a VC that matches at least one ( |
Filter Object Properties All properties within a single filter object are combined with an AND condition.
Field | Type | Description |
|---|---|---|
| array of strings | An array of acceptable VC type schemas. |
| string (DID) | A specific VC DID to request. |
| array | An array of trusted issuer DIDs. See format below. |
| string | A tag to match against the VC's metadata. |
| array of DIDs | An array of acceptable owner DIDs. |
| string (URI) | A URL where the credential proof can be submitted or verified. |
| string (URI) | A URL where the user can acquire the required credential if they don't have it. |
trustedIssuers Format An item in the trustedIssuers array can be either a DID string or an object containing the issuer's DID and endpoint.
Example verifiableCredential Claim This example requests a Certificate VC issued by either of two trusted issuers.
{
"type": "verifiableCredential",
"description": "Please present your certificate to access the course material.",
"filters": [
{
"type": ["Certificate"],
"trustedIssuers": [
"z1Tp3bGid5Kwc1NygaBPdVVg6BuhJagF2G4",
{
"did": "z1nUziGm98Rigq2ZoRQNyHd4Xw1KkVKCWE6",
"endpoint": "https://arcblock.io"
}
]
}
]
}asset#
Requests the user to present a non-fungible asset (NFT) that matches specific criteria. The structure is very similar to the verifiableCredential claim.
Field | Type | Default | Description |
|---|---|---|---|
| boolean |
| If true, the user can skip this step. |
| array of objects |
| An array of filter objects. The user must provide an asset that matches at least one ( |
Filter Object Properties All properties within a single filter object are combined with an AND condition.
Field | Type | Description |
|---|---|---|
| string (DID) | The contract address of the asset. |
| array | An array of trusted issuer DIDs. |
| array of DIDs | An array of trusted parent collection DIDs. |
| string | A tag to match against the asset's metadata. |
| array of DIDs | An array of acceptable owner DIDs. |
| boolean | Whether to request a consumed or unconsumed asset. |
| string (URI) | A URL where the user can acquire the required asset. |
Example asset Claim
{
"type": "asset",
"description": "Please present your event ticket to enter.",
"filters": [
{
"trustedParents": ["z82...TicketCollectionDID...wT7"],
"consumed": false
}
]
}Other Claim Types#
Claim Type | Description |
|---|---|
| Requests the user to agree to a document (e.g., Terms of Service) by confirming a hash of the document's content. |
| Asks the wallet to prepare a transaction for signing, often used when the dApp needs the wallet to contribute some information to the transaction before the user signs it. |
| A flexible claim that allows requesting either an asset or a verifiable credential that matches the given filter criteria. |
| Requests the wallet to generate a new key pair (a new DID). Useful for account creation flows. |
| Requests the wallet to derive an encryption key from the user's secret key and a provided salt. Used for establishing an encrypted communication channel. |
For more specific examples and advanced use cases, you can review the library's source code and tests. A good next step is to see how these schemas are used in practice by reviewing the Testing guide.