This document is written for developers using Libindy to provide necessary information and to simplify their transition to Libindy 1.11 from Libindy 1.10. If you are using older Libindy version you can check migration guides history:
- Libindy 1.3 to 1.4 migration
- Libindy 1.4 to 1.5 migration
- Libindy 1.5 to 1.6 migration
- Libindy 1.6 to 1.7 migration
- Libindy 1.7 to 1.8 migration
- Libindy 1.8 to 1.9 migration
- Libindy 1.9 to 1.10 migration
Migration information is organized in tables, there are mappings for each Libindy API part of how older version functionality maps to a newer one. Functions from older version are listed in the left column, and the equivalent newer version function is placed in the right column:
- If some function had been added, the word 'NEW' would be placed in the left column.
- If some function had been deleted, the word 'DELETED' would be placed in the right column.
- If some function had been deprecated, the word 'DEPRECATED' would be placed in the right column.
- If some function had been changed, the current format would be placed in the right column.
- If some function had not been changed, the symbol '=' would be placed in the right column.
- To get more details about current format of a function click on the description above it.
- Bellow are signatures of functions in Libindy C API.
The params of
cb
(except command_handle and err) will be result values of the similar function in any Libindy wrapper.
Migration information is organized in tables, there are mappings for each Libindy API part of how older version functionality maps to a newer one. Functions from older version are listed in the left column, and the equivalent newer version function is placed in the right column:
-
If some function had been added, the word 'NEW' would be placed in the left column.
-
If some function had been deleted, the word 'DELETED' would be placed in the right column.
-
If some function had been deprecated, the word 'DEPRECATED' would be placed in the right column.
-
If some function had been changed, the current format would be placed in the right column.
-
If some function had not been changed, the symbol '=' would be placed in the right column.
-
To get more details about current format of a function click on the description above it.
-
Bellow are signatures of functions in Libindy C API. The params of
cb
(except command_handle and err) will be result values of the similar function in any Libindy wrapper.<th colspan="2"> <a href="https://github.com/hyperledger/indy-sdk/blob/v1.11.0/libindy/src/api/payments.rs#L729"> Parses response for Indy request for getting sources list. </a> </th>
v1.10.0 - Payment API | v1.11.0 - Payment API |
---|---|
Signs a message with a payment address. | |
NEW |
indy_sign_with_address(command_handle: CommandHandle, wallet_handle: WalletHandle, address: *const c_char, message_raw: *const u8, message_len: u32, cb: fn(command_handle_: CommandHandle, err: ErrorCode, signature_raw: *const u8, signature_len: u32)) |
Verify a signature with a payment address. | |
NEW |
indy_verify_with_address(command_handle: CommandHandle, address: *const c_char, message_raw: *const u8, message_len: u32, signature_raw: *const u8, signature_len: u32, cb: fn(command_handle_: CommandHandle, err: ErrorCode, result: bool)) |
Builds Indy request for getting sources list for payment address according to this payment method. | |
NEW |
indy_build_get_payment_sources_with_from_request(command_handle: CommandHandle, wallet_handle: WalletHandle, submitter_did: *const c_char, payment_address: *const c_char, from: i64, cb: fn(command_handle_: CommandHandle, err: ErrorCode, get_sources_txn_json: *const c_char, payment_method: *const c_char)) |
Parses response for Indy request for getting sources list. | |
NEW |
indy_parse_get_payment_sources_with_from_response(command_handle: CommandHandle, payment_method: *const c_char, resp_json: *const c_char, cb: fn(command_handle_: CommandHandle, err: ErrorCode, sources_json: *const c_char, next: i64)) |
Builds Indy request for getting sources list for payment address according to this payment method. | |
indy_build_get_payment_sources_request(command_handle: CommandHandle, wallet_handle: WalletHandle, submitter_did: *const c_char, payment_address: *const c_char, cb: fn(command_handle_: CommandHandle, err: ErrorCode, get_sources_txn_json: *const c_char, payment_method: *const c_char)) |
DEPRECATED |
|
DEPRECATED |
Gets request requirements (with minimal price) correspondent to specific auth rule in case the requester can perform this action. | |
NEW |
indy_get_request_info(command_handle: CommandHandle, get_auth_rule_response_json: *const c_char, requester_info_json: *const c_char, fees_json: *const c_char, cb: fn(command_handle_: CommandHandle, err: ErrorCode, request_info_json: *const c_char)) |
Note that indy_register_payment_method
Payment API function was updated to accept:
- an additional callbacks correspondent to new functions to sign/verify a message with a payment address.
- callbacks correspondent to the new functions for getting payment sources with pagination support instead of deprecated.
-
Updated behavior of
indy_prover_create_proof
to create revocation proof based onnon_revoked
timestamps within a proof request. Now onlyprimary
proof can be built ifnon_revoked
intervals were not requested by a verifier. An example test can be found here:indy-sdk/libindy/tests/anoncreds_demos.rs/anoncreds_works_for_requested_proof_with_revocation_but_provided_primary_only
-
Added new Libindy API function
indy_generate_nonce
to generate a nonce of the size recommended for usage within a proof request. An example test can be found here:indy-sdk/libindy/tests/anoncreds_demos.rs/anoncreds_works_for_single_issuer_single_prover
-
Updated
indy_append_txn_author_agreement_acceptance_to_request
Libindy function to discard the time portion ofacceptance time
on appending TAA metadata into request. It was done cause too much time precision can lead to privacy risk.NOTE that if the following points are met:
- Indy Pool consists of nodes with version less 1.9.2
- Transaction Author Agreement is set on the Pool
Requests to the Pool will fail during the day TAA was set.
-
Updated
constraint
parameter ofindy_build_auth_rule_request
Libindy Ledger API function to accept new optionaloff_ledger_signature
field that specifies if a signature of unknown ledgerDID
is allowed for an action performing (false by default). -
Added new function
indy_append_request_endorser
to append Endorser to an existing request. It allows writing transactions to the ledger with preserving an original author but by different Endorser. An example flow can be found here An example test can be found here:indy-sdk/libindy/tests/ledger.rs/indy_send_request_by_endorser_works
- Extended
config
parameter ofindy_open_pool_ledger
function to acceptnumber_read_nodes
value. This value set the number of nodes to send read requests.
The main idea of changes performed in Anoncreds API is to provide a way to rotate the key of a Credential Definition stored into the wallet.
WARNING: Rotating the credential definitional keys will result in making all credentials issued under the previous keys unverifiable.
v1.11.0 - Anoncreds API | v1.11.1 - Anoncreds API |
---|---|
Generate temporary credential definitional keys for an existing one (owned by the caller of the library). | |
NEW |
indy_issuer_rotate_credential_def_start(command_handle: i32, wallet_handle: WalletHandle, cred_def_id: *const c_char, config_json: *const c_char, cb: Option) |
Apply temporary keys as main for an existing Credential Definition (owned by the caller of the library). | |
NEW |
indy_issuer_rotate_credential_def_apply(command_handle: i32, wallet_handle: WalletHandle, cred_def_id: *const c_char, cb: Option) |
cred_def_id, cred_def_json = indy_issuer_create_and_store_credential_def(...)
indy_sign_and_submit_request(cred_def_json)
...
...
temp_cred_def_json = indy_issuer_rotate_credential_def_start(cred_def_id)
indy_sign_and_submit_request(temp_cred_def_json)
indy_issuer_rotate_credential_def_apply(cred_def_id)