Commands reference

This section describe the complete list of commands that can be called in the command line interface.

Set, Using, View, Env, Run, Exit
Compute
Conformance
Authorisation API
Ledger API
DID Registry API
Timestamp API
Trusted Apps Registry API
Trusted Issuers Registry API
Trusted Schemas Registry API
New and old APIs

Set, Using, View, Env, Run, Exit

using user <algorithm> <didMethod> <privateKey> <did> <keyId>

Command to load a client in the CLI with one of the supported algorithms (ES256, RS256, EdDSA).

Params:

algorithm (optional): Algorithm. It must be ES256K (default), ES256, RS256, or EdDSA. Use "null" to remove the user.
didMethod (optional): Did method version. It must be "did1" (default, legal entities), or "did2" (natural persons).
privateKey (optional): Private Key in hex string or JWK format. By default it creates a random key. The hex string is only valid if the algorithm selected is ES256K.
did (optional): DID of the client. It should start with "did:ebsi" (or another did method registered in the did registry). There is no specific format for the complete did, but it is recommend to use in the third section a 256-bit number encoded in base58. By default it defines a random DID.
keyId (optional): Key identifier registered in the verifications methods of the did document.

Examples:

using user ES256K did1 f19863112d798add7c8df9a100a9ed961e7e7986c2e9042506840c8695e38800 did:ebsi:zkqR9GCLrLYbkubAjuqQZAz
using user ES256 did2
using user ES256 did1 {"kty":"EC","crv":"P-256","x":"...","y":"...","d":"..."} did:ebsi:zkqR9GCLrLYbkubAjuqQZAz keys-2
using user null (remove user)

using ethuser <privateKey> <did>

Command to call using user ES256K <didMethod> <privateKey> <did>.

using app <name> <privateKey>

Command to load a Trusted App in the CLI. It also calls the Trusted Apps Registry to get the application id.

Params:

name: Application name
privateKey: Private key in hexadecimal format.

Examples:

using app my-app f19863112d798add7c8df9a100a9ed961e7e7986c2e9042506840c8695e38800

using token <token>

Command to load a JWT derived from a SIOP authorisation. This JWT will be added in the headers of subsequents calls to the APIs. It's also possible to load a JWT previously saved in the CLI (see set var) by referencing its name.

Params:

token: JWT to set in the headers. Leave it empty to remove the token from the headers.

Examples:

using token eyJ0eXAiOiJ...
using token mySioptoken
using token token1
using token (token removed)

using oauth2token <token>

Command to load a JWT. This JWT is added in the headers when calling Ledger API if the SIOP token is not defined (see using token <token>). When a transaction is broadcasted to the blockchain the script will use this token to access Ledger API and it will wait for the transaction to be mined by checking the transaction receipt. It's also possible to load a JWT previously saved in the CLI (see set var) by referencing its name.

Params:

token: JWT to set in the headers when accessing Ledger API. Leave it empty to remove the token from the headers.

Examples:

using oauth2token eyJ0eXAiOiJ...
using oauth2token myOauth2Token
using oauth2token token1
using oauth2token (token removed)

set <var> <value>

Command to set a variable. Use it to load different JWTs in the CLI. You can also store the results when calling the different APIs.

Params:

var: Variable name
value: Value to store

Examples:

set token1 eyJhbG...
mytoken: authorisation siop

view <id>

Command to view the data stored in the internal variables.

Params:

id: ID of the variable

Examples:

view token (JWT used in the headers).
view oauth2token (JWT used in the headers of Ledger API).
view user (view user set with using user).
view app (view app set with using app).
view transactionInfo (view relevant info related to the most recent transaction built/sent).

env <environment>

Command to set the environment. By default the CLI starts pointing to Test Environment.

Examples:

env test
env pilot
env conformance

run <file>

This repository contains a script folder with some scripts that provide you examples of how you can easily run multiple commands in a single execution. The commands should be defined in a file and the path should be relative to the folder "scripts". Store your scripts in the folder scripts/local.

Examples:

run onboarding
run local/my-script.txt

exit

Command to exit from the CLI.

Compute

compute signTransaction <unsignedTransaction>

Command to sign a transaction with the private key defined in using user. It's also possible to load it from the saved variables by referencing its name.

Params:

unsignedTransaction: JSON with the unsigned transaction (ethereum).

Examples:

compute signTransaction 0xf9...
compute signTransaction utx
sgnTx: compute signTransaction utx

compute createPresentation <verifiableCredential>

Command to generate a Verifiable Presentation. The presentation is signed with the user defined in using user.

Params:

verifiableCredential: JSON with the verifiable credential. It's also possible to load it from the saved variables by referencing its name.

Examples:

compute createPresentation {"@context":"..."}
compute createPresentation vc

compute createPresentationJwt <verifiableCredential>

Command to generate a Verifiable Presentation using the "vp_jwt" format. The presentation is signed with the user defined in using user.

Params:

verifiableCredential: Verifiable credential. It's also possible to load it from the saved variables by referencing its name.

Examples:

compute createPresentationJwt eyJhb...
compute createPresentationJwt {"@context":"..."}
compute createPresentationJwt vc

compute createVcJwt <vcPayload> <jwtPayload> <alg>

Command to create a verifiable credential with JWT format. It automatically defines relevant data like context, type, isssuance date, and expiration data. The credential is signed with the user defined in using user.

Params:

vcPayload: Payload to include in "vc" field. Context, id, type, issuer, issuance/expiration date are automatically generated but then can be overwritten.
jwtPayload: Payload to include outside "vc" field.
alg (optional): Signing algorithm to be used. It should be ES256K (default), ES256, RS256, or EdDSA. And the private key should be defined for that algorithm (see using user).

Examples:

compute createVcJwt {"credentialSubject":{"id":"did:ebsi:123"}} {"sub":"did:ebsi:123"}
vc: compute createVcJwt {"credentialSubject":{"id":"did:ebsi:123"}} {"sub":"did:ebsi:123"} ES256

compute canonicalizeBase64url <json>

Command to canonicalize a JSON and encode it in base64url. It's also possible to load it from the saved variables by referencing its name. This command is used during the onboarding process to encode the verifiable presentation in base64url.

Params:

json: JSON object to encode

Examples:

compute canonicalizeBase64url {"@context":"..."}
compute canonicalizeBase64url vp

compute verifyAuthenticationRequest <request>

Command to verify an authentication request by checking the signature and did in the request. It return the client_id specified in the request. It's also possible to load it from the saved variables by referencing its name. This command is used during the SIOP authentication with the authorisation API.

Params:

request: JSON containing at least the fields client_id and request (JWT).

Examples:

compute verifyAuthenticationRequest {"client_id":"https//...","request":"eyJ0e..."}
compute verifyAuthenticationRequest request

compute verifySessionResponse <response>

Command to verify a session response by checking the nonce and signature in the Ake response. It decrypts and returns the access token contained in the Ake response. For decryption it uses the private key defined in the command using user. It's also possible to load the response from the saved variables by referencing its name. This command is used during the SIOP authentication with the authorisation API.

Params:

response: JSON containing the fields nonce (reference to check in the response), and response (using Ake protocol format).

Examples:

