During the build of the pool docker image, pip installation fails with the following warnings:

#6 [3/11] RUN pip3 install -U 	pip==9.0.3 	setuptools
#6 1.341 Collecting pip==9.0.3
#6 1.643   Downloading https://files.pythonhosted.org/packages/ac/95/a05b56bb975efa78d3557efa36acaf9cf5d2fd0ee0062060493687432e03/pip-9.0.3-py2.py3-none-any.whl (1.4MB)
#6 2.354 Collecting setuptools
#6 2.673   Downloading https://files.pythonhosted.org/packages/6d/38/c21ef5034684ffc0412deefbb07d66678332290c14bb5269c85145fbd55e/setuptools-50.3.2-py3-none-any.whl (785kB)
#6 2.846 Installing collected packages: pip, setuptools
#6 2.846   Found existing installation: pip 8.1.1
#6 2.849     Not uninstalling pip at /usr/lib/python3/dist-packages, outside environment /usr
#6 3.612   Found existing installation: setuptools 20.7.0
#6 3.614     Not uninstalling setuptools at /usr/lib/python3/dist-packages, outside environment /usr
#6 3.987 Successfully installed pip-9.0.3 setuptools-50.3.2
#6 4.143 You are using pip version 9.0.3, however version 20.2.4 is available.
#6 4.143 You should consider upgrading via the 'pip install --upgrade pip' command.

Related to these (perhaps causally) may be the following error, which fails the build:

#10 [7/11] RUN apt-get update -y && apt-get install -y         python3-pyzmq...
#10 0.597 Get:1 https://repo.sovrin.org/deb xenial InRelease [28.4 kB]
#10 0.610 Hit:2 http://security.ubuntu.com/ubuntu xenial-security InRelease
#10 0.612 Hit:3 http://archive.ubuntu.com/ubuntu xenial InRelease
#10 0.691 Hit:4 http://archive.ubuntu.com/ubuntu xenial-updates InRelease
#10 0.697 Get:5 https://repo.sovrin.org/deb xenial/master amd64 Packages [345 kB]
#10 0.771 Hit:6 http://archive.ubuntu.com/ubuntu xenial-backports InRelease
#10 1.037 Fetched 373 kB in 0s (535 kB/s)
#10 1.037 Reading package lists...
#10 2.041 Reading package lists...
#10 3.065 Building dependency tree...
#10 3.197 Reading state information...
#10 3.242 Some packages could not be installed. This may mean that you have
#10 3.242 requested an impossible situation or if you are using the unstable
#10 3.242 distribution that some required packages have not yet been created
#10 3.242 or been moved out of Incoming.
#10 3.242 The following information may help to resolve the situation:
#10 3.242 
#10 3.242 The following packages have unmet dependencies:
#10 3.292  indy-plenum : Depends: python3-orderedset (= 2.0) but 2.0.3 is to be installed
#10 3.292                Depends: python3-psutil (= 5.4.3) but 5.6.6 is to be installed
#10 3.292                Depends: python3-psutil (= 5.4.3) but 5.6.6 is to be installed
#10 3.292                Depends: python3-pympler (= 0.5) but 0.8 is to be installed
#10 3.300 E: Unable to correct problems, you have held broken packages.

This may be related to the recent changes in the way pip resolves dependencies, or the new version of setuptools.

Temporarily, this issue was resolved by fetching a prebuilt pool image uploaded to GitHub Container Registry.

Currently @type values use incorrect prefix:

did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/connections/1.0/invitation
did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/present-proof/1.0/request-presentation

