Defining my own claim schema's


#1

[I’m a Sovrin noob and this is my first post, so apologies if it isn’t according to the proper etiquette…]

Digging in the source code, I found the way to define your own claim schema’s:

  1. spin a client agent
  2. connect to the test/live environment
  3. execute the following command: “send SCHEMA name= version= keys=”

I get an error however:
error occurred during operation: client request invalid: CouldNotAuthenticate('Can not find verkey for DID ',)

Do I need to register the DID somewhere first? Can someone point me to a place where creating and managing your own custom claims is explained properly and thoroughly, please?


#2

Hi Patrice,

Welcome to Sovrin.

You are on the right path. Here is what you are missing. Before sending the schema, you need to establish your identity with the client, so that it can digitally sign your submission. In order to send a schema, you need to be a “trust anchor”. On a test environment such as a validator network that is created via the vagrant method, you would do the following on a client node:

  1. Get onto the Sovrin CLI
    $ sovrin
  2. Connect to the test network
    sovrin> connect test
  3. Generate random credentials that will be used for the trust anchor
    sovrin@test> new key
  4. Establish yourself as a steward
    sovrin@test> new key with seed 000000000000000000000000Steward1
  5. Put the trust anchor credentials onto the ledger
    send NYM dest=<DID_from_step_3> role=TRUST_ANCHOR verkey=<verkey_from_step_3>
  6. quit out of the CLI

Now that the trust anchor credentials are on the ledger, you can do what you wanted, with one additional step:

  1. Get onto the Sovrin CLI
    $ sovrin
  2. Connect to the test network
    sovrin> connect test
  3. Establish yourself as the trust anchor
    sovrin@test> use DID <DID_from_previous_step_3>
  4. Send the schema

Notes:

The steward used is a well-known one that is created in the vagrant scripts for a test network. It does not exist on other networks. If you were doing this on another network, you would need to use a valid steward’s credentials for that network to set up a trust anchor.

“new key” creates a public / private key pair, puts the private key into a local “wallet” for the CLI to use, and establishes that entity as the current user for signing messages sent to the ledger.

“use DID” establishes a user who’s private key already exists in the wallet as the current user for signing messages sent to the ledger.


#3

Thank you for the very specific guidance. It totally did the job!