Skip to content

migration-guide-1.13.0-1.14.0.md

Latest commit

 

History

History
121 lines (93 loc) · 5.11 KB

migration-guide-1.13.0-1.14.0.md

File metadata and controls

121 lines (93 loc) · 5.11 KB
Raw

Libindy 1.13 to 1.14 migration Guide

This document is written for developers using Libindy to provide necessary information and to simplify their transition to Libindy 1.13 from Libindy 1.14. If you are using older Libindy version you can check migration guides history:

Table of contents

Libindy 1.13 to 1.14 migration

Ledger API

The v1.14 release contains some changes related to transaction author agreement functionality.

This changes allow to user to review and accept the TAA in advance of it being written to the ledger. Thus when we submit a transaction we can report the real date of meaningful acceptance, instead of an arbitrary date engineered to be newer than when the TAA is added.

The TAA could be legally accepted at any point after the TAA is approved by network governance.

There are two changes related to Libindy Ledger API:

  • extended definition of indy_build_txn_author_agreement_request to accept new parameters:

    • ratification_ts - the date (timestamp) of TAA ratification by network government.
    • retirement_ts - the date (timestamp) of TAA retirement.

    Please take a look that this breaks API regarding earlier Libindy versions.

  • added a new function indy_build_disable_all_txn_author_agreements_request to build DISABLE_ALL_TXN_AUTHR_AGRMTS request. Request to disable all Transaction Author Agreement on the ledger.

More details regarding updated transaction author agreement workflow you can find in this file.

Libindy 1.14.0 to 1.14.1 migration Guide

The Libindy 1.14.1 release contains fixes that don't affect API functions.

Libindy 1.14.1 to 1.14.2 migration Guide

The Libindy 1.14.1 release contains fixes that don't affect API functions.

Changes

  • Updated behavior of indy_store_their_did function to allow updating of existing theirDID record. It can be used to rotate a pairwise key (IS-1166).

    This example works now but threw WalletItemAlreadyExists error in previous versions:

    let identity_json = json!({"did": DID, "verkey": VERKEY}).to_string();
did::store_their_did(setup.wallet_handle, &identity_json).unwrap();

let identity_json = json!({"did": DID, "verkey": VERKEY_TRUSTEE}).to_string();
did::store_their_did(setup.wallet_handle, &identity_json).unwrap();

let verkey = did::key_for_local_did(setup.wallet_handle, DID).unwrap();
assert_eq!(VERKEY_TRUSTEE, verkey);

  • Enhanced validation of schema_json: added check that id is consistent with name and version values (IS-1430).

    valid:
{
    "id":"schema:sov:did:sov:NcYxiDXkpYi6ov5FcYDi1e:2:gvt:1.0",
    "name":"gvt",
    "version":"1.0",
    "attrNames":["aaa","bbb","ccc"],
    "ver":"1.0"
}
invalid:     
{
    "id":"schema:sov:did:sov:NcYxiDXkpYi6ov5FcYDi1e:2:gvt:1.0",
    "name":"other_name",
    "version":"1111.0",
    "attrNames":["aaa","bbb","ccc"],
    "ver":"1.0"
}

  • Added support of the additional format of rev_states_json which is used for proof creation. Both rev_reg_def_id and credential_id can be used as map keys.

    1)
{
  rev_reg_id: {
    timestamp: rev_reg_state,
    ..
  },
  ...
}
2)
{ 
  credential_id: {
    timestamp: rev_reg_state,
    ...
  },
 ...
}

credential_id must be used in case of proving that two credentials matching the same rev_reg_id are not revoked at the same timestamp (IS-1447).

  • others minor bugfixes