compute verifySessionResponse {"nonce":"3a4...","response":{"ake1_enc_payload":"9ed9b3b..."}
compute verifySessionResponse response

compute decodeJWT <jwt>

Command to decode a jwt. It's also possible to load it from the saved variables by referencing its name.

Params:

jwt: JWT to decode.

Examples:

compute decodeJWT eyJ0e...
compute decodeJWT myJwt

compute decodeBase64 <data>

Command to decode data encoded in base64. It's also possible to load it from the saved variables by referencing its name.

Params:

data: Data to decode.

Examples:

compute decodeBase64 eyJ0e...
compute decodeBase64 myData

compute decodeBase64url <data>

Command to decode data encoded in base64url. It's also possible to load it from the saved variables by referencing its name.

Params:

data: Data to decode.

Examples:

compute decodeBase64url eyJ0e...
compute decodeBase64url myData

compute decodeHex <data>

Command to decode data encoded as hex string. It's also possible to load it from the saved variables by referencing its name.

Params:

data: Data to decode.

Examples:

compute decodeHex 0x41df...
compute decodeHex 41df...

Conformance

Set of instructions to interact with the conformance service. Check also the scripts located in scripts/conformanceNaturalPerson and scripts/conformanceLegalEntity with complete flows.

conformance get <url>

Command to GET in conformance service. It is useful to get the conformance logs.

Params:

url: Path to get.

Examples:

data: conformance get /logs/5fd122e1-c5e5-40a6-b448-00e0f21f9d7e
conformance get /logs/ conformanceId
conformance get /health

conformance setId <uuid>

Command to set a conformance id for the headers.

Params:

uuid (optional): UUID identifier. If it is empty it will create a random UUID. If it is "null" it will remove the id.

Examples:

conformance setId
conformance setId d3d701df-513d-46b5-9285-25ea05c639a0
conformance setId null

conformance issuerInitiate <flowType> <redirect>

Command to call the initiate endpoint in the issuer mock in the conformance service.

Params:

flowType (optional): It must be "cross-device" or "same-device" (default).
redirect (optional): boolean defining the redirect option. By default it is false.

Examples:

conformance issuerInitiate
conformance issuerInitiate cross-device true

conformance issuerAuthorize <redirectUri> <credentialType>

Command to call the authorize endpoint in the issuer mock in the conformance service.

Params:

redirectUri: uri to redirect
credentialType: credential type received in the initiate call

Examples:

conformance issuerAuthorize http://mywallet.io https://api-pilot.ebsi.eu/trusted-schemas-registry/v3/schemas/0xad457662a535791e888994e97d7b5e0cdd09fbae2c8900039d2ee2d9a64969b1

conformance issuerToken <code> <redirectUri>

Command to call the token endpoint in the issuer mock in the conformance service.

Params:

code: code received in the authorize call
redirectUri (optional): uri to redirect. By default it is http://localhost:3000

Examples:

conformance issuerToken abcdfe123456

conformance issuerCredential <c_nonce> <redirectUri> <accessToken> <alg> <credentialType> <issuerUrl>

Command to call the credential endpoint in the issuer mock in the conformance service. It requires an access token (obtained in the previous call) in the headers.

Params:

c_nonce: nonce received in the previous call
redirectUri: uri to redirect
accessToken: access token received in the token call
alg: Signing algorithm to be used. It should be ES256K (default), ES256, RS256, or EdDSA. And the private key should be defined for that algorithm (see using user).
credentialType: credential type received in the initiate call
issuerUrl: issuer url received in the initiate call

Examples:

conformance issuerCredential 7aba0bd957099f28fd31 http://localhost:3000 2f6a857923f6565b3432 ES256K https://api-pilot.ebsi.eu/trusted-schemas-registry/v3/schemas/0xad457662a535791e888994e97d7b5e0cdd09fbae2c8900039d2ee2d9a64969b1 https://conformance.test.intebsi.xyz/conformance/v3

conformance verifierAuthRequest <flowType> <redirect>

Command to call the endpoint /authentication-requests in the verifier-mock.

Params:

flowType (optional): It must be "cross-device" or "same-device" (default).
redirect (optional): boolean defining the redirect option

Examples:

conformance verifierAuthRequest
conformance verifierAuthRequest cross-device true

conformance verifierAuthResponse <jwtVp> <alg>

Command to call /authentication-responses in the verifier mock.

Params:

jwtVp: presentation to include in the data. It should be a presentation in JWT (see compute createPresentationJwt)
alg (optional): Signing algorithm to be used for the id token. It should be ES256K (default), ES256, RS256, or EdDSA. And the private key should be defined for that algorithm (see using user).

Examples:

conformance verifierAuthResponse eyJ0e...
conformance verifierAuthResponse eyJ0e... ES256K

conformance issuer

Command to test the flow in the issuer mock in order to create a credential. It will call internally issuerAuthorize, issuerToken, and issuerCredential.

conformance verifier

Command to test the flow for issuer and verifier. It will call internally the issuer endpoints to create a credential, and the verifier to send a verifiable presentation.

conformance notification <endpoint> <headers> <body>

Command to make a call to conformance api through notifications api.

Params:

endpoint: Endpoint in conformance
headers: JSON with the headers
body: JSON with the body

Examples:

conformance /issuer-mock/authorize {"conformance":"cc08e8cd-6c98-43e1-99ca-b96300eb9ab5"} {"scope":"openid conformance_testing","response_type":"code","redirect_uri":"http://localhost:3000","client_id":"http://localhost:3000","response_mode":"post","state":"73ccb1b10f8f","nonce":"017a42792de3"}

Authorisation API

OpenAPI documentation

authorisation get <url>

Command to GET in Authorisation API. It is useful to check the health of the api.

Params:

url: Path to get.

Examples:

authorisation get /health

authorisation siopRequest

Command to start a SIOP authentication with authorisation api. The authorisation api will return a request.

Examples:

authorisation siopRequest
response: authorisation siopRequest

authorisation siopSession <url> <alg> <vpBase64url>

Command to call /siop-sessions in authorisation api. It uses the client defined in using user to sign the response. It returns the response received from the api. It's also possible to load the parameters from the saved variables by referencing the names.

Params:

url: callback url to build the response.
alg (optional): Signing algorithm to be used. It should be ES256K (default), ES256, RS256, or EdDSA. And the private key should be defined for that algorithm (see using user).
vpBase64url (optional): Data to include in the verified claims. It should be canonicalized and encoded in base64url (see compute canonicalizeBase64url)

Examples:

authorisation siopSession https://... ES256K eyJ0e...
authorisation siopSession callbackUrl ES256K myVpBase64url

authorisation siop <alg> <vcJwtEOS>

Command to establish a SIOP session with authorisation api. It uses the client defined in using user. It returns an access token. The command will perform the following steps:

call compute createPresentationJwt to create a verifiable presentation (only if a verifiable authorisation is provided).
call authorisation siopRequest to get a request from the API.
call compute verifyAuthenticationRequest to verify the request.
call authorisation siopSession to send a response to the api.
call compute verifySessionResponse to verify the response and get the access token.

Params:

alg (optional): Signing algorithm to be used. It should be ES256K (default), ES256, RS256, or EdDSA. And the private key should be defined for that algorithm (see using user).
vcJwtEOS (optional): Verifiable Authorisation issued by an EBSI Onboarding Service (EOS) to be wrapped in a verifiable presentation. This credential is required for natural persons.

Examples:

authorisation siop
mySiopToken: authorisation siop
mySiopToken: authorisation siop EdDSA
mySiopToken: authorisation siop ES256K ey...

authorisation oauth2 <audience>

Command to establish an Oauth2 session with authorisation api. It uses the ap defined in using app. It returns an access token. Normally this call is used together with the option to store the results.

Params:

audience: App audience of oauth2 token.

Examples:

authorisation oauth2 ledger-api
myOauth2Token: authorisation oauth2 ledger-api

Ledger API

ledger <contract> <method> <params>

Command to interact with the smart contracts throught the Ledger API without calling other APIs. The contract, methods, and params are the same defined in the previous sections for DID API, Timestamp API, Trusted Apps Registry API, Trusted Issuers Registry API, and Trusted Schemas Registry API.

Examples:

ledger timestamp timestampHashes
ledger timestamp build-timestampHashes
ledger tir insertIssuer did:ebsi:zkqR9GCLrLYbkubAjuqQZAz {"institution":"eu"}

ledger getBlock <number>

Command to get a block by number. The JWT defined in using oauth2token is set in the headers.

Params:

number: Block number

Examples:

ledger get 123

ledger getTransactionCount <address>

Command to get the number of transactions of a particular address. The JWT defined in using oauth2token is set in the headers.

Params:

address: Ethereum address

Examples:

ledger getTransactionCount 0x2fCbc96c55e57bed5ae8BC533EF77b977Dc482d7

ledger getChainId

Command to get the chain id of the network. The JWT defined in using oauth2token is set in the headers.

Examples:

ledger getChainId

ledger getTransaction <id>

Command to get a transaction by its ID. The JWT defined in using oauth2token is set in the headers.

Params:

id: Transaction ID

Examples:

ledger getTransaction 0x2fCb...82d7

ledger getTransactionReceipt <id>

Command to get the receipt of a particular transaction. It also displays the revert reason for failed transactions. The JWT defined in using oauth2token is set in the headers.

Params:

id: Transaction ID

Examples:

ledger getTransactionReceipt 0x2fCb...482d7

ledger sendTransaction <signedTransaction>

Command to send transactions to the blockchain. The JWT defined in using oauth2token is set in the headers.

Params:

signedTransaction: signed transaction in raw format.

Examples:

ledger sendTransaction 0x2fCb...482d7 0x123456

proxyledger <...>

The command proxyledger has the same commands as ledger with the difference that it will call the blockchain directly without going through Ledger API. To enable this feature set the corresponding provider in TEST_BESU_PROVIDER or PILOT_BESU_PROVIDER in the env variables. This command should not be used by externals.

Examples:

proxyledger timestamp timestampHashes
proxyledger timestamp build-timestampHashes
proxyledger tir insertIssuer did:ebsi:zkqR9GCLrLYbkubAjuqQZAz {"institution":"eu"}
proxyledger getTransactionReceipt 0x2fCb...482d7

DID Registry API

OpenAPI documentation

did get <url>

Command to GET in the DID Registry API. All endpoints are open to the public.

Params:

url: Path to get.

Examples:

did get /identifiers
did get /identifiers?controller=0x2fCb...82d7
did get /identifiers/did:ebsi:zkqR9GCLrLYbkubAjuqQZAz
did get /hash-algorithms
did get /policies
did get /did-timestamps

did (build-)insertPolicy <name> <data>

Command to insert a policy. The JWT is set in the headers. This method requires admin rights in the DID Registry.

Use the build- prefix to call the API helper to build the transaction. If this prefix is not set then the command will perform the following steps:

call did build-insertPolicy to build an unsigned transaction.
call compute signTransaction to sign the transaction with the user defined in using user.
call did sendSignedTransaction to send the transaction signed.
call view transactionInfo to see relevant data for this transaction.

Params:

name (optional): Name of the policy. By default it uses a random name.
data (optional): JSON data to store in the policy. By default it uses random data.

Examples:

did insertPolicy
did insertPolicy my-policy {"name":"my policy"}

did (build-)updatePolicy <name> <data>

Command to update an existing policy. The JWT is set in the headers. This method requires admin rights in the DID Registry.

Use the build- prefix to call the API helper to build the transaction. If this prefix is not set then the command will perform the following steps:

call did build-updatePolicy to build an unsigned transaction.
call compute signTransaction to sign the transaction with the user defined in using user.
call did sendSignedTransaction to send the transaction signed.
call view transactionInfo to see relevant data for this transaction.

Params:

name: Name of the policy.
data (optional): JSON data to store in the policy. By default it uses random data.

Examples:

did updatePolicy my-policy {"name":"my policy"}

did (build-)insertHashAlgorithm <outputLength> <ianaName> <oid> <status> <multihash>

Command to insert a new hash algorithm. The JWT is set in the headers. This method requires admin rights in the DID Registry.

Use the build- prefix to call the API helper to build the transaction. If this prefix is not set then the command will perform the following steps:

call did build-insertHashAlgorithm to build an unsigned transaction.
call compute signTransaction to sign the transaction with the user defined in using user.
call did sendSignedTransaction to send the transaction signed.
call view transactionInfo to see relevant data for this transaction.

Params:

outputLength (optional): JSON data to store. By default it is 1.
ianaName (optional): IANA name. By default it is "undefined".
oid (optional): OID. By default it is "undefined".
status (optional): Status. It must be 1 (default) or 2 which corresponds with active or revoked respectively.
multihash (optional): Multihash identifier. By default it uses de ianaName.

Examples:

did insertHashAlgorithm 256 sha-256 2.16.840.1.101.3.4.2.1 1 sha2-256
did insertHashAlgorithm 512 sha3-512 2.16.840.1.101.3.4.2.10 1 sha3-512

did (build-)updateHashAlgorithm <hashAlgId> <outputLength> <ianaName> <oid> <status> <multihash>

Command to update an existing hash algorithm. The JWT is set in the headers. This method requires admin rights in the DID Registry.

Use the build- prefix to call the API helper to build the transaction. If this prefix is not set then the command will perform the following steps:

call did build-updateHashAlgorithm to build an unsigned transaction.
call compute signTransaction to sign the transaction with the user defined in using user.
call did sendSignedTransaction to send the transaction signed.
call view transactionInfo to see relevant data for this transaction.

Params:

hashAlgId: Hash Algorithm ID to update.
outputLength (optional): JSON data to store. By default it is 1.
ianaName (optional): IANA name. By default it is "undefined".
oid (optional): OID. By default it is "undefined".
status (optional): Status. It must be 1 (default) or 2 which corresponds with active or revoked respectively.
multihash (optional): Multihash identifier. By default it uses de ianaName.

Examples:

did updateHashAlgorithm 1 256 sha-256 2.16.840.1.101.3.4.2.1 1 sha2-256
did updateHashAlgorithm 7 512 sha3-512 2.16.840.1.101.3.4.2.10 1 sha3-512

did (build-)insertDidDocument <did> <document> <metadata> <timestampData>

Command to insert a new DID document and create a timestamp of it. The JWT is set in the headers.

Use the build- prefix to call the API helper to build the transaction. If this prefix is not set then the command will perform the following steps:

call did build-insertDidDocument to build an unsigned transaction.
call compute signTransaction to sign the transaction with the user defined in using user.
call did sendSignedTransaction to send the transaction signed.
call view transactionInfo to see relevant data for this transaction.

Params:

did (optional): DID to insert. By default it uses the did defined in the command using user.
document (optional): JSON did document to store in the registry. By default it creates a document derived from the private keys defined in the command using user.
metadata (optional): JSON metadata to insert in this first version. By default it creates random data.
timestampData (optional): JSON data to store in the timestamp of the did document. By default it creates random data.

Examples:

did insertDidDocument
did insertDidDocument did:ebsi:zkqR9GCLrLYbkubAjuqQZAz
did insertDidDocument did:ebsi:zkqR9GCLrLYbkubAjuqQZAz {"@context":"...","id":"...","verificationMethod":[...]}
did insertDidDocument did:ebsi:zkqR9GCLrLYbkubAjuqQZAz {"@context":"...","id":"...","verificationMethod":[...]} {"metadata":"data"}
did insertDidDocument did:ebsi:zkqR9GCLrLYbkubAjuqQZAz {"@context":"...","id":"...","verificationMethod":[...]} {"metadata":"data"} {"data":"timestamp data"}

did (build-)updateDidDocument <did> <document> <metadata> <timestampData>

Command to update a DID document and create a timestamp of the update. The user should be defined in the list of controllers of the DID. The JWT is set in the headers.

Use the build- prefix to call the API helper to build the transaction. If this prefix is not set then the command will perform the following steps:

call did build-updateDidDocument to build an unsigned transaction.
call compute signTransaction to sign the transaction with the user defined in using user.
call did sendSignedTransaction to send the transaction signed.
call view transactionInfo to see relevant data for this transaction.

Params:

did (optional): DID to update. By default it uses the did defined in the command using user.
document (optional): JSON did document to store in the registry. By default it creates a document derived from the private keys defined in the command using user.
metadata (optional): JSON metadata to insert in this new version. By default it creates random data.
timestampData (optional): JSON data to store in the timestamp of the did document. By default it creates random data.

Examples:

did updateDidDocument
did updateDidDocument did:ebsi:zkqR9GCLrLYbkubAjuqQZAz
did updateDidDocument did:ebsi:zkqR9GCLrLYbkubAjuqQZAz {"@context":"...","id":"...","verificationMethod":[...]}
did updateDidDocument did:ebsi:zkqR9GCLrLYbkubAjuqQZAz {"@context":"...","id":"...","verificationMethod":[...]} {"metadata":"data"}
did updateDidDocument did:ebsi:zkqR9GCLrLYbkubAjuqQZAz {"@context":"...","id":"...","verificationMethod":[...]} {"metadata":"data"} {"data":"timestamp data"}

did (build-)insertDidController <did> <controllerId> <notBefore> <notAfter>

Command to insert new controllers in the DID. The user should be defined in the list of controllers of the DID. The JWT is set in the headers.

Use the build- prefix to call the API helper to build the transaction. If this prefix is not set then the command will perform the following steps:

call did build-insertDidController to build an unsigned transaction.
call compute signTransaction to sign the transaction with the user defined in using user.
call did sendSignedTransaction to send the transaction signed.
call view transactionInfo to see relevant data for this transaction.

Params:

did: DID to update. By default it uses the did defined in the command using user.
controllerId: Ethereum address of new controller.
notBefore (optional): Point in time when the new controller becomes valid. It should be defined in epoch time. By default it takes the actual time.
notAfter (optional): Point in time when the new controller becomes invalid. It should be defined in epoch time. By default it is 0 (indefinite).

Examples:

did insertDidController did:ebsi:zkqR9GCLrLYbkubAjuqQZAz 0x8593...9e10
did insertDidController did:ebsi:zkqR9GCLrLYbkubAjuqQZAz 0x8593...9e10 1625568669 1657104669

did (build-)updateDidController <did> <controllerId> <notBefore> <notAfter>

Command to replace the signer for a new one in the list of controllers of the DID. The user should be defined in the list of controllers of the DID. The JWT is set in the headers.

Use the build- prefix to call the API helper to build the transaction. If this prefix is not set then the command will perform the following steps:

call did build-updateDidController to build an unsigned transaction.
call compute signTransaction to sign the transaction with the user defined in using user.
call did sendSignedTransaction to send the transaction signed.
call view transactionInfo to see relevant data for this transaction.

Params:

did: DID to update. By default it uses the did defined in the command using user.
controllerId: Ethereum address of new controller. The signer of the transaction will be removed.
notBefore (optional): Point in time when the new controller becomes valid. It should be defined in epoch time. By default it takes the actual time.
notAfter (optional): Point in time when the new controller becomes invalid. It should be defined in epoch time. By default it is 0 (indefinite).

Examples:

did updateDidController did:ebsi:zkqR9GCLrLYbkubAjuqQZAz 0x8593...9e10
did updateDidController did:ebsi:zkqR9GCLrLYbkubAjuqQZAz 0x8593...9e10 1625568669 1657104669

did (build-)revokeDidController <did> <controllerId>

Command to remove a controller from the list of controllers and put it in the revoked list. The user should be defined in the list of controllers of the DID. The JWT is set in the headers.

Use the build- prefix to call the API helper to build the transaction. If this prefix is not set then the command will perform the following steps:

call did build-revokeDidController to build an unsigned transaction.
call compute signTransaction to sign the transaction with the user defined in using user.
call did sendSignedTransaction to send the transaction signed.
call view transactionInfo to see relevant data for this transaction.

Params:

did: DID to update. By default it uses the did defined in the command using user.
controllerId: Ethereum address to be removed from controllers and to be put in the revoked list.

Examples:

did revokeDidController did:ebsi:zkqR9GCLrLYbkubAjuqQZAz 0x8593...9e10

did (build-)appendDidDocumentVersionHash <did> <document> <timestampData>

Command to create a timestamp in an existing version. The user should be defined in the list of controllers of the DID. The JWT is set in the headers.

Use the build- prefix to call the API helper to build the transaction. If this prefix is not set then the command will perform the following steps:

call did build-appendDidDocumentVersionHash to build an unsigned transaction.
call compute signTransaction to sign the transaction with the user defined in using user.
call did sendSignedTransaction to send the transaction signed.
call view transactionInfo to see relevant data for this transaction.

Params:

did (optional): DID to update. By default it uses the did defined in the command using user.
document (optional): JSON of the version of the existing did document. By default it creates a document derived from the private keys defined in the command using user.
timestampData (optional): JSON data to store in the timestamp of the did document. By default it creates random data.

Examples:

did appendDidDocumentVersionHash
did appendDidDocumentVersionHash did:ebsi:zkqR9GCLrLYbkubAjuqQZAz
did appendDidDocumentVersionHash did:ebsi:zkqR9GCLrLYbkubAjuqQZAz {"@context":"...","id":"...","verificationMethod":[...]}
did appendDidDocumentVersionHash did:ebsi:zkqR9GCLrLYbkubAjuqQZAz {"@context":"...","id":"...","verificationMethod":[...]} {"data":"timestamp data"}

did (build-)detachDidDocumentVersionHash <did> <document>

Command to detach a did document version from its timestamp. The user should be defined in the list of controllers of the DID. The JWT is set in the headers.

Use the build- prefix to call the API helper to build the transaction. If this prefix is not set then the command will perform the following steps:

call did build-detachDidDocumentVersionHash to build an unsigned transaction.
call compute signTransaction to sign the transaction with the user defined in using user.
call did sendSignedTransaction to send the transaction signed.
call view transactionInfo to see relevant data for this transaction.

Params:

did (optional): DID to update. By default it uses the did defined in the command using user.
document (optional): JSON of the version of the existing did document. By default it creates a document derived from the private keys defined in the command using user.

Examples:

did detachDidDocumentVersionHash
did detachDidDocumentVersionHash did:ebsi:zkqR9GCLrLYbkubAjuqQZAz
did detachDidDocumentVersionHash did:ebsi:zkqR9GCLrLYbkubAjuqQZAz {"@context":"...","id":"...","verificationMethod":[...]}

did (build-)appendDidDocumentVersionMetadata <did> <document> <metadata>

Command to insert new metadata in a specific version of a DID document. The user should be defined in the list of controllers of the DID. The JWT is set in the headers.

Use the build- prefix to call the API helper to build the transaction. If this prefix is not set then the command will perform the following steps:

call did build-appendDidDocumentVersionMetadata to build an unsigned transaction.
call compute signTransaction to sign the transaction with the user defined in using user.
call did sendSignedTransaction to send the transaction signed.
call view transactionInfo to see relevant data for this transaction.

Params:

did (optional): DID to update. By default it uses the did defined in the command using user.
document (optional): JSON did document to update. By default it creates a document derived from the private keys defined in the command using user.
metadata (optional): JSON metadata to insert in this version. By default it creates random data.

Examples:

did appendDidDocumentVersionMetadata
did appendDidDocumentVersionMetadata did:ebsi:zkqR9GCLrLYbkubAjuqQZAz
did appendDidDocumentVersionMetadata did:ebsi:zkqR9GCLrLYbkubAjuqQZAz {"@context":"...","id":"...","verificationMethod":[...]}
did appendDidDocumentVersionMetadata did:ebsi:zkqR9GCLrLYbkubAjuqQZAz {"@context":"...","id":"...","verificationMethod":[...]} {"metadata":"data"}

did (build-)detachDidDocumentVersionMetadata <did> <document> <metadata>

Command to detach a metadata from a specific version of a DID document. The user should be defined in the list of controllers of the DID. The JWT is set in the headers.

Use the build- prefix to call the API helper to build the transaction. If this prefix is not set then the command will perform the following steps:

call did build-detachDidDocumentVersionMetadata to build an unsigned transaction.
call compute signTransaction to sign the transaction with the user defined in using user.
call did sendSignedTransaction to send the transaction signed.
call view transactionInfo to see relevant data for this transaction.

Params:

did (optional): DID to update. By default it uses the did defined in the command using user.
document (optional): JSON did document to update. By default it creates a document derived from the private keys defined in the command using user.
metadata (optional): JSON metadata to detach.

Examples:

did detachDidDocumentVersionMetadata
did detachDidDocumentVersionMetadata did:ebsi:zkqR9GCLrLYbkubAjuqQZAz
did detachDidDocumentVersionMetadata did:ebsi:zkqR9GCLrLYbkubAjuqQZAz {"@context":"...","id":"...","verificationMethod":[...]}
did detachDidDocumentVersionMetadata did:ebsi:zkqR9GCLrLYbkubAjuqQZAz {"@context":"...","id":"...","verificationMethod":[...]} {"metadata":"data"}

did sendSignedTransaction <unsignedTransaction> <signedTransaction>

Command to send a signed transaction to the DID Registry. The JWT is set in the headers. It's also possible to load the parameters from the saved variables by referencing the names.

Params:

unsignedTransaction: JSON with the unsigned transaction.
signedTransaction: Signed transaction in raw format.

Examples:

did sendSignedTransaction {"from":"0x6b...} 0xf9022...
did sendSignedTransaction utx sgntx

Timestamp API

OpenAPI documentation

timestamp get <url>

Command to GET in the Timestamp API. All endpoints are open to the public.

Params:

url: Path to get.

Examples:

timestamp get /timestamps
timestamp get /timestamps/uMHh...
timestamp get /hash-algorithms
timestamp get /records

timestamp (build-)insertHashAlgorithm <outputLength> <ianaName> <oid> <status> <multihash>

Command to insert a new hash algorithm. The JWT is set in the headers. This method requires admin rights in the Trusted Apps Registry.

Use the build- prefix to call the API helper to build the transaction. If this prefix is not set then the command will perform the following steps:

call timestamp build-insertHashAlgorithm to build an unsigned transaction.
call compute signTransaction to sign the transaction with the user defined in using user.
call timestamp sendSignedTransaction to send the transaction signed.
call view transactionInfo to see relevant data for this transaction.

Params:

outputLength (optional): JSON data to store. By default it is 1.
ianaName (optional): IANA name. By default it is "undefined".
oid (optional): OID. By default it is "undefined".
status (optional): Status. It must be 1 (default) or 2 which corresponds with active or revoked respectively.
multihash (optional): Multihash identifier. By default it uses de ianaName.

Examples:

timestamp insertHashAlgorithm 256 sha-256 2.16.840.1.101.3.4.2.1 1 sha2-256
timestamp insertHashAlgorithm 512 sha3-512 2.16.840.1.101.3.4.2.10 1 sha3-512

timestamp (build-)updateHashAlgorithm <hashAlgId> <outputLength> <ianaName> <oid> <status> <multihash>

Command to update an existing hash algorithm. The JWT is set in the headers. This method requires admin rights in the Trusted Apps Registry.

Use the build- prefix to call the API helper to build the transaction. If this prefix is not set then the command will perform the following steps:

call timestamp build-updateHashAlgorithm to build an unsigned transaction.
call compute signTransaction to sign the transaction with the user defined in using user.
call timestamp sendSignedTransaction to send the transaction signed.
call view transactionInfo to see relevant data for this transaction.

Params:

hashAlgId: Hash Algorithm ID to update.
outputLength (optional): JSON data to store. By default it is 1.
ianaName (optional): IANA name. By default it is "undefined".
oid (optional): OID. By default it is "undefined".
status (optional): Status. It must be 1 (default) or 2 which corresponds with active or revoked respectively.
multihash (optional): Multihash identifier. By default it uses de ianaName.

Examples:

timestamp updateHashAlgorithm 1 256 sha-256 2.16.840.1.101.3.4.2.1 1 sha2-256
timestamp updateHashAlgorithm 7 512 sha3-512 2.16.840.1.101.3.4.2.10 1 sha3-512

timestamp (build-)timestampRecordHashes <data> <info>

Command to timestamp data and create a record of it with some info. The JWT is set in the headers.

Use the build- prefix to call the API helper to build the transaction. If this prefix is not set then the command will perform the following steps:

call timestamp build-timestampRecordHashes to build an unsigned transaction.
call compute signTransaction to sign the transaction with the user defined in using user.
call timestamp sendSignedTransaction to send the transaction signed.
call view transactionInfo to see relevant data for this transaction.

Params:

data (optional): JSON data to timestamp. By default it creates random data.
info (optional): JSON info to insert in the record. By default it creates random data.

Examples:

timestamp timestampRecordHashes
timestamp timestampRecordHashes {"data":"my data"} {"info":"test"}

timestamp (build-)timestampVersionHashes <previousHash> <data> <info>

Command to create a new version of an existing record given the previous version hash. This new version is timestamped. Use it when you don't have the recordId but you have the hash that was timestamped in the previous version. You can not use this function if several records share the same hash, for such cases use timestampRecordVersionHashes. The JWT is set in the headers. Only record owners are allowed to perform this operation.

Use the build- prefix to call the API helper to build the transaction. If this prefix is not set then the command will perform the following steps:

call timestamp build-timestampVersionHashes to build an unsigned transaction.
call compute signTransaction to sign the transaction with the user defined in using user.
call timestamp sendSignedTransaction to send the transaction signed.
call view transactionInfo to see relevant data for this transaction.

Params:

previousHash: Hash timestamped in a previous version
data (optional): JSON data to timestamp. By default it creates random data.
info (optional): JSON info to insert in the new version of the record. By default it creates random data.

Examples:

timestamp timestampVersionHashes 0x12f5...
timestamp timestampVersionHashes 0x12f5... {"data":"my data"} {"info":"test"}

timestamp (build-)timestampRecordVersionHashes <recordId> <data> <info>

Command to create a new version of an existing record. This new version is timestamped. The JWT is set in the headers. Only record owners are allowed to perform this operation.

Use the build- prefix to call the API helper to build the transaction. If this prefix is not set then the command will perform the following steps:

call timestamp build-timestampRecordVersionHashes to build an unsigned transaction.
call compute signTransaction to sign the transaction with the user defined in using user.
call timestamp sendSignedTransaction to send the transaction signed.
call view transactionInfo to see relevant data for this transaction.

Params:

recordId: Record ID in hex string format
data (optional): JSON data to timestamp. By default it creates random data.
info (optional): JSON info to insert in the new version of the record. By default it creates random data.

Examples:

timestamp timestampRecordVersionHashes 0x12f5...
timestamp timestampRecordVersionHashes 0x12f5... {"data":"my data"} {"info":"test"}

timestamp (build-)insertRecordOwner <recordId> <ownerId> <notBefore> <notAfter>

Command to insert a new owner in an existing record. The JWT is set in the headers. Only record owners are allowed to perform this operation.

Use the build- prefix to call the API helper to build the transaction. If this prefix is not set then the command will perform the following steps:

call timestamp build-insertRecordOwner to build an unsigned transaction.
call compute signTransaction to sign the transaction with the user defined in using user.
call timestamp sendSignedTransaction to send the transaction signed.
call view transactionInfo to see relevant data for this transaction.

Params:

recordId: Record ID in hex string format
ownerId: Ethereum address of new owner.
notBefore (optional): Point in time when the owner becomes valid. It should be defined in epoch time. By default it takes the actual time.
notAfter (optional): Point in time when the owner becomes invalid. It should be defined in epoch time. By default it is 0 (indefinite).

Examples:

timestamp insertRecordOwner 0x12f5... 0xab54...
timestamp insertRecordOwner 0x12f5... 0xab54... 1625568669 1657104669

timestamp (build-)revokeRecordOwner <recordId> <ownerId>

Command to revoke new owner from an existing record and put it in the revoked list. The JWT is set in the headers. Only record owners are allowed to perform this operation.

Use the build- prefix to call the API helper to build the transaction. If this prefix is not set then the command will perform the following steps:

call timestamp build-revokeRecordOwner to build an unsigned transaction.
call compute signTransaction to sign the transaction with the user defined in using user.
call timestamp sendSignedTransaction to send the transaction signed.
call view transactionInfo to see relevant data for this transaction.

Params:

recordId: Record ID in hex string format.
ownerId: Ethereum address of the owner to revoke.

Examples:

timestamp revokeRecordOwner 0x12f5... 0xab54...

timestamp (build-)insertRecordVersionInfo <recordId> <versionId> <info>

Command to insert new info to a version of an existing record. The JWT is set in the headers. Only record owners are allowed to perform this operation.

Use the build- prefix to call the API helper to build the transaction. If this prefix is not set then the command will perform the following steps:

call timestamp build-insertRecordVersionInfo to build an unsigned transaction.
call compute signTransaction to sign the transaction with the user defined in using user.
call timestamp sendSignedTransaction to send the transaction signed.
call view transactionInfo to see relevant data for this transaction.

Params:

recordId: Record ID in hex string format.
versionId: Number of the version.
info (optional): JSON info to insert in the version.

Examples:

timestamp insertRecordVersionInfo 0x12f5... 1
timestamp insertRecordVersionInfo 0x12f5... 1 {"info":"test"}

timestamp (build-)detachRecordVersionHash <recordId> <versionId> <hash>

Command to remove a hash from a version of an existing record. The JWT is set in the headers. Only record owners are allowed to perform this operation.

Use the build- prefix to call the API helper to build the transaction. If this prefix is not set then the command will perform the following steps:

call timestamp build-detachRecordVersionHash to build an unsigned transaction.
call compute signTransaction to sign the transaction with the user defined in using user.
call timestamp sendSignedTransaction to send the transaction signed.
call view transactionInfo to see relevant data for this transaction.

Params:

recordId: Record ID in hex string format.
versionId: Number of the version.
hash: Hash of timestamp to detach.

Examples:

timestamp detachRecordVersionHash 0x12f5... 1 0xfd45...

timestamp (build-)appendRecordVersionHashes <recordId> <versionId> <data> <info>

Command to include more hashes to an existing version. For instance, use it if you want to have different hashes (sha2-256, sha3-512, etc) of the same data. The JWT is set in the headers. Only record owners are allowed to perform this operation.

DISCLAIMER: In the current version the CLI the "data" is hashed with sha2-256. Future versions will include more algorithms.

Use the build- prefix to call the API helper to build the transaction. If this prefix is not set then the command will perform the following steps:

call timestamp build-appendRecordVersionHashes to build an unsigned transaction.
call compute signTransaction to sign the transaction with the user defined in using user.
call timestamp sendSignedTransaction to send the transaction signed.
call view transactionInfo to see relevant data for this transaction.

Params:

recordId: Record ID in hex string format
versionId: Number of the version.
data (optional): JSON data to timestamp. By default it creates random data.
info (optional): JSON info to append in the version of the record. By default it creates random data.

Examples:

timestamp appendRecordVersionHashes 0x12f5... 1
timestamp appendRecordVersionHashes 0x12f5... 1 {"data":"my data"} {"info":"test"}

timestamp (build-)timestampHashes <data>

Command to timestamp data. The JWT is set in the headers.

Use the build- prefix to call the API helper to build the transaction. If this prefix is not set then the command will perform the following steps:

call timestamp build-timestampHashes to build an unsigned transaction.
call compute signTransaction to sign the transaction with the user defined in using user.
call timestamp sendSignedTransaction to send the transaction signed.
call view transactionInfo to see relevant data for this transaction.

Params:

data (optional): JSON data to timestamp. By default it creates random data.

Examples:

timestamp timestampHashes
timestamp timestampHashes {"data":"my data"}

timestamp sendSignedTransaction <unsignedTransaction> <signedTransaction>

Command to send a signed transaction to the Timestamp Registry. The JWT is set in the headers. It's also possible to load the parameters from the saved variables by referencing the names.

Params:

unsignedTransaction: JSON with the unsigned transaction.
signedTransaction: Signed transaction in raw format.

Examples:

timestamp sendSignedTransaction {"from":"0x6b...} 0xf9022...
timestamp sendSignedTransaction utx sgntx

Trusted Apps Registry API

tar get <url>

Command to GET in the Trusted Apps Registry API. All endpoints are open to the public.

Params:

url: Path to get.

Examples:

tar get /apps
tar get /apps?public_key_id=0x3f...
tar get /apps/ledger-api/authorizations?requesterApplicationId=0x45...
tar get /policies

tar (build-)insertPolicy <name> <data>

Command to insert a policy. The JWT is set in the headers. This method requires admin rights in the Trusted Apps Registry.

Use the build- prefix to call the API helper to build the transaction. If this prefix is not set then the command will perform the following steps:

call tar build-insertPolicy to build an unsigned transaction.
call compute signTransaction to sign the transaction with the user defined in using user.
call tar sendSignedTransaction to send the transaction signed.
call view transactionInfo to see relevant data for this transaction.

Params:

name (optional): Name of the policy. By default it uses a random name.
data (optional): JSON data to store in the policy. By default it uses random data.

Examples:

tar insertPolicy
tar insertPolicy my-policy {"name":"my policy"}

tar (build-)updatePolicy <name> <data>

Command to update an existing policy. The JWT is set in the headers. This method requires admin rights in the Trusted Apps Registry.

Use the build- prefix to call the API helper to build the transaction. If this prefix is not set then the command will perform the following steps:

call tar build-updatePolicy to build an unsigned transaction.
call compute signTransaction to sign the transaction with the user defined in using user.
call tar sendSignedTransaction to send the transaction signed.
call view transactionInfo to see relevant data for this transaction.

Params:

name: Name of the policy.
data (optional): JSON data to store in the policy. By default it uses random data.

Examples:

tar updatePolicy my-policy {"name":"my policy"}

tar (build-)insertAuthorization <appName> <authorizedAppName> <issuer> <status> <permissions> <notBefore> <notAfter>

Command to insert a new authorization. The JWT is set in the headers. This method requires admin rights in the Trusted Apps Registry.

Use the build- prefix to call the API helper to build the transaction. If this prefix is not set then the command will perform the following steps:

call tar build-insertAuthorization to build an unsigned transaction.
call compute signTransaction to sign the transaction with the user defined in using user.
call tar sendSignedTransaction to send the transaction signed.
call view transactionInfo to see relevant data for this transaction.

Params:

appName: Resource application name.
authorizedAppName: Application that will have access to the resource application.
issuer (optional): DID of the issuer. By default it takes the DID defined in using user.
status (optional): Status. It must be 1 (default), 2, or 3 which corresponds with active, revoked, or suspended respectively.
permissions (optional): CRUD permissions. It must be a number between 0 and 15 (default). It's binary representation enables or disables each one of the 4 CRUD permissions (create, read, update, delete).
notBefore (optional): Point in time when the authorization becomes valid. It should be defined in epoch time. By default it takes the actual time.
notAfter (optional): Point in time when the authorization becomes invalid. It should be defined in epoch time. By default it is 0 (indefinite).

Examples:

tar insertAuthorization ledger-api my-app
tar insertAuthorization ledger-api my-app did:ebsi:zkqR9GCLrLYbkubAjuqQZAz 1 15 1625568669 1657104669

tar (build-)updateAuthorization <id> <status> <permissions> <notAfter>

Command to update an authorization. The JWT is set in the headers. This method requires admin rights in the Trusted Apps Registry.

Use the build- prefix to call the API helper to build the transaction. If this prefix is not set then the command will perform the following steps:

call tar build-updateAuthorization to build an unsigned transaction.
call compute signTransaction to sign the transaction with the user defined in using user.
call tar sendSignedTransaction to send the transaction signed.
call view transactionInfo to see relevant data for this transaction.

Params:

id: Authorization ID.
status (optional): Status. It must be 1 (default), 2, or 3 which corresponds with active, revoked, or suspended respectively.
permissions (optional): CRUD permissions. It must be a number between 0 and 15 (default). It's binary representation enables or disables each one of the 4 CRUD permissions (create, read, update, delete).
notAfter (optional): Point in time when the did method becomes invalid. It should be defined in epoch time. By default it is 0 (indefinite).

Examples:

tar updateAuthorization 0x12...4f
tar updateAuthorization 0x12...4f 1 15 1657104669

tar (build-)insertApp <name> <appAdministrator>

Command to insert a new app in the Trusted Apps Registry. The JWT is set in the headers. This method requires admin rights in the Trusted Apps Registry.

Use the build- prefix to call the API helper to build the transaction. If this prefix is not set then the command will perform the following steps:

call tar build-insertApp to build an unsigned transaction.
call compute signTransaction to sign the transaction with the user defined in using user.
call tar sendSignedTransaction to send the transaction signed.
call view transactionInfo to see relevant data for this transaction.

Params:

name: Name of the new app.
appAdministrator (optional): Did of app administrator. By default it takes the did defined in the command using user.

Examples:

tar insertApp my-app did:ebsi:znbuGDt6tEqpGZNAuGc2uvZ

tar (build-)updateApp <id> <name> <domain>

Command to update an existing app. The JWT is set in the headers. This method requires admin rights in the Trusted Apps Registry.

Use the build- prefix to call the API helper to build the transaction. If this prefix is not set then the command will perform the following steps:

call tar build-updateApp to build an unsigned transaction.
call compute signTransaction to sign the transaction with the user defined in using user.
call tar sendSignedTransaction to send the transaction signed.
call view transactionInfo to see relevant data for this transaction.

Params:

id: Application ID
name: New name.
domain (optional): New domain. It must be 1 (default) or 2, which corresponds with "ebsi" and "external" respectively.

Examples:

tar updateApp 0x123...fe5 new-name
tar updateApp 0x123...fe5 new-name 2

tar (build-)insertAppInfo <id> <info>

Command to insert info in an existing app. The JWT is set in the headers. This method requires admin rights in the Trusted Apps Registry.

Use the build- prefix to call the API helper to build the transaction. If this prefix is not set then the command will perform the following steps:

call tar build-insertAppInfo to build an unsigned transaction.
call compute signTransaction to sign the transaction with the user defined in using user.
call tar sendSignedTransaction to send the transaction signed.
call view transactionInfo to see relevant data for this transaction.

Params:

id: Application ID
info: JSON info.

Examples:

tar insertAppInfo 0x123...fe5 {"name":"my app"}

tar (build-)insertAppPublicKey <id> <publicKey> <status> <notBefore> <notAfter>

Command to insert a new public key in an app. The JWT is set in the headers. This method requires admin rights in the Trusted Apps Registry.

Use the build- prefix to call the API helper to build the transaction. If this prefix is not set then the command will perform the following steps:

call tar build-insertAppPublicKey to build an unsigned transaction.
call compute signTransaction to sign the transaction with the user defined in using user.
call tar sendSignedTransaction to send the transaction signed.
call view transactionInfo to see relevant data for this transaction.

Params:

id: Application ID
publicKey: Public key. Insert base64 representation of PEM string.
status (optional): Status. It must be 1 (default), 2, or 3 which corresponds with active, revoked, or suspended respectively.
notBefore (optional): Point in time when the public key becomes valid. It should be defined in epoch time. By default it takes the actual time.
notAfter (optional): Point in time when the public key becomes invalid. It should be defined in epoch time. By default it is 0 (indefinite).

Examples:

tar insertAppPublicKey LS0tLS1...
tar insertAppPublicKey LS0tLS1... 1 1625568669 1657104669

tar (build-)updateAppPublicKey <id> <status> <notAfter>

Command to update an existing public key. The JWT is set in the headers. This method requires admin rights in the Trusted Apps Registry.

Use the build- prefix to call the API helper to build the transaction. If this prefix is not set then the command will perform the following steps:

call tar build-updateAppPublicKey to build an unsigned transaction.
call compute signTransaction to sign the transaction with the user defined in using user.
call tar sendSignedTransaction to send the transaction signed.
call view transactionInfo to see relevant data for this transaction.

Params:

id: Public key ID
status (optional): Status. It must be 1 (default), 2, or 3 which corresponds with active, revoked, or suspended respectively.
notAfter (optional): Point in time when the public key becomes invalid. It should be defined in epoch time. By default it is 0 (indefinite).

Examples:

tar updateAppPublicKey 0x45...f1
tar updateAppPublicKey 0x45...f1 1 1657104669

tar (build-)insertAppAdministrator <id> <didAdmin>

Command to insert an app administrator to an existing app. The JWT is set in the headers. This method requires admin rights in the Trusted Apps Registry.

Use the build- prefix to call the API helper to build the transaction. If this prefix is not set then the command will perform the following steps:

call tar build-insertAppAdministrator to build an unsigned transaction.
call compute signTransaction to sign the transaction with the user defined in using user.
call tar sendSignedTransaction to send the transaction signed.
call view transactionInfo to see relevant data for this transaction.

Params:

id: Application ID.
didAdmin: DID of new app admin.

Examples:

tar insertAppAdministrator 0x45...f1 did:ebsi:zkqR9GCLrLYbkubAjuqQZAz

tar (build-)deleteAppAdministrator <id> <didAdmin>

Command to delete an app administrator from an existing app. The JWT is set in the headers. This method requires admin rights in the Trusted Apps Registry.

Use the build- prefix to call the API helper to build the transaction. If this prefix is not set then the command will perform the following steps:

call tar build-deleteAppAdministrator to build an unsigned transaction.
call compute signTransaction to sign the transaction with the user defined in using user.
call tar sendSignedTransaction to send the transaction signed.
call view transactionInfo to see relevant data for this transaction.

Params:

id: Application ID.
didAdmin: DID to delete from app admins.

Examples:

tar deleteAppAdministrator 0x45...f1 did:ebsi:zkqR9GCLrLYbkubAjuqQZAz

tar (build-)insertRevocation <id> <revokedBy> <notBefore>

Command to revoke an app. It will be moved to the revocation list. The JWT is set in the headers. This method requires admin rights in the Trusted Apps Registry.

Use the build- prefix to call the API helper to build the transaction. If this prefix is not set then the command will perform the following steps:

call tar build-insertRevocation to build an unsigned transaction.
call compute signTransaction to sign the transaction with the user defined in using user.
call tar sendSignedTransaction to send the transaction signed.
call view transactionInfo to see relevant data for this transaction.

Params:

id: Application ID.
revokedBy: DID of the admin performing the revocation.
notBefore (optional): Point in time when the app becomes revoked. It should be defined in epoch time. By default it takes the actual time.

Examples:

tar insertRevocation 0x45...f1 did:ebsi:zkqR9GCLrLYbkubAjuqQZAz
tar insertRevocation 0x45...f1 did:ebsi:zkqR9GCLrLYbkubAjuqQZAz 1625568669

tar sendSignedTransaction <unsignedTransaction> <signedTransaction>

Command to send a signed transaction to the Trusted Apps Registry. The JWT is set in the headers. It's also possible to load the parameters from the saved variables by referencing the names.

Params:

unsignedTransaction: JSON with the unsigned transaction.
signedTransaction: Signed transaction in raw format.

Examples:

tar sendSignedTransaction {"from":"0x6b...} 0xf9022...
tar sendSignedTransaction utx sgntx

Trusted Issuers Registry API

OpenAPI documentation

tir get <url>

Command to GET in the Trusted Issuers Registry API.

Params:

url: Path to get.

Examples:

tir get /issuers
tir get /issuers/did:ebsi:12a...
tir get /policies

tir (build-)insertPolicy <name> <data>

Command to insert a policy. The JWT is set in the headers. This method requires admin rights in the Trusted Issuers Registry.

Use the build- prefix to call the API helper to build the transaction. If this prefix is not set then the command will perform the following steps:

call tir build-insertPolicy to build an unsigned transaction.
call compute signTransaction to sign the transaction with the user defined in using user.
call tir sendSignedTransaction to send the transaction signed.
call view transactionInfo to see relevant data for this transaction.

Params:

name (optional): Name of the policy. By default it uses a random name.
data (optional): JSON data to store in the policy. By default it uses random data.

Examples:

tir insertPolicy
tir insertPolicy my-policy {"name":"my policy"}

tir (build-)updatePolicy <name> <data>

Command to update an existing policy. The JWT is set in the headers. This method requires admin rights in the Trusted Issuers Registry.

Use the build- prefix to call the API helper to build the transaction. If this prefix is not set then the command will perform the following steps:

call tir build-updatePolicy to build an unsigned transaction.
call compute signTransaction to sign the transaction with the user defined in using user.
call tir sendSignedTransaction to send the transaction signed.
call view transactionInfo to see relevant data for this transaction.

Params:

name: Name of the policy.
data (optional): JSON data to store in the policy. By default it uses random data.

Examples:

tir updatePolicy my-policy {"name":"my policy"}

tir (build-)insertIssuer <did> <attribute>

Command to insert a new issuer in the registry. The JWT is set in the headers. This method requires admin rights in the Trusted Issuers Registry.

Use the build- prefix to call the API helper to build the transaction. If this prefix is not set then the command will perform the following steps:

call tir build-insertIssuer to build an unsigned transaction.
call compute signTransaction to sign the transaction with the user defined in using user.
call tir sendSignedTransaction to send the transaction signed.
call view transactionInfo to see relevant data for this transaction.

Params:

did: DID of the new issuer.
attribute: VC JWT, JSON attribute or buffer expressed as hex string.

Examples:

tir insertIssuer did:ebsi:zkqR9GCLrLYbkubAjuqQZAz ey...
tir insertIssuer did:ebsi:zkqR9GCLrLYbkubAjuqQZAz {"institution":"eu"}
tir insertIssuer did:ebsi:zkqR9GCLrLYbkubAjuqQZAz ef1256ea058df9

tir (build-)updateIssuer <did> <attribute> <prevAttributeHash>

Command to update the attribute to an existing issuer. The JWT is set in the headers. This method requires admin rights in the Trusted Issuers Registry.

Use the build- prefix to call the API helper to build the transaction. If this prefix is not set then the command will perform the following steps:

call tir build-updateIssuer to build an unsigned transaction.
call compute signTransaction to sign the transaction with the user defined in using user.
call tir sendSignedTransaction to send the transaction signed.
call view transactionInfo to see relevant data for this transaction.

Params:

did: DID of the administrator.
attribute: VC JWT, JSON attribute or buffer expressed as hex string.
prevAttributeHash (optional): Hash of the previous attribute. If it's not set a new attribute will be added.

Examples:

tir updateIssuer did:ebsi:zkqR9GCLrLYbkubAjuqQZAz
tir updateIssuer did:ebsi:zkqR9GCLrLYbkubAjuqQZAz {"name":"alice"}
tir updateIssuer did:ebsi:zkqR9GCLrLYbkubAjuqQZAz ey...

tir sendSignedTransaction <unsignedTransaction> <signedTransaction>

Command to send a signed transaction to the Trusted Issuers Registry. The JWT is set in the headers. It's also possible to load the parameters from the saved variables by referencing the names.

Params:

unsignedTransaction: JSON with the unsigned transaction.
signedTransaction: Signed transaction in raw format.

Examples:

tir sendSignedTransaction {"from":"0x6b...} 0xf9022...
tir sendSignedTransaction utx sgntx

Trusted Schemas Registry API

OpenAPI documentation

tsr get <url>

Command to GET in the Trusted Schemas Registry API.

Params:

url: Path to get.

Examples:

tsr get /schemas
tsr get /schemas/0x12f...
tsr get /policies

tsr (build-)insertPolicy <name> <data>

Command to insert a policy. The JWT is set in the headers. This method requires admin rights in the Trusted Schemas Registry.

Use the build- prefix to call the API helper to build the transaction. If this prefix is not set then the command will perform the following steps:

call tsr build-insertPolicy to build an unsigned transaction.
call compute signTransaction to sign the transaction with the user defined in using user.
call tsr sendSignedTransaction to send the transaction signed.
call view transactionInfo to see relevant data for this transaction.

Params:

name (optional): Name of the policy. By default it uses a random name.
data (optional): JSON data to store in the policy. By default it uses random data.

Examples:

tsr insertPolicy
tsr insertPolicy my-policy {"name":"my policy"}

tsr (build-)updatePolicy <name> <data>

Command to update an existing policy. The JWT is set in the headers. This method requires admin rights in the Trusted Schemas Registry.

Use the build- prefix to call the API helper to build the transaction. If this prefix is not set then the command will perform the following steps:

call tsr build-updatePolicy to build an unsigned transaction.
call compute signTransaction to sign the transaction with the user defined in using user.
call tsr sendSignedTransaction to send the transaction signed.
call view transactionInfo to see relevant data for this transaction.

Params:

name: Name of the policy.
data (optional): JSON data to store in the policy. By default it uses random data.

Examples:

tsr updatePolicy my-policy {"name":"my policy"}

tsr (build-)insertSchema <schema> <metadata>

Command to insert a new schema. The JWT is set in the headers. This method requires admin rights in the Trusted Schemas Registry. The schema id is computed based on the schema (see schema lifecycle).

Use the build- prefix to call the API helper to build the transaction. If this prefix is not set then the command will perform the following steps:

call tsr build-insertSchema to build an unsigned transaction.
call compute signTransaction to sign the transaction with the user defined in using user.
call tsr sendSignedTransaction to send the transaction signed.
call view transactionInfo to see relevant data for this transaction.

Params:

schema (optional): JSON schema. By default it uses a random schema.
metadata (optional): JSON metadata. By default is uses random metadata.

Examples:

tsr insertSchema
tsr insertSchema {"@context":"ebsi.eu","type":"schema"} {"metadata":"data"}

tsr (build-)updateSchema <schemaId> <schema> <metadata>

Command to update an schema. The JWT is set in the headers. This method requires admin rights in the Trusted Schemas Registry.

Use the build- prefix to call the API helper to build the transaction. If this prefix is not set then the command will perform the following steps:

call tsr build-updateSchema to build an unsigned transaction.
call compute signTransaction to sign the transaction with the user defined in using user.
call tsr sendSignedTransaction to send the transaction signed.
call view transactionInfo to see relevant data for this transaction.

Params:

schemaId: Schema ID.
schema (optional): JSON schema. By default it uses a random schema.
metadata (optional): JSON metadata. By default is uses random metadata.

Examples:

tsr updateSchema
tsr updateSchema 0x12f... {"@context":"ebsi.eu","type":"schema"} {"metadata":"data"}

tsr sendSignedTransaction <unsignedTransaction> <signedTransaction>

Command to send a signed transaction to the Trusted Schemas Registry. The JWT is set in the headers. It's also possible to load the parameters from the saved variables by referencing the names.

Params:

unsignedTransaction: JSON with the unsigned transaction.
signedTransaction: Signed transaction in raw format.

Examples:

tsr sendSignedTransaction {"from":"0x6b...} 0xf9022...
tsr sendSignedTransaction utx sgntx

New and old APIs

The CLI tool supports the connection to the previous and new API versions.

To access previous versions use the suffix -old in the command name. To access the new versions use the suffix -new in the command name.

Example:

==> tir-old get /issuers
GET https://api-pilot.ebsi.eu/trusted-issuers-registry/v3/issuers
...

==> tir get /issuers
GET https://api-pilot.ebsi.eu/trusted-issuers-registry/v4/issuers
...

==> tir-new get /issuers
GET https://api-pilot.ebsi.eu/trusted-issuers-registry/v5/issuers
...

Set, Using, View, Env, Run, Exit​

Compute​

Conformance​

Authorisation API​

Ledger API​

DID Registry API​

Timestamp API​

Trusted Apps Registry API​

Trusted Issuers Registry API​

Trusted Schemas Registry API​

New and old APIs​

Set, Using, View, Env, Run, Exit

Compute

Conformance

Authorisation API

Ledger API

DID Registry API

Timestamp API

Trusted Apps Registry API

Trusted Issuers Registry API

Trusted Schemas Registry API

New and old APIs