According to RFCs (https://github.com/hyperledger/aries-rfcs/blob/master/features/0160-connection-protocol/README.md, https://github.com/hyperledger/aries-rfcs/tree/master/features/0037-present-proof .. ), prefix https://didcomm.org/ should be used

https://didcomm.org/connections/1.0/invitation
https://didcomm.org/present-proof/1.0/request-presentation

This goes for all @type annotations used accross the codebase. It's apparently some legacy format which were brough in for backward compatibility (by look at acapy codebase https://github.com/hyperledger/aries-cloudagent-python/search?q=https%3A%2F%2Fdidcomm.org )

I am not sure if there's some agents using the legacy did:sov:BzCbsNYhMrjHiqZDTUASHg;spec, perhaps we can support both for now and drop the old one later. Acapy also seems to support both.

• We should have a way of validating DIDs, for example when passing in public did via argument to method like append_service_did

Agency client is currently using blocking API of reqwest. We should use its async api and expose async methods from agency client itself.

Currently httpClient.rs in agency_client module is used to make all http calls.

1. Optimize implementation of http client, mainly the fact that currently every call to post_message builds a brand new reqwest client

let client = reqwest::ClientBuilder::new().timeout(crate::utils::timeout::TimeoutUtils::long_timeout()).build()

which not only adds overhead, but also prevent reqwest from connection pooling.

2. Improve error handling, we return error at few places, but always just as AgencyClientErrorKind::PostMessageFailed, add error logging if an error occurs.

3. Assure aries-vcx is not dependent on agency_client's httpClient.rs - either by copy/paste (imo preferable now, it's just 1 file) or extracting as a package.

If issuer tries to create schema on ledger and this process fails due to issuer had not accepted the ledger TAA, it results in "Duplicate Schema" error, which is wrong.

