forked from hyperledger-archives/indy-sdk
-
Notifications
You must be signed in to change notification settings - Fork 0
/
step2.js
77 lines (63 loc) · 4.01 KB
/
step2.js
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
// Tell SDK which pool you are going to use. You should have already started
// this pool using docker compose or similar. Here, we are dumping the config
// just for demonstration purposes.
// 1.
log('1. Creates a new local pool ledger configuration that is used later when connecting to ledger.')
const poolName = 'pool'
const genesisFilePath = await util.getPoolGenesisTxnPath(poolName)
const poolConfig = {'genesis_txn': genesisFilePath}
await indy.createPoolLedgerConfig(poolName, poolConfig)
// 2.
log('2. Open pool ledger and get handle from libindy')
const poolHandle = await indy.openPoolLedger(poolName, undefined)
// 3.
log('3. Creating new secure wallet with the given unique name')
const walletConfig = {"id": "wallet"}
const walletCredentials = {"key": "wallet_key"}
await indy.createWallet(walletConfig, walletCredentials)
// 4.
log('4. Open wallet and get handle from libindy to use in methods that require wallet access')
const walletHandle = await indy.openWallet(walletConfig, walletCredentials)
// First, put a steward DID and its keypair in the wallet. This doesn't write anything to the ledger,
// but it gives us a key that we can use to sign a ledger transaction that we're going to submit later.
// The DID and public verkey for this steward key are already in the ledger; they were part of the genesis
// transactions we told the SDK to start with in the previous step. But we have to also put the DID, verkey,
// and private signing key into our wallet, so we can use the signing key to submit an acceptably signed
// transaction to the ledger, creating our *next* DID (which is truly new). This is why we use a hard-coded seed
// when creating this DID--it guarantees that the same DID and key material are created that the genesis txns
// expect.
// 5.
log('5. Generating and storing steward DID and verkey')
const stewardSeed = '000000000000000000000000Steward1'
const did = {'seed': stewardSeed}
const [stewardDid, stewardVerkey] = await indy.createAndStoreMyDid(walletHandle, did)
logValue('Steward DID: ', stewardDid)
logValue('Steward Verkey: ', stewardVerkey)
// Now, create a new DID and verkey for a trust anchor, and store it in our wallet as well. Don't use a seed;
// this DID and its keys are secure and random. Again, we're not writing to the ledger yet.
// 6.
log('6. Generating and storing trust anchor DID and verkey')
const [trustAnchorDid, trustAnchorVerkey] = await indy.createAndStoreMyDid(walletHandle, "{}")
logValue('Trust Anchor DID: ', trustAnchorDid)
logValue('Trust Anchor Verkey: ', trustAnchorVerkey)
// Here, we are building the transaction payload that we'll send to write the Trust Anchor identity to the ledger.
// We submit this transaction under the authority of the steward DID that the ledger already recognizes.
// This call will look up the private key of the steward DID in our wallet, and use it to sign the transaction.
// 7.
log('7. Building NYM request to add Trust Anchor to the ledger')
const nymRequest = await indy.buildNymRequest(/*submitter_did*/ stewardDid,
/*target_did*/ trustAnchorDid,
/*ver_key*/ trustAnchorVerkey,
/*alias*/ undefined,
/*role*/ 'TRUST_ANCHOR')
// Now that we have the transaction ready, send it. The building and the sending are separate steps because some
// clients may want to prepare transactions in one piece of code (e.g., that has access to privileged backend systems),
// and communicate with the ledger in a different piece of code (e.g., that lives outside the safe internal
// network).
// 8.
log('8. Sending NYM request to the ledger')
await indy.signAndSubmitRequest(/*pool_handle*/ poolHandle,
/*wallet_handle*/ walletHandle,
/*submitter_did*/ stewardDid,
/*request_json*/ nymRequest)
// At this point, we have successfully written a new identity to the ledger. Our next step will be to query it.