Advanced Issuer Node configuration
This guide will show you how to configure your Issuer Node.
*Polygon Mumbai testnet has been deprecated
Revocation Status
The revocation status is a core part of the credential, as it is the verifier's way of checking whether or not a credential has been revoked by the issuer. The Issuer Node offers three different ways to check the revocation status of a credential:
Centralized
: The verifier or user will check the credential revocation status through the Issuer Node itself, which is why we consider it to be a centralized method. If the node is not available, the verification will fail, resulting in possible errors when trying to generate ZK Proofs.RHS Off Chain
: In this case, the credential revocation will be checked in a server independent from the Issuer Node (managed by the Issuer or an independent agent), so that we no longer depend on the Issuer Node as the only point of failure. This service will be a fallback in case the RHS is not available.RHS On Chain
: This method can be considered as completely decentralized since the RHS is on chain, therefore the user or verifier will check the status of a credential via this decentralized on chain service without depending on a centralized server. This is the desirable option.
Centralized (default)
In this case we will have to make sure that the Issuer Node is publicly accessible.
Core API:
.env-issuer
ISSUER_CREDENTIAL_STATUS_RHS_MODE=None
ISSUER_SERVER_URL={Set a publicly accessible URL for the same $ISSUER_SERVER_PORT}
UI:
.env-api
ISSUER_API_UI_SERVER_URL={Set a publicly accessible URL for the same $ISSUER_API_UI_SERVER_PORT}
RHS Off Chain
For the RHS Off Chain, there are two options:
- Use an RHS from a reliable entity.
- Install your own RHS; you can do it with the following guide: Configure your own RHS
Once you have your publicly accessible RHS URL:
.env-issuer
ISSUER_CREDENTIAL_STATUS_RHS_MODE=OffChain
ISSUER_CREDENTIAL_STATUS_RHS_URL={RHS publicly accessible URL}
RHS On Chain
.env-issuer
ISSUER_CREDENTIAL_STATUS_RHS_MODE=OnChain
- Polygon Amoy
- Polygon Main
- Polygon Mumbai*
ISSUER_CREDENTIAL_STATUS_ONCHAIN_TREE_STORE_SUPPORTED_CONTRACT=0x3d3763eC0a50CE1AdF83d0b5D99FBE0e3fEB43fb
ISSUER_CREDENTIAL_STATUS_RHS_CHAIN_ID=80002
ISSUER_CREDENTIAL_STATUS_ONCHAIN_TREE_STORE_SUPPORTED_CONTRACT=0xbEeB6bB53504E8C872023451fd0D23BeF01d320B
ISSUER_CREDENTIAL_STATUS_RHS_CHAIN_ID=137
ISSUER_CREDENTIAL_STATUS_ONCHAIN_TREE_STORE_SUPPORTED_CONTRACT=0x16A1ae4c460C0a42f0a87e69c526c61599B28BC9
ISSUER_CREDENTIAL_STATUS_RHS_CHAIN_ID=80001
State Contract
The State Contract stores the Global Identity State Tree. The GIST State represents a snapshot of the states of all the identities operating in the system. The design of the State Contract allows identities to authenticate themselves using Identity Profiles.
Every time that an identity is updated, for example when a credential is issued using SMT Proof or revoked, it needs to perform a State Transition. This process consists of generating a ZK-proof or a digitally-signed message that proves that the identity is authorized to perform the state transition. Then the State contract verifies the proof on-chain via its transitState (for ZK-proofs) or transitStateGeneric (generic, as the name suggests) function.
Learn more about state contract here.
- Polygon Amoy
- Polygon Main
ISSUER_ETHEREUM_CONTRACT_ADDRESS=0x1a4cC30f2aA0377b0c3bc9848766D90cb4404124
ISSUER_ETHEREUM_RESOLVER_PREFIX=polygon:amoy
ISSUER_ETHEREUM_URL={Replace with a Polygon Amoy RPC}
ISSUER_ETHEREUM_CONTRACT_ADDRESS=0x624ce98D2d27b20b8f8d521723Df8fC4db71D79D
ISSUER_ETHEREUM_RESOLVER_PREFIX=polygon:main
ISSUER_ETHEREUM_URL={Replace with a Polygon Main RPC}
Issuer's DID
Currently there are two options for creating an issuer's DID:
- Using a Makefile command, generally used for the UI or API-UI.
- Create Identity endpoint of Core API, generally used for the Core API.
Makefile Command
The DID configured for the UI or API-UI works under the following rules:
- if a DID is provided in the .env-api file, it will be checked for its existence in the vault. In case it is different from the one in the vault, the latter will be updated.
- If a DID is not provided in the file, it will be searched in the vault.
- When a DID is created with this method, it is saved both in the .env-api file and in the vault. :::
.env-api
- Polygon Amoy
- Polygon Main
- Polygon Mumbai*
ISSUER_API_IDENTITY_BLOCKCHAIN=polygon
ISSUER_API_IDENTITY_NETWORK=amoy
ISSUER_API_IDENTITY_METHOD={polygonid | custom method}
ISSUER_API_IDENTITY_BLOCKCHAIN=polygon
ISSUER_API_IDENTITY_NETWORK=main
ISSUER_API_IDENTITY_METHOD={polygonid | custom method}
ISSUER_API_IDENTITY_BLOCKCHAIN=polygon
ISSUER_API_IDENTITY_NETWORK=mumbai
ISSUER_API_IDENTITY_METHOD={polygonid | custom method}
Execute the following make command
in order to generate a new DID with the .env-api provided blockchain
,network
and method
.
The given command will perform the following actions:
- Replace ISSUER_API_UI_ISSUER_DID value with the new DID(.env-api file).
- Write the new DID in the vault.
make generate-issuer-did
In order to delete the DID from the Vault:
make delete-did
Core API
The Core API provides the /v1/identities
endpoint in order to create an identity.
The property type can have two possible values:
BJJ
: BJJ keys based identity.ETH
: Ethereum based identity.
Create Identity Payload example:
- Polygon Amoy
- Polygon Main
- Polygon Mumbai*
{
"didMetadata": {
"method": "polygonid",
"blockchain": "polygon",
"network": "amoy",
"type": "BJJ"
}
}
{
"didMetadata": {
"method": "polygonid",
"blockchain": "polygon",
"network": "main",
"type": "BJJ"
}
}
{
"didMetadata": {
"method": "polygonid",
"blockchain": "polygon",
"network": "mumbai",
"type": "BJJ"
}
}