Now that you have a trust anchor identity, you can write or query any number of additional identities to the ledger, with just a handful of lines of code. Most of the code in this how-to exists to satisfy some preconditions. Run the completed demo and observe the whole sequence. You should see similarities between the way this query “transaction” and the preceding write transaction are bundled and sent. Only a handful of lines of code matter to our goal here the rest of this block is comments and boilerplate cleanup (which you should not omit!). Once we have an identity on the ledger, we can query it.Ĭopy the contents of step5.java into WriteDIDAndQueryVerkey.java on top of the Step 5 code goes here placeholder comment.Save the updated version of WriteDIDAndQueryVerkey.java. Now that preparations are complete, we can finally write the DID and verkey for our trust anchor identity to the ledger.Ĭopy the contents of step4.java into WriteDIDAndQueryVerkey.java on top of the Step 4 code goes here placeholder comment.Save the updated version of WriteDIDAndQueryVerkey.java. In a production indy pool such as the Sovrin “live” network, the bootstrapping steward identities would not have known the seeds. This is why we use a hard-coded seed when creating the steward DID–it guarantees that the same DID and key material are created that the genesis transactions expect. We will use this steward’s signing key to create our next DID–the one for our trust anchor, which is truly new. But we have to also put the DID, verkey, and private signing key (which the ledger doesn’t know) into our wallet, so we can use the signing key to submit an acceptably signed transaction to the ledger. This is because the steward DID and its verkey are already in the ledger they were part of the genesis transactions we told the SDK to start with in the previous step. Notice that the steward DID is created with a seed, but the trust anchor DID is not. The steward identity is a bootstrapping step, whereas the trust anchor DID is the one we will query later. Here, we are populating our identity wallet with DID+keypair material for one steward identity and one trust anchor identity. A trust anchor DID can add arbitrary DIDs to the ledger. For example, an DID that is a steward can add a node (the one they own) to the validator pool, and can create DIDs with a trust anchor role. Copy the contents of step3.java into WriteDIDAndQueryVerkey.java on top of the Step 3 code goes here placeholder comment.Save the updated version of WriteDIDAndQueryVerkey.java.Ī few operations in indy can only be done by identities (DIDs) with special roles. Now we need to put some DIDs and keys in our identity wallet. Scaffolding code like this is likely to appear in anything that uses indy. We also need to create an identity wallet, so the SDK can store the DID and key material generated during the tutorial.Ĭopy the contents of step2.java into WriteDIDAndQueryVerkey.java on top of the Step 2 code goes here placeholder comment.Save the updated version of WriteDIDAndQueryVerkey.java. This requires us to point the SDK at some genesis transactions that tell the SDK how to contact the ledger on the network, and how to trust that the nodes it contacts possess appropriate keys. Now we need to give the SDK some context that it will need to deal with an indy ledger. This is a very simple app framework into which you’ll plug the code you’ll be writing. Save the doc as WriteDIDAndQueryVerkey.java We will be modifying this code in later steps. In your normal workstation operating system (not the VM), open a java editor of your choice and paste the code from template.java into a new doc. Setup your workstation with an indy development virtual machine (VM). Indy-SDK Developer Walkthrough #1, Java Edition Write a DID and Query Its Verkey Rotate a Key Save a Schema and Cred Def Issue a Credential Negotiate a Proof Send a Secure Message 1、 Write a DID and Query Its Verkey
0 Comments
Leave a Reply. |