This page explains states and a typical flow of client-managed secret mode with the did:cheqd method. See https://identity.foundation/did-registration/#client-managed-secret-mode for more information about the protocol.
¶ States
Possible states:
¶ Requests and Responses
¶ Request 1: Missing verificationMethod "#key-1"
Supported options:
- network: The network on which to create the DID (possible values:
testnet,mainnet)
curl -H "Authorization: Bearer b082c420-df67-4b06-899c-b7c51d75fba0" \
-X POST "https://api.godiddy.com/0.1.0/universal-registrar/create?method=cheqd" \
-H "Content-Type: application/json" \
-d '{
"options": {
"clientSecretMode": true,
"network": "testnet"
},
"secret": { },
"didDocument": {
"@context": ["https//www.w3.org/ns/did/v1"],
"service": [{
"id": "#didcomm",
"type": "DIDComm",
"serviceEndpoint": "https://test.com/mydidcomm/endpoint"
}]
}
}'
¶ Response A: action=getVerificationMethod
{
"jobId": null,
"didState": {
"state": "action",
"action": "getVerificationMethod",
"verificationMethodTemplate": [{
"id": "#key-1",
"type": "Ed25519VerificationKey2020",
"purpose": [
"authentication"
]
}]
},
"didRegistrationMetadata": { ... },
"didDocumentMetadata": { ... }
}
¶ Request 2: verificationMethod "#key-1"
curl -H "Authorization: Bearer b082c420-df67-4b06-899c-b7c51d75fba0" \
-X POST "https://api.godiddy.com/0.1.0/universal-registrar/create?method=cheqd" \
-H "Content-Type: application/json" \
-d '{
"options": {
"clientSecretMode": true,
"network": "testnet"
},
"secret": { },
"didDocument": {
"@context": ["https//www.w3.org/ns/did/v1"],
"verificationMethod": [{
"id": "#key-1",
"type": "Ed25519VerificationKey2020",
"publicKeyMultibase": "<-- multibase encoded -->"
}],
"service": [{
"id": "#didcomm",
"type": "DIDComm",
"serviceEndpoint": "https://test.com/mydidcomm/endpoint"
}]
}
}'
¶ Response B: action=signPayload with "signingRequest1"
{
"jobId": "00000000-0000-0000-0000-000000000000",
"didState": {
"state": "action",
"action": "signPayload",
"signingRequest": {
"signingRequest1": {
"kid": "#key-1",
"alg": "EdDSA",
"serializedPayload": "<-- base 64 encoded -->"
}
}
},
"didRegistrationMetadata": { ... },
"didDocumentMetadata": { ... }
}
¶ Request 3: signingResponse for "signingRequest1"
curl -H "Authorization: Bearer b082c420-df67-4b06-899c-b7c51d75fba0" \
-X POST "https://api.godiddy.com/0.1.0/universal-registrar/create?method=indy" \
-H "Content-Type: application/json" \
-d '{
"jobId": "00000000-0000-0000-0000-000000000000",
"options": {
"clientSecretMode": true
},
"secret": {
"signingResponse": {
"signingRequest1": {
"signature": "<-- base64 encoded -->"
}
}
},
"didDocument": { }
}'
¶ Response C: state=finished
{
"jobId": "00000000-0000-0000-0000-000000000000",
"didState": {
"state": "finished",
"did": "did:cheqd:testnet:1234567890123456789012",
"secret": {
"verificationMethod": [
[{
"id": "#key-1"
}, {
"id": "did:cheqd:testnet:1234567890123456789012#key-1",
"controller": "did:cheqd:testnet:1234567890123456789012"
}]
]
}
},
"didRegistrationMetadata": { ... },
"didDocumentMetadata": { ... }
}
¶ OpenSSL Commands
¶ For Request 2:
Generate a new DID controller keypair (Ed25519):
openssl genpkey -algorithm ed25519 -outform DER >privkey
openssl pkey -in privkey -pubout -out pubkey -inform DER -outform DER
Convert DID controller public key to Multibase:
echo "z$(echo -n "$(echo -n 'ED01'| basenc -d --base16)$(cat pubkey| tail -c +13)"| base58)"
The result can then used as value of publicKeyBaseMultibase in Request 2.
¶ For Response B:
Extract the value of serializedPayload from Response B. Then Base64-decode the payload and write to a file:
echo "<-- base64 encoded -->"|base64 -d >payload
¶ For Request 3:
Sign the payload with the DID controller private key:
openssl pkeyutl -sign -rawin -in payload -inkey privkey -keyform DER| base64| tr -d '\n' >signature
The result can then used as value of signature in Request 3.
Note: This needs experimental Debian/Ubuntu packages libssl3 3.0.0 and openssl 3.0.0.