See log from such event:

 WARN|vcx::api::schema              |           libvcx/src/api/schema.rs:72  | vcx_schema_create_cb(command_handle: 0, rc: Error: Duplicate Schema: Ledger Already Contains Schema For Given DID, Version, and Name Combination
  Caused by: Reject { reason: "client request invalid: InvalidClientTaaAcceptanceError('Txn Author Agreement acceptance is required for ledger with id 1',)" }

The InvalidClientTaaAcceptanceError is wrapped somewhere inside, but still the error itself Duplicate Schema. This can cause problem in case someone tries to evaluate presence/absence of some schema on ledger by attempting to creating it. Having not signing TAA would in such application cause false positive.

Previously we had 1 single rust project and hence it was easy to measure code coverage. However, after having done #112 and #196 we now have 3 crates:

• libvcx (c layer)
• aries_vcx (core rust layer)
• agency_client

The ideal state would be to measure coverage on each of these projects, but we can do this incrementally.

We are currently still measure coverage in libvcx project. Now many integration test are being moved from libvcx into aries_vcx and since aries_vcx is the core component, I think it'd make sense to start focusing on code coverage there first.

• We should not keep ~/.cargo in the final image
• Find if we can optimize/delete something else to decrease the image size

If inviter is using pairwise invitation to initiate connection with counter-party, after connection is established, inviter's bootstrap agent-connection in agency is never used, but it's never deleted. We should clean it up.

Note: Not worthy much investment time investment as it can be expected connection-protocol #160 will be replaced by did-exchange where we don't necessary have to deal with fore-mentioned issue.

This task encompasses modifications needed to make aries_vcx easy to use and concise.

Type of modifications needed:

• Do not expose unnecessary artifacts
• Remove ambiguities
• Rename / restructure crate artifacts

This task will be continually updated.

Issuer's finished state looks as follows:

pub struct FinishedState {
    pub cred_id: Option<String>,
    pub revocation_info_v1: Option<RevocationInfoV1>,
    pub status: Status,
}

whereas

pub enum Status {
    Undefined,
    Success,
    Failed(ProblemReport),
    Declined(ProblemReport),
}

When we dispatch credential message, we move to Finished { status: Status::Success }. However, after dispatching credential, there are 3 possibilities of what happens next

• we receiveAck
• we receive ProblemReport
• we receive nothing (buggy / not well behaved counterparty)

In all of these cases, the credential was created and sent, and regardless of what the counterparty claims happens, it should be considered as generally successful issuance and it should be clear that the credential is revokable.

I propose adjusting Status like this:

pub enum Status {
    Undefined,
    IssuedWithAck,
    IssuedWithProblem(ProblemReport),
    Failed(ProblemReport),
    Declined(ProblemReport),
}

After dispatching credential, there are 3 possibilities of what happens next

• we receiveAck -> we go to Finished { status: Status::IssuedWithAck }.
• we receive ProblemReport -> we go to Finished { status: Status::IssuedWithProblem(problem_report) }.
• we receive nothing -> we stay in state CredentialSent

And we should implement method was_issued(&self) ->bool which would

• return true if SM is in state CredentialSent or Finished { status: Status::IssuedWithAck } or Finished { status: Status::IssuedWithProblem(problem_report) }. This would signal that the credential was be dispatched and can be revoked.
• return false if SM is in states other than CredentialSent | Finished, or if is in state Finished { status: Failed(ProblemReport) } or Finished { status: Declined(ProblemReport) } .

Just for reminder, the way to reach Finished { status: Status::IssuedWithProblem(problem_report) } would be to receive problem report when we are in state offer_sent.

It would be nice we added option parameter. It would be a stringified JSON. The first supported option within it could be something like correlation_id. That way the caller could optionally inject correlation ID to be injected into HTTP request made against the Agent's agency. This would help to correlate requests especially in backed environment, so you could see how API calls into 1 service propagated to calls made against an agency via Libvcx.

Currently there's only method vcx_schema_create which writes schema on ledger and creates schema representation object.
If issuer wants to create credential definition using existing schema (perhaps one which was authored by different DID), aries-vcx currently provides no direct support to do that.
We should add something like vcx_schema_create_from_existing (not sure about naming), which would take schema ledger id as parameter, resolve attributes on ledger and create aries-vcx representation.

Appendix

1. Currently, aries-vcx schema representation has following structure:

{
    version: '1.0',
    data: {
      data: <attributes>,
      version: <schema_version>,
      schema_id: <schema_id>,
      name: <schema_name>,
      source_id: <source_id>,
      payment_txn: null
    }
  }

2.schemaId such as 8oSxhsmNTy8QXq3ESjsRud:2:Diploma 067a867c:0.1, has structure <sender_did>:2:<schema_name>:<schema_version>

Write script to generate images from puml files in docs/states/aries/

The problem

Currently there's no good way to consume aries-vcx from other Rust code.

Solution 1 - Aries-vcx as consumable crate

Here I am proposing structuring aries-vcx into 4 layers. But that doesn't mean we should have them all exposed from the crate.

• HandleAPI (not exposed from crate) - enforces memory management. I don't see why someone using aries-vcx from rust would want to deal with u32 object handles and loose all the typing smartness. This should not be exposed, but stay as internal layer only leveraged by C-Callable API itself.
• ComfortAPI - This layer puts together Aries state machines and agency client - good example is updateState, as described on the picture. This would be likely level of abstraction someone would want to operate on if there was intention to use VCX Agency as well.
• DirectAPI - This is API of Aries state machines, agency client. These objects are already something the consumer of ComfortAPI is dealing with in parameters / return values and there should be option to call methods on these structures directly. It could also be that someone is only interested in using Aries state machines directly.

Steps to take:

1. Rename api to api_c. Then api_c module to be more "pure", as currently it does more than handling FFI calls, more specifically it:

   • Some function are reading data from settings.rs, passing it down to further called functions (see
     vcx_schema_prepare_for_endorser for example).
   • Spawning work on threadpool.

2. Create api_handle module. This will contain basically the logic and state shared across threads - currently in src/*rs files which take u32 object "handles" as input/output.

3. Create api_comfort module. This should have similar API as api_handle however input/outputs should be typed with Rust structures. This layer will contain logic gluing together multiple structures / operations on top of them (for example updateState()). This layer should not have any state of its own.

4. Create api_direct which would include:

• Aries state machines
• agency client
• other operations (pool, wallet, ledger operations)

Pros:

• As someone building Rust agent, the only runtime dependency would be libindy and libnullpay. But aries-vcx crate would be "the whole package".
• Consumer of the crate can take full advantage of Rust typing
• Consumer of the crate can decide not to use Agency
• Because consumer of the crate doesn't deal with handles as we have them now, and is not forced to shared any internal state across threads, it's possible to write Aries2Bob integration tests, each party running in its own thread without any interference between them.

... without duplication of the state information.

Currently the library exposes c-callable function vcx_download_agent_messages which is going to be deprecated. The reason is that it's security-issue prone. It returns messages downloaded from agency according to specified filters (pw_did, message status, agency message uid). The problem is that it returns payload of these messages, but these messages are not authenticated, so it would be fairly easy to spoof a message.

Common usage of vcx_download_agent_messages is to only inspect what kind of messages has been received (cred offer, proof req ...) and then execute separate action based on that information (which would then use functions which download specific message AND performs the authentication).
To accommodate this pattern, we could implement vcx_download_msg_info which would have the same API interface as present vcx_download_agent_messages, except that instead of returning message payload, it would only return message type. The caller could then execute actions based on this information. The risk here is highly mitigated, but still, this partial information about received messages would not be authenticated.

Perhaps best way to go about this would be:

• change signature of vcx_download_agent_messages such that instead of list of pw_dids, it would take list of connection handles. This way authentication would be possible in vcx_download_agent_messages implementation and we could return message payload as we do now, except it would actually be authenticated.
  This would mostly preserve the behaviour as of today, whilst making the implementation secure.

Hi,

after double checking multiple times:

Release 0.23.0 - works fine (including all previous releases)
Release 0.24.1 - crashing in initialization

On the first launch of the app:
vcx.initThreadpool = Success
vcx.createWallet = here it seems to crash

We are using the universal framework.

OOB message looks as described here https://github.com/hyperledger/aries-rfcs/blob/main/features/0434-outofband/README.md#messages

And particularly about field services

services - an array of union types that the receiver uses when responding to the message. Each item is either a DIDComm service object (as per RFC0067) or a DID (as per Decentralized Identifiers v1.0). Additional details below.

We currently implement method for appending service object, but not DID.

The way aries-vcx is currently supposed to be initialized typically looks as follows:

        logger.info('Initializing VCX settings')
        await initVcxCore(JSON.stringify(vcxAgentProvision))
        logger.info('Opening pool')
        await openVcxPool()
        logger.info('Opening wallet')
        await openVcxWallet()
        logger.info('LibVCX fully initialized')

1. Everthing starts with initVcxCore which does 2 things:

• initializes "settings" - global state of the library
• initializes logger
• initializes threadpool for async FFI calls

2. Then you have to open pool and wallet, whereas both of these functions relies on global state configured via vcxInitCore.

We previously had all these operations as part of vcx_init_with_config and we've split them into separate APIs. This enabled for more flexibility, but I see the current state as only a phase. So I propose next phase, where we deprecate vcx_init_core, vcx_open_wallet, vcx_open_pool and instead introduce:

vcx_init_ffi - creates runtime for executing work on async FFI APIs
vcx_init_logger - initializes logger
vcx_init_issuer_configuration - initializes settings.rs with information issuer needs to know to operate (see vcx_configure_issuer_wallet at #209)
vcx_create_agency_client(agency_config) - creates shared global instance of agency_client in aries-vcx. See detials of (agency_config)[https://github.com//issues/209]
vcx_open_wallet_directly(wallet_config) - opens wallet
vcx_open_pool_directly(pool_config)- opens pool

Currently we are using in tests enum -> u32 conversions such asIssuerState::Initial as u32 but this way impl From<IssuerState> for u32 is not utilized, instead the result is determined by position of the variant listing in enum declaration.

We should use .into() instead of as u32

Currently, we have some From implementations which should be converted to TryFrom as they may fail, e.g. impl From<Invitation> for DidDoc.

Aiming for our roadmap architecture
https://github.com/hyperledger/aries-vcx/blob/main/docs/architecture/ariesvcx_architecture_future_180821.png

we will need to extract new crate aries_fsm out of aries_vcx. The aries_fsm crate function is to be pure Aries RFC codification without external dependencies. It should be independent of whether you use mediator agency or not, it should be independent of type of credential you issue or verify (indy, bbs+, ... )

Preconditions for making that happen are following:

• #111
• #112
• #151
• #337
• #338

Module protocols should be a "codification" of state machines as defines by Aries RCFs. These should not directly tie to libindy or any specific type of credentials or frameworks.

aries_vcx is currently organized primarily per protocol, eg. src/handlers/connection, src/handlers/issuance and within each protocol is contained both logic of both aries_vcx and Aries FSM (as referred to in diagram https://github.com/hyperledger/aries-vcx/blob/main/docs/architecture/ariesvcx_architecture_now_180821.png )

The code should be reorganized as follows:

- src 
    - aries 
       - messages/..
       - utils/..
       - fsm
           - connection
               - invitee
                   - states/..
                   - state_machine.rs
               - inviter/..
           - issuance
               - holder/..
               - issuer/..
           - presentation/..
    - vcx
       - connection.rs
       - issuer.rs
       - holder.rs
       - prover.rs
       - verifier.rs

so that the business of aries_vcx is contained in module vcx and everything aries related, which should ideally have no dependency on ledger or credential library, shall be contained in module aries.

One of the steps toward building standalone Aries protocol state machine module is to remove dependency on global variables from ::settings. Whenever global values are used, it should rather be injected by calling code.

• Code in V3 directory should not contain notion of connection_handle as that's something what belongs to higher layers of abstractions.
• Connection handle is being used typically to: send message (maybe more)
• Instead of connection handle, different minimal abstractions necessary to performs these operations will have to be passed - perhaps closures capable of sending message to the right place, some trait object or maybe connection state machine?
• Side effect will be that connection handle won't be part of serialized credential/proof state machines.
• This will be important step toward extracting state aries protocol state machines to independent crate.

We found that vcx_v2_messages_download is currently exposing API which doesn't play nice with with language wrapper, which don't have u32 / uint representation of handles.

In particular, the Rust API returns u32 handles as references to various objects stored in memory on libvcx layer. Java wrapper types these values as int, which is 32bits long number, but includes negative range, eg. equivalent of i32 in Rust. Because of this, on Java layer, these values appear negative.

This is generally not problem, as far as the C-APIs deal with these handles as numbers - it doesn't matter the value "appears" negative in Java, the sequence of bytes is always the same, hence the memory reference is valid.

The problem is that

pub extern fn vcx_v2_messages_download(command_handle: CommandHandle,
                                       conn_handles: *const c_char,
                                       message_statuses: *const c_char,
                                       uids: *const c_char,
                                       cb: Option<extern fn(xcommand_handle: CommandHandle, err: u32, messages: *const c_char)>) -> u32 {

is taking conn_handles, which is supposed to be JSON array of handles. Because these in Java appear negative, in result what we pass down to Rust is something like:

conn_handles = "[-15161235, -2161243]"

And we then try to parse these negative numbers into unsigned 32 bit int, which is not possible without dirty tricks (doing unsafe conversion based on whether received number is negative or positive)

Possible solutions could are following.

1. Change conn_handles to be array of u32s, but then we probably also need additional parameter to define length of the array.
2. Implement new function to download messages for particular connection only, which removes the problem with passing down array of numeric u32 handles. This would also just make the API more user friendly, as one could then request download of messages on particular connection object like:

connection.downloadMessages(STATUS_PENDING, ["uid123", "uid456"])

instead of using utility function as currently:

downloadMessages([connection1.handle], STATUS_PENDING, ["uid123", "uid456"])

With this solution, if you want to download messages for more connections, you'll have to call the function on each of them. This is not less efficient than previous implementation with vcx_v2_messages_download, as this itself was looping the connections internally on Rust layer.

Due to lacking write permissions in CI when mounting volumes into docker containers, we copy the entire repository into the android dockerfile. This increases the size of the resulting image to ~8 GB. During android builds, the storage usage exceeds current github actions limit (12 GB). We need to reduce the size of the image, e.g. by resolving the permissions issues when mounting volumes.

We are dropping support for vcx_download_agent_messages and vcx_agent_update_info .
Was removed from NodeJS ffi, remove from other wrappers as well.

The problem with current API is described hyperledger-archives/indy-sdk#2211

I propose to add new update methods, deprecate old ones in 1 release, remove deprecated update methods in next release.

Currently the only open-source aries-vcx agency is vcx-agency-node written in Node. This brings extra maintenance overhead and duplication:

• the message types are defined on 2 places (aries-vcx and in Node agency)
• Node agency has it's own implementation of agency-client written for purpose of integration testing
• Node agency is dependency on IndySDK and crippled by performance issues caused by blocking storage API in IndySDK - it would be good start to replace IndySDK in agency by using aries-askar. We could learn something before we attempt to migrate aries-vcx away from libindy. It's also more accessible to experiment with aries-askar and other aries/indy crates from Rust, as in case of Node, we would have to write Node FFI wrappers.
• aries-vcx as a whole and mediator agency go hand in hand and it would make sense to test them in one CI.

• Acapy is fairly mainstream choice for open source institutional agent

• aries-framework-rs provides interfaces for mobile

• there's good chance and aries-framework-rs based app would interact with acapy

• To make sure we are not in a buble, it would be great to have integration tests with acapy as part of Github Actions CI

• Attaching help-wanted label, we as Absa don't plan to work on this in upcoming future, but this issue is here as invitation for others to contribute

Split of vcx_provision_agent

I propose to split deprecate vcx_provision_agent and split it into 3 new functions vcx_create_wallet, vcx_configure_issuer_wallet, vcx_provision_new_agent due to following problems. To enable this, we will also need vcx_open_wallet which does not rely on settings.rs.

Problem 1

Currently this is function which has was given 3 responsibilities:

• create new wallet
• configure wallet (create prover master secret in wallet, create issuer's DID from seed (using enterprise_seed attribute))
• using that wallet, onboard a new agency agent
  Though this covers common scenarios, it's restrictive at the same time - what if I only want to create new wallet and onboard agency client later? (perhaps running on mobile app for the first while not being connected to the internet - we might not be able to onboard agency client, but we might at least want to create the app wallet). Or perhaps we have wallet(s) and want to onboard to agency using it.

Problem 2

Additionally there's one more design issue with vcx_provision_agent. Currently, it requires you to pass in "config" looking as such:

{
    "path": "/path/to/genesis/127.0.0.1",

    "name": "my_agent_name",
    "logo": "https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcTjkD2iJdaKMlH2sKgR_flz6sa3mgkB9PRQwve4GLoXqPI7r73RiQ",

    "agency_url": "http://127.0.0.1:8080",
    "agency_did": "VsKV7grR1BUE29mG2Fm2kX",
    "agency_verkey": "Hezce2UWMZ3wUhVkh2LfKSs8nDzWwzs2Win7EzNN3YaR",

    "payment_method": "null",
    
    "enterprise_seed": "000000000000000000000000Trustee1",

    "wallet_name": "my_wallet_name",
    "wallet_key": "123456",
    "wallet_key_derivation": "ARGON2I_MOD",
    "wallet_type": "postgres_storage",
    "storage_config": "{\"url\":\"localhost:5432\"}",
    "storage_credentials": "{\"account\":\"postgres\",\"password\":\"password_123\",\"admin_account\":\"postgres\",\"admin_password\":\"password_foo\"}"
}

Performs some sort of mappings to these fields, so that it produces similarly looking config, with additional agency_client related info (remote_to_sdk_did, .. etc.):

{
  "path": "/path/to/genesis/127.0.0.1",

  "institution_did": "V4SGRU86Z58d6TV7PBUe6f",
  "institution_name": "my_agent_name",
  "institution_verkey": "GJ1SzoWzavQYfNL9XkaJdrQejfztN4XqdsiV4ct3LXKL",

  "agency_did": "VsKV7grR1BUE29mG2Fm2kX",
  "agency_endpoint": "http://127.0.0.1:8080",
  "agency_verkey": "Hezce2UWMZ3wUhVkh2LfKSs8nDzWwzs2Win7EzNN3YaR",
  "remote_to_sdk_did": "GkdUhwyWqNw3vGs6FQFFHb",
  "remote_to_sdk_verkey": "9axcTwXeJ1haJBw9LqexT8dRpiFCJwA6ZUevM5nfiDKg",
  "sdk_to_remote_did": "C5DiHD1n3MqNcv5h7PBK9J",
  "sdk_to_remote_verkey": "732pD7kDiBjSyS57aNXi52Xpg2DLCTb43aLpddo2X8CG",

  "wallet_name": "my_wallet_name",
  "wallet_key": "123456",
  "wallet_key_derivation": "ARGON2I_MOD",
  "wallet_type": "postgres_storage",
  "storage_config": "{\"url\":\"localhost:5432\"}",
  "storage_credentials": "{\"account\":\"postgres\",\"password\":\"password_123\",\"admin_account\":\"postgres\",\"admin_password\":\"password_foo\"}"
}

And whenever you initialize vcx, you are expected to pass in this as parameter. The fact the attributes are being renamed (name becomes institution_name, ...) is confusing and the overall flow rigid and reflects previously coupled architecture of the library.

Solution

So I suggest to deprecate vcx_provision_agent and instead create:

vcx_create_wallet

Creates new wallet using provided parameters, pretty much propagates to IndySDK and creates wallet. Additionally creates prover master secret, as that'd be needed on both mobile and institutional agents. It keeps wallet closed. API:
vcx_create_wallet(wallet_config) -> void
Whereas the argument wallet_config is JSON string such as:

{
   "wallet_name": "my_wallet_name",
   "wallet_key": "123456",
   "wallet_key_derivation": "ARGON2I_MOD",
   "wallet_type": "postgres_storage",
   "storage_config": "{\"url\":\"localhost:5432\"}",
   "storage_credentials": "{\"account\":\"postgres\",\"password\":\"password_123\",\"admin_account\":\"postgres\",\"admin_password\":\"password_foo\"}"
}

vcx_configure_issuer_wallet

This is only needed if you are issuer, so mobile agents would not need to call this. API
vcx_create_wallet(enterprise_seed, institution_name) -> institution_config
Whereas institution_config is JSON such as

{
  "institution_did": "V4SGRU86Z58d6TV7PBUe6f",
  "institution_name": "my_agent_name",
  "institution_verkey": "GJ1SzoWzavQYfNL9XkaJdrQejfztN4XqdsiV4ct3LXKL",
}

vcx_provision_new_agent

Provision new agent using provided agency information and a wallet_handle. API:
vcx_provision_new_agent(agency_did, agency_vk, agency_endpoint) -> agency_config
whereas the returned agency_config would be JSON string containing information needed to create agency client (apart from proper wallet handle)

{
  "agency_did": "VsKV7grR1BUE29mG2Fm2kX",
  "agency_endpoint": "http://127.0.0.1:8080",
  "agency_verkey": "Hezce2UWMZ3wUhVkh2LfKSs8nDzWwzs2Win7EzNN3YaR",
  "remote_to_sdk_did": "GkdUhwyWqNw3vGs6FQFFHb",
  "remote_to_sdk_verkey": "9axcTwXeJ1haJBw9LqexT8dRpiFCJwA6ZUevM5nfiDKg",
  "sdk_to_remote_did": "C5DiHD1n3MqNcv5h7PBK9J",
  "sdk_to_remote_verkey": "732pD7kDiBjSyS57aNXi52Xpg2DLCTb43aLpddo2X8CG"
}

Okay so there we have it, vcx_provision_agent split into 3 functions. Assuming no modifications to other functions, the caller would now have some extra work - he needs to combine known information (wallet info) with infromation received (agency_client config) to construct the config JSON to be pass into vcx_init_core. This was previously bit easier as this was "conveniently" received from vcx_provision_agent.

Example of "NodeJS pseudocode" based institutional agent consuming new APIs

const pool_config = {
    "path": "/path/to/genesis/127.0.0.1",
}
const wallet_config = {
   "wallet_name" = "my_wallet_name",
   "wallet_key" = "123456",
   "wallet_key_derivation" = "ARGON2I_MOD",
   "wallet_type" = "postgres_storage",
   "storage_config" = "{\"url\":\"localhost:5432\"}",
   "storage_credentials" = "{\"account\":\"postgres\",\"password\":\"password_123\",\"admin_account\":\"postgres\",\"admin_password\":\"password_foo\"}"
}
cosnt enterprise_seed = "000000000000000000000000Trustee1" 
const institution_name = "Faber"

const agency_did="VsKV7grR1BUE29mG2Fm2kX"
const agency_endpoint="http://127.0.0.1:8080"
const agency_verkey="Hezce2UWMZ3wUhVkh2LfKSs8nDzWwzs2Win7EzNN3YaR"

await vcx_create_wallet(wallet_config)
const wallet_handle = await vcx_open_wallet_directly(wallet_config)
const institution_config = await vcx_configure_issuer_wallet(wallet_handle, "enterprise_seed", institution_name)
const agency_config = await vcx_provision_new_agent(agency_did, agency_vk, agency_endpoint)
await vcx_close_wallet_directly(wallet_handle)

const initConfig = { ...agency_config, ...wallet_config, ...institution_config, ...pool_config }

await vcx_init_core(initConfig)
await vcx_open_wallet()
await vcx_open_pool()

Additional APIs needed

Additionally as can be seen per example above, we also need APIs:
vcx_open_wallet_directly(wallet_config) -> wallet_handle
vcx_close_wallet_directly(wallet_handle)

Currently failure to send Ack (if requested by prover) leads Verifier FSM to failed state. For now an open question is whether that's right design/behaviour.

• Currenty we support Connection protocol https://github.com/hyperledger/aries-rfcs/blob/main/features/0160-connection-protocol/README.md as part of AIP 1.0
• First step towards AIP 2.0 is adding support for DidExchange protocol https://github.com/hyperledger/aries-rfcs/blob/main/features/0023-did-exchange/README.md

when error is catched on libvcx layer from aries-vcx, the error log should include stacktrace

The current version of LibVCX now contains a revocation feature, but a tails file should deploy with an agent locally.

Would it be possible to make this feature to support a tails server publicly? such as https://github.com/bcgov/indy-tails-server

Example use case
When deployed issuer and verifier on a different server, how does a verifier find a tails file for a revocation registry to check a VC that still valid or not? It would be great if a tails server able to deploy as a separate service, a holder also support to attach a tails server URL with its presentation.

Hej, I am building a mobile iOS agent and already spend some time on the 3rd party iOS Swift wrapper.
After updating the vcx library, I noticed that many parts of the provisioning have been deprecated/removed from the library, so the demo isn‘t working anymore.

So I started my own Swift wrapper, but uncertain about the correct workflow. Based on #209 I tried to figure out the correct workflow. So far I have working:

• createWallet
• openMainWallet
• vcxProvisionCloudAgent (connection to dummy cloud agent)
• closeMainWallet

Now that "vcx_init_core" is not working anymore, how to init core with the returned agency config?
Digging deeper into #210 it's supposed to continue with:

• vcx_init_ffi (not available in iOS wrapper. Is this vcxInitThreadpool?)
• vcx_init_logger
• vcx_init_issuer_configuration (not required for mobile agent)
• vcx_configure_issuer_wallet (not required for mobile agent)
• vcx_create_agency_client(agency_config) - vcxCreateAgencyClient
• openMainWallet
• vcx_open_pool_directly(pool_config) - vcxOpenMainPool (connection to indy pool run in a Docker container)
  This currently returns an error ("Connection to Pool Ledger.").

Thanks

Currently we implement connection protocol https://github.com/hyperledger/aries-rfcs/blob/main/features/0160-connection-protocol/README.md
We should implement did-exchange protocol https://github.com/hyperledger/aries-rfcs/blob/main/features/0023-did-exchange/README.md

Consider this when working on the implementation
https://github.com/hyperledger/aries-rfcs/blob/main/features/0496-transition-to-oob-and-did-exchange/README.md

Currently there are 2 ways of updating protocol state machines in libvcx:

• update_state_with_message - tries to progress state of the SM and possibly invoke side effect such as sending message (reply to counterparty) over network
• update_state - has 3 stages:
  1. download messages from agency
  2. perform update_state_with_message
  3. update state of processed message in agency

Because update_state is introducing dependencies on agency and the operations are not really related to aries protocol itself, this should be extracted out of (currently) v3 directory (to be renamed to aries directory).

Logging is not consistent in term of finishing sentence with period or not - the style should be unified. We decided not to use periods.

The first step toward building standalone vcx-agency client is to remove dependecy on global variables from ::settings. Whenever global values are used, it should rather be injected by calling code.

• create credential definition without revocation registry
• issue credential
• request proof, require non-revocation proof
• fulfil the proof request using the non-revokable credential

We've run into intermittent failure in this CI run
https://github.com/hyperledger/aries-vcx/pull/201/checks?check_run_id=1380131901

failures:

---- api::disclosed_proof::tests::test_generate_msg stdout ----
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: 1005', src/api/disclosed_proof.rs:1112:18
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace


failures:
    api::disclosed_proof::tests::test_generate_msg

test result: FAILED. 495 passed; 1 failed; 3 ignored; 0 measured; 0 filtered out

• General interface, perhaps a trait should be created for interaction with agency.
• This should make it easier to eventually swap implementation and implement client-to-agency communication aligned with Aries RFCs (currently the client-to-agency protocol is non-standard)
  Aries state machines should (currently under v3 directory) should only interact with agency via some general interface instead being depending on particular implementation.
• This will be important step toward extracting state aries protocol state machines to independent crate.

Subtasks:
#150

When aries-vcx agent queried via https://didcomm.org/discover-features/1.0/* about which Aries protocol it supports, it replies with list of all protocols implemented in aries-vcx.
The fact that the protocols are implemented in libvcx doesn't mean an agent wants to use them/disclose them. AriesVCX user should have control over which protocols will be disclosed.