Project proposal to move Aries VCX to OWF

[gmulhearn]

CC: @JamesKEbert

[gmulhearn]

naming is hard... the codebase is formerly know as "Aries VCX", where VCX = Verifiable Credential Exchange. Perhaps just "VCX" is too broad for OWF?

[gmulhearn]

alternatives may be something like, vcx-rs, or maybe some slick new rebranded name (e.g. like how afj did with credo).

thoughts @JamesKEbert ?

[JamesKEbert]

I've been leaning towards just 'VCX', whether we keep the acronym or not (I tentatively lean towards not keeping the acronym). I also think VCX has a broader scope than 'vcx-rs' implies since it can be used in Android / iOS projects and possibly in the future React Native and WebAssembly as well, so not only Rust. Or even any other language that could interface with C theoretically. The wrappers would likely be tedious, but it is possible, and could be potentially beneficial with the DID Core crates for instance.

We also don't have quite the same issue that AFJ had, since dropping Aries from the name left them with just 'Javascript Framework', which is humorously broad.

I'd also consider the in-development 'VCX Framework' as part of the naming considerations here.

That's my .02--but yeah, naming things is hard..

[skounis]

Are there plans to refer to the OWF copy just for consistency?

[JamesKEbert]

I would expect so -- any concern with that @gmulhearn ?

[gmulhearn]

yes definitely happy to adopt and refer to OWF copy. Does this section of the vcx.md need to be updated?

[skounis]

I suggest also to check if any of these dependencies brings a license (open source or not) that collides with the permissive nature of Apache.

[gmulhearn]

i've ran a simple check with cargo license:

• majority are apache 2.0,
• others include: bsd-3-clause, ISC, MIT, ZLib
• MPL-2.0 is used by uniffi-rs deps, however i believe it's not a problem since we are not modifying the uniffi code at all, simply consuming it
• Unicode-3.0 is used by some icu_ deps, however we are not re-distributing or export their unicode functionality, so i don't believe further license restrictions apply
• finally ring has a custom license based on boringssl/openssl .. this might require some further investigation on what the implications are. e.g. meeting their advertising clause: https://github.com/briansmith/ring/blob/main/LICENSE#L66

[gmulhearn]

full license dump (generated by cargo license) FWIW:

(Apache-2.0 OR MIT) AND BSD-3-Clause (1): encoding_rs
(MIT OR Apache-2.0) AND Unicode-3.0 (1): unicode-ident
0BSD OR Apache-2.0 OR MIT (1): adler2
Apache-2.0 (32): amcl, anoncreds, anoncreds-clsignatures, anoncreds-clsignatures, aries-vcx-agent, aries_vcx, aries_vcx_anoncreds, aries_vcx_ledger, aries_vcx_wallet, ciborium, ciborium-io, ciborium-ll, did_cheqd, diddoc_legacy, etcommon-hexutil, fragile, glass_pumpkin, indy-blssignatures, indy-data-types, indy-vdr, isolang, messages, openssl, prost, prost-build, prost-derive, prost-types, shared, sync_wrapper, test_utils, uniffi_aries_vcx, xi-unicode
Apache-2.0 OR Apache-2.0 WITH LLVM-exception OR MIT (5): linux-raw-sys, rustix, wasi, wasi, wit-bindgen-rt
Apache-2.0 OR BSD-1-Clause OR MIT (1): fiat-crypto
Apache-2.0 OR BSD-2-Clause OR MIT (4): zerocopy, zerocopy, zerocopy-derive, zerocopy-derive
Apache-2.0 OR BSL-1.0 (1): ryu
Apache-2.0 OR BSL-1.0 OR MIT (2): wasite, whoami
Apache-2.0 OR ISC OR MIT (3): hyper-rustls, rustls, rustls-pemfile
Apache-2.0 OR MIT (379): actix-codec, actix-http, actix-macros, actix-router, actix-rt, actix-server, actix-service, actix-utils, actix-web, actix-web-codegen, addr2line, aead, aes, aes-gcm, ahash, allocator-api2, android-tzdata, android_log-sys, android_logger, android_system_properties, anstream, anstyle, anstyle-parse, anstyle-query, anstyle-wincon, anyhow, arc-swap, argon2, aries-askar, askama, askama_derive, askama_escape, askama_shared, askar-crypto, askar-storage, async-lock, async-trait, atomic-waker, autocfg, backtrace, base16ct, base64, base64, base64ct, bitflags, bitflags, blake2, block-buffer, block-modes, block-padding, bls12_381, bs58, bumpalo, bytestring, camino, cargo-platform, cbc, cc, cfg-if, chacha20, chacha20poly1305, chrono, cipher, clap, clap, clap_builder, clap_derive, clap_derive, clap_lex, clap_lex, colorchoice, concurrent-queue, const-oid, cookie, core-foundation, core-foundation-sys, core2, cpufeatures, crc, crc-catalog, crc32fast, crossbeam-channel, crossbeam-epoch, crossbeam-queue, crossbeam-utils, crypto-bigint, crypto-common, crypto_box, crypto_secretbox, ctr, curve25519-dalek-derive, der, deranged, derive_builder, derive_builder_core, derive_builder_macro, diff, digest, displaydoc, ecdsa, ed25519, either, elliptic-curve, enum-map, enum-map-derive, enumset, enumset_derive, env_filter, env_logger, env_logger, equivalent, errno, error-chain, etcetera, etcommon-rlp, event-listener, event-listener-strategy, fastrand, ff, ffi-support, fixedbitset, flate2, flume, fnv, foreign-types, foreign-types-shared, form_urlencoded, fs-err, fs2, futures, futures-channel, futures-core, futures-executor, futures-intrusive, futures-io, futures-lite, futures-macro, futures-sink, futures-task, futures-util, fxhash, getrandom, getrandom, ghash, gimli, glob, group, half, hashbrown, hashbrown, hashlink, heck, heck, hermit-abi, hex, hkdf, hmac, home, http, http, httparse, httpdate, humantime, hyper-timeout, hyper-tls, iana-time-zone, iana-time-zone-haiku, ident_case, idna, idna_adapter, impl-more, indexmap, indexmap, inout, ipnet, is_terminal_polyfill, itertools, itertools, itoa, jobserver, js-sys, k256, keccak, language-tags, lazy_static, libc, local-channel, local-waker, lock_api, log, maplit, md-5, metadeps, mime, minimal-lexical, mockall, mockall_derive, multimap, native-tls, num, num-bigint, num-bigint-dig, num-complex, num-conv, num-integer, num-iter, num-rational, num-traits, num_threads, object, once_cell, opaque-debug, openssl-macros, openssl-probe, os_str_bytes, p256, p384, parking, parking_lot, parking_lot, parking_lot_core, parking_lot_core, password-hash, paste, pem-rfc7468, percent-encoding, petgraph, pin-project, pin-project-internal, pin-project-lite, pin-utils, pkcs1, pkcs8, pkg-config, plain, poly1305, polyval, powerfmt, ppv-lite86, predicates, predicates-core, predicates-tree, pretty_assertions, prettyplease, primeorder, proc-macro-error, proc-macro-error-attr, proc-macro2, quote, rand, rand, rand_chacha, rand_chacha, rand_core, rand_core, regex, regex-automata, regex-lite, regex-syntax, reqwest, rfc6979, rsa, rustc-demangle, rustc_version, rustls-pki-types, rustversion, salsa20, scopeguard, sec1, security-framework, security-framework-sys, semver, serde, serde-json-core, serde_derive, serde_json, serde_path_to_error, serde_test, serde_urlencoded, sha1, sha2, sha3, shlex, signal-hook, signal-hook-mio, signal-hook-registry, signature, siphasher, siphasher, sled, smallvec, socket2, spki, sqlx, sqlx-core, sqlx-macros, sqlx-macros-core, sqlx-mysql, sqlx-postgres, sqlx-sqlite, stable_deref_trait, static_assertions, stringprep, syn, syn, system-configuration, system-configuration-sys, tempfile, term_size, thiserror, thiserror, thiserror-impl, thiserror-impl, time, time-core, time-macros, tokio-rustls, toml, toml, typed-builder, typed-builder-macro, typenum, unicase, unicode-bidi, unicode-normalization, unicode-properties, unicode-segmentation, unicode-width, unicode-xid, universal-hash, url, utf16_iter, utf8_iter, utf8parse, uuid, vcpkg, version_check, wasm-bindgen, wasm-bindgen-backend, wasm-bindgen-futures, wasm-bindgen-macro, wasm-bindgen-macro-support, wasm-bindgen-shared, web-sys, winapi, winapi-i686-pc-windows-gnu, winapi-x86_64-pc-windows-gnu, windows-core, windows-registry, windows-result, windows-strings, windows-sys, windows-sys, windows-sys, windows-targets, windows-targets, windows_aarch64_gnullvm, windows_aarch64_gnullvm, windows_aarch64_msvc, windows_aarch64_msvc, windows_i686_gnu, windows_i686_gnu, windows_i686_gnullvm, windows_i686_msvc, windows_i686_msvc, windows_x86_64_gnu, windows_x86_64_gnu, windows_x86_64_gnullvm, windows_x86_64_gnullvm, windows_x86_64_msvc, windows_x86_64_msvc, write16, yansi, zeroize, zeroize_derive, zmq, zmq-sys, zstd-safe, zstd-sys
Apache-2.0 OR MIT OR Zlib (3): miniz_oxide, tinyvec, tinyvec_macros
Apache-2.0) OR MIT AND (MIT (1): libm
BSD-3-Clause (7): alloc-no-stdlib, alloc-stdlib, curve25519-dalek, ed25519-dalek, instant, subtle, x25519-dalek
BSD-3-Clause OR MIT (2): brotli, brotli-decompressor
Custom License File (1): ring
ISC (2): rustls-webpki, untrusted
MIT (94): async-stream, async-stream-impl, atoi, atty, axum, axum-core, base-x, bincode, bitvec, bytes, cargo_metadata, convert_case, crossterm, crossterm_winapi, crunchy, cursive, cursive_core, darling, darling_core, darling_macro, data-encoding, data-encoding-macro, data-encoding-macro-internal, derive_more, derive_more, derive_more-impl, display_as_json, dotenvy, downcast, elastic-array-plus, funty, generic-array, goblin, h2, h2, http-body, http-body-util, hyper, hyper-util, libsqlite3-sys, lru, mime_guess, mio, mio, multibase, ncurses, nom, openssl-sys, owning_ref, pem, phf, phf_shared, radium, redox_syscall, redox_syscall, rmp, rmp-serde, schannel, scroll, scroll_derive, slab, spin, strsim, strsim, strum, strum_macros, synstructure, tap, termtree, textwrap, tokio, tokio-macros, tokio-native-tls, tokio-stream, tokio-test, tokio-util, tonic, tonic-build, tower, tower, tower-http, tower-layer, tower-service, tracing, tracing-attributes, tracing-core, transitive, try-lock, uniresid, unsigned-varint, want, weedle2, wyz, zstd
MIT AND BSD-3-Clause (1): matchit
MIT OR Unlicense (5): aho-corasick, byteorder, memchr, termcolor, winapi-util
MPL-2.0 (9): uniffi, uniffi_bindgen, uniffi_build, uniffi_checksum_derive, uniffi_core, uniffi_macros, uniffi_meta, uniffi_testing, webpki-roots
N/A (18): anoncreds_types, aries-vcx-backchannel, cheqd_proto_gen, client-tui, did_doc, did_jwk, did_key, did_parser_nom, did_peer, did_resolver, did_resolver_registry, did_resolver_sov, did_resolver_web, indy-ledger-response-parser, mediator, messages_macros, public_key, simple_message_relay
Unicode-3.0 (19): icu_collections, icu_locid, icu_locid_transform, icu_locid_transform_data, icu_normalizer, icu_normalizer_data, icu_properties, icu_properties_data, icu_provider, icu_provider_macros, litemap, tinystr, writeable, yoke, yoke-derive, zerofrom, zerofrom-derive, zerovec, zerovec-derive
Zlib (1): foldhash

[gmulhearn]

NOTE: all N/A licenses in that license dump are child-crates owned by the aries-vcx codebase/workspace. I'm not sure why they aren't inheriting the Apache 2.0 license in the root of the aries-vcx repo.

[skounis]

Will Hyperledger keep sponsoring the project?

[JamesKEbert]

I don't anticipate this, I believe everything would be moved over to the OWF.

[skounis]

It looks like that the following criteria are met but it's good to have a sort comment for each one of them so we help our discussion

• 2 TAC sponsors to champion the project and provide mentorship as needed.
• Development of a growth plan, to be done in conjunction with their project mentor(s) at the TAC.
• Development of a project roadmap that provides differentiated features and capabilities and the timeframe for completion.
• Document that it is being used successfully in either proof of concepts or pilots by at least two independent end users which, in the TAC’s judgment, are of adequate quality and scope.
• Demonstrate a substantial ongoing flow of commits and merged contributions.
• Demonstrate that the current level of community participation is sufficient to meet the goals outlined in the growth plan and roadmap.
• Demonstrates how this project differs from existing projects in the Growth and Impact stages.

Note for our vote:
Receive a two-thirds supermajority vote of the TAC to move to Growth Stage. 1

See: https://tac.openwallet.foundation/governance/project-lifecycle/#growth-stage

[JamesKEbert]

2 TAC sponsors to champion the project and provide mentorship as needed.

The thought process here was to pick up our second sponsor at the TAC meeting, but if that's inadvisable I can reach out to other TAC members prior to the meeting.

Development of a growth plan, to be done in conjunction with their project mentor(s) at the TAC.

Development of a project roadmap that provides differentiated features and capabilities and the timeframe for completion.

These still need to be created, but I believe there's a good collection of items for both of these, including the upcoming VCX framework, community development, crates.io publishing, mobile bindings, additional DID methods, etc. I think the most pertinent item for the growth plan is community adoption/involvement/growth.

Document that it is being used successfully in either proof of concepts or pilots by at least two independent end users which, in the TAC’s judgment, are of adequate quality and scope.

VCX is being actively used in Anonyome Lab's DI Edge Agent Mobile SDK, as well as Instnt's Multipass product. The project was also thoroughly used by Absa up until mid-2024 when Absa stepped away from their SSI projects (I think this could speak to the usefulness of VCX, even if the specific company is no longer using the project).

Demonstrate a substantial ongoing flow of commits and merged contributions.

Here's the stats for VCX in the last year (2-13-24 - 2-13-25)
Merged 125 PRs
Published 6 releases in the past year
12 contributors in the past year (with 113 contributors since project inception)
We don't have good metrics on artifact consumption as we've been distributing via Github URL instead of using crates.io (which we'd like to do and plan to do soon)

Demonstrate that the current level of community participation is sufficient to meet the goals outlined in the growth plan and roadmap.

This is where we actually hope to have the most growth by this move to OWF--increasing our level of community involvement, visibility, and adoption. There's a wealth of useful code, tools, and resources in VCX that could benefit many developers.

Demonstrates how this project differs from existing projects in the Growth and Impact stages.

Here's a couple of ways VCX differs from existing projects:

VCX shares many goals of ACA-Py and Credo, which ultimately is a good thing--it allows us to build an ecosystem in which multiple entities can interoperate with each other from diverse different systems. For instance, Instnt uses an ACA-Py issuer and verifier, while the holder agent is using VCX, and Instnt has also used Credo and Bifold as well, and this has only been possible by having shared interoperability targets.

Beyond that though, VCX is built using Rust, which lends itself to increased performance, memory safety, and cross-platform support, among other benefits. This makes it a natural selection for projects already written in Rust, as well as in projects in other languages via wrappers (such as UniFFI).

One of the items on our roadmap is to improve VCX's mobile bindings, allowing native usage by Kotlin / Java for Android and Swift / Objective C for iOS. This is an area that has real demand and is not served by ACA-Py or Credo (as Credo is can only serve the React Native aspect), and that demand can be filled by just VCX instead of having two separate projects and attempting to keep their feature sets in sync, which can end up being really challenging to accomplish.

Also, VCX's approach of providing a diverse set of crates/components provides a large amount of flexibility in how a developer can use the project. For instance, a developer could choose to use just the DID Core crates for DID method resolution and nothing else.

---

I'm happy to clarify any of the above items or answer additional questions that arise 👍

[aceshim]

Hi @JamesKEbert , as a TAC member I'd be happy to sponsor this project.

[gmulhearn]

@aceshim thank you Ace! i'll add you to the proposal