├── CODEOWNERS ├── LICENSE ├── README.md ├── projects ├── OWL.md ├── README.md ├── aca-py.md ├── agent-framework-javascript │ ├── afj-high-level-arch.png │ ├── agent-framework-javascript.md │ └── dependency-licensing-overview.md ├── android-identity-library.md ├── askar.md ├── bifold-wallet │ └── README.md ├── build-wallet-core.md ├── credhub.md ├── dcql-ts.md ├── didcomm-mediator.md ├── eudi-wallet-kit-react-native.md ├── farmworker-wallet-os.md ├── learner-credential-wallet.md ├── mdl-js.md ├── multiformat-vc-ios.md ├── oid4vc-ts.md ├── openid-federation-ts.md ├── rust-tsp.md ├── sd-jwt-dotnet.md ├── sd-jwt-js.md ├── sd-jwt-kotlin.md ├── sd-jwt-python.md ├── sd-jwt-rs.md ├── sd-jwt-vcdm.md ├── solid-data-wallet.md ├── trs.md ├── tuvali.md ├── vc-api-implementation.md ├── vcx.md └── wallet-framework-dotnet.md └── proposal-template.md /CODEOWNERS: -------------------------------------------------------------------------------- 1 | * @rolsonquadras @wenjing @skounis @stefan-kauhaus @davidz25 @aceshim @swcurran 2 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | ![OpenWallet Foundation Logo](https://openwallet.foundation/wp-content/uploads/sites/11/2023/02/OpenWallet_Logo_Color-with-descriptor.svg) 2 | 3 | # Hosting Projects under the OpenWallet Foundation 4 | The OpenWallet Foundation (OWF) is the home to various open source, 5 | open data and/or other open projects relating to or supporting development 6 | of digital wallets, including infrastructure and support initiatives related. 7 | The [OWF Project Lifecycle](https://openwallet-foundation.github.io/tac/governance/project-lifecycle/) 8 | specifies the stages that a project may be admitted under and what the 9 | criteria and expectations are for a given stage, as well as the acceptance 10 | criteria for a project to move from one stage to another. 11 | 12 | The project proposal process is the same for both existing projects which 13 | seek to move into the OpenWallet Foundation and new projects to be formed 14 | within the OpenWallet Foundation. 15 | 16 | This repository will be used for OpenWallet Foundation project proposals. 17 | It contains the [proposal template](./proposal-template.md) and projects 18 | that have been proposed for consideration to the OpenWallet Foundation TAC. 19 | 20 | # Instructions for Proposing a Project 21 | The seed of a new project has to be vetted in a public forum like the 22 | [TAC mailing list](https://lists.openwallet.foundation/g/TAC) before 23 | creating a project proposal. It is best if the project has specific maintainers 24 | with a common software-implemented mission. A clear statement of the problem 25 | and its technical details are helpful to coalesce the community around a 26 | solution and prompt volunteers. 27 | 28 | If this project proposal is for a feature that is unique to an existing 29 | OpenWallet Foundation project, please reach out to that project’s maintainers 30 | to see about joining that project instead of creating a new project proposal. 31 | If discussion with the existing project community leads to not joining, then 32 | the proposal will be reviewed on its own merits as an independent project. 33 | Please note in the proposal the conversations with that project and the reason 34 | for not joining their efforts. 35 | 36 | 1. Fork [this repository](https://github.com/openwallet-foundation/project-proposals). 37 | 2. Copy the `proposal-template.md` file to the `projects` directory and rename 38 | the file to `project-name.md`, where _project-name_ is the name of your project. 39 | 3. Complete the template. 40 | 4. Commit your changes with proper sign-off. This means that your commit 41 | log message must contain a line that looks like the following one, 42 | with your actual name and email address: 43 | 44 | Signed-off-by: Jane Doe 45 | 46 | Adding the `-s` flag to your `git commit` command will add that line 47 | automatically. You can also add it manually as part of your commit 48 | log message or add it afterwards with `git commit --amend -s`. 49 | 5. Submit a pull request. 50 | 51 | # Fixing DCO on Existing Repositories 52 | 53 | In order to bring an existing source base to the OpenWallet Foundation, the repository must have [DCO](https://developercertificate.org/) signoff on all commits. If your existing repository does not have DCO signoff on all commits, you will need to do one of two things: 54 | 55 | 1. bring your code by squashing all of your commits into a single first commit made against a new OWF repo with your DCO sign-off. 56 | 57 | 2. amend the commit history to include DCO sign-off for each of the commits. The Hyperledger Indy community has [documented steps to fix DCO on previous commits](https://github.com/hyperledger/indy-sdk/blob/main/docs/contributors/signing-commits.md#how-to-sign-previous-commits). Also, the [Fix DCO Guide from src-d](https://github.com/src-d/guide/blob/master/developer-community/fix-DCO.md) contains some different steps you can take. 58 | -------------------------------------------------------------------------------- /projects/OWL.md: -------------------------------------------------------------------------------- 1 | # OWL -- Wallet Test Tools 2 | 3 | ## Project Name: OWL 4 | 5 | In proposing to bring the current [Aries Agent Test Harness](https://aries-interop.info) to OWF, we suggest merging into it the [Mobile Agent Test Harness](https://github.com/openwallet-foundation/mobile-wallet-test-harness), currently (but not supposed to be) part of the OWF”s Bifold Wallet project. The Mobile Agent Test Harness uses Aries Agent Test Harness in some of its test cases. We also propose including in this testing project the [Aries Akrida](https://github.com/hyperledger/aries-akrida) repository, an agent load testing tool for deployments of ACA-Py and compatible agents. Akrida’s engine is based on the open source [Locust](https://locust.io/) tool, and instances (single or clustered) of OWF’s [Credo-TS](https://github.com/openwallet-foundation/credo-ts). Together, the three components provide rich testing lab for Agents and Wallets covering compatibility, interoperability, and scalability. 6 | 7 | The OWL name is a nod to the Telecom industry's interoperability "Labs", such as at [UNH](https://www.iol.unh.edu/), where environments are created to enable vendors and product creators can bring their products to test with others. The not-an-acronym name OWL is to prevent confusion with the OpenWallet Foundation's "Labs" maturity level. 8 | 9 | ## Preferred Maturity Level 10 | 11 | We propose that the project be at the “Growth” level. All three of the components have been used extensively in the past and are well documented. Many groups have used the tools in testing their own instances of the various support agents and wallets. As we move the project to OWF and start up the Wallet Interoperability Special Interest Group (link to PR to be added) these tools will be useful in enabling testing across frameworks and deployments built on those deployments. We look to expand their use in both the scope of the testing they enable, and their use by the community. 12 | 13 | The following sub-section covers how Agent Test Harness meets OpenWallet Foundation maturity level criteria for Growth projects. 14 | 15 | ### Growth 16 | 17 | * 2 TAC sponsors to champion the project and provide mentorship as needed. 18 | * Development of a growth plan, to be done in conjunction with their project mentor(s) at the TAC. 19 | * Development of a project roadmap that provides differentiated features and capabilities and the timeframe for completion. 20 | * Defined Roadmap Activities: 21 | * Short Term (3 months) 22 | * Credo Backchannel OOB/DIDExchange Support 23 | * Full Credo AIP 2.0 Support in Backchannel 24 | * RFC 0794 DID Rotate with Credo/ACA-Py/VCX 25 | * Mobile Backchannel Headless App Support 26 | * Migrate AATH to use fully qualified credential identifiers instead of legacy indy 27 | * Remote agent in any role support 28 | * Medium Term (6 Months) 29 | * Expand AnonCreds Handling and Tests 30 | * Large Scenario Tests (test chaining) 31 | * Removal of the AIP 1.0 & 2.0 classifications/handling 32 | * Tests for Proof requests for multiple AnonCreds w/wo revocation 33 | * Backchannels moved to out of AATH and into the Frameworks purview 34 | * Long Term (9 month to 1 year) 35 | * OID4VC support in AATH 36 | * DIDComm V2 Test Scenarios 37 | * 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. 38 | * [Government of British Columbia](https://digital.gov.bc.ca/digital-trust/home/) 39 | * [Indicio, PBC](https://indicio.tech/) 40 | * [GAN](https://gan.foundation/) 41 | * Demonstrate a substantial ongoing flow of commits and merged contributions. 42 | * 29 [Contributors](https://github.com/hyperledger/aries-agent-test-harness/graphs/contributors) and a steady flow of contributions 43 | * Ongoing maintenance to both add and remove tests and components being tested. 44 | * Demonstrate that the current level of community participation is sufficient to meet the goals outlined in the growth plan and roadmap. 45 | * The interoperability and load testing is inherently crucial to all users and contributors to [Credo-TS](https://credo.js.org/), [Bifold Wallet](https://github.com/openwallet-foundation/bifold-wallet), [ACA-Py](https://aca-py.org) and [Aries VCX](https://github.com/hyperledger/aries-vcx) (Aries Framework). 46 | * Since these metrics can vary significantly depending on the type, scope and size of a project, the TAC has final judgment over the level of activity that is adequate to meet these criteria. 47 | * Demonstrates how this project differs from existing projects in the Growth and Impact stages. 48 | 49 | ## Project Description 50 | 51 | OWL is an extensible set of open-source testing tools designed to validate the functionality, scalability, and interoperability of wallets and other components within the decentralized trust ecosystems. A summary of its daily interoperability test runs can be published, such as on the website [https://aries-interop.info](https://aries-interop.info). The test harness components are crucial for ensuring that different decentralized trust agent implementations, which are responsible for handling decentralized identifiers (DIDs) and exchanging verifiable credentials, can interoperate seamlessly. OWL currently includes support for the OWF’s Credo-TS and Bifold projects, plus the proposed ACA-Py project and other [Hyperledger Aries](https://www.hyperledger.org/projects/aries) sub-projects. 52 | 53 | The following are the key features of OWL supported by its different tools. 54 | 55 | * Interoperability Testing: Agent and Mobile Test Harnesses are specifically designed to test the interoperability of wallets and agents by executing interactions between them, ensuring that agent implementations can communicate using standard protocols, exchange verifiable credentials, resolve DIDs, and perform other core functions reliably. 56 | * Load Testing: Akrida provides a scriptable framework for generating load against a deployment of agents for messaging and exchanging credentials. This allows users of OWF technologies to apply a significant generated load on their deployment to ensure it will scale as needed, and to identify and address bottlenecks. 57 | * Automation: Agent Test Harness automates the testing of agents, making it easier for developers to continuously verify the compliance and performance of their implementations. Developers can configure what agent implementations with whom they want to test interoperability and for each, what specific tests they want executed. Implementations can even include their CI pipelines select Agent Test Harness interoperability tests. 58 | * Extensibility: The tools are highly extensible, allowing developers to add their implementations for testing and to construct custom tests and scenarios that suit a wide variety of use cases. This flexibility is important for testing a wide range of decentralized identity solutions across different industries. 59 | * Comprehensive Coverage: OWL covers a wide array of functionalities that decentralized trust agents should support, including secure messaging, protocols, and credential issuance, verification and revocation across a range of credential formats. 60 | * Community-Driven: OWL is developed and maintained by a global community of contributors to ensure that it stays up-to-date with the latest standards and best practices in the decentralized identity space. 61 | 62 | As mentioned in the [Project Name](#project-name-owl) section, we suggest that the newest components, Agent Test Harness and Akrida, be combined into a single project with the Mobile Wallet Test Harness. All will be separate repos in the project, but share common project components (governance, meetings, Discord community, etc.). 63 | 64 | ## Alignment with the OpenWallet Foundation Mission 65 | 66 | OWL supports the OWF’s goals by focusing on interoperability, and the promotion of open standards within the decentralized identity ecosystem. Notably, OWL’s goals in common with the OpenWallet Foundation are: 67 | 68 | 1. Interoperability: The primary purpose of the OWL Test Harnesses are to ensure interoperability between different agents/wallets by validating their ability to communicate using standard protocols like DIDComm and to handle core functions like verifiable credential exchanges. It provides a consistent testing environment to verify that components from different developers and organizations, evolving independently, can work together seamlessly. 69 | 2. Promotion of Open Standards: As an open-source toolset, OWL is built around open standards and protocols, ensuring that the agents it tests comply with widely accepted norms in the decentralized identity space. This approach encourages the adoption of these standards across the industry, fostering a more unified and interoperable ecosystem. 70 | 3. Facilitating Innovation and Adoption: By providing developers with tools to validate their agents with those developed by others in the space, OWL lowers the barriers to entry for creating new, compliant, and interoperable decentralized identity solutions. This facilitates innovation and encourages the adoption of decentralized identity technologies. 71 | 72 | ## Code of Conduct 73 | 74 | OWL follows the [Hyperledger Code of Conduct](https://github.com/hyperledger/aries-agent-test-harness/blob/main/CODE_OF_CONDUCT.md), which is what the OWF code of conduct is based on. 75 | 76 | ## TAC Sponsor 77 | 78 | * Tracy Kuhrt 79 | * Wenjing Chu 80 | 81 | ## Project License 82 | 83 | The project has an Apache 2.0 license: [Agent Test Harness - License](https://github.com/hyperledger/aries-agent-test-harness/blob/main/LICENSE) 84 | 85 | ## Source Control 86 | 87 | The project is hosted in GitHub and includes the following repositories: 88 | 89 | * [Agent Test Harness](https://github.com/hyperledger/aries-agent-test-harness) — test results published to [https://aries-interop.info](https://aries-interop.info) 90 | * [Aries Akrida](https://github.com/hyperledger/aries-akrida) — load testing engine for deployments of ACA-Py and other compatible agents. 91 | * [Mobile Wallet Test Harness](https://github.com/openwallet-foundation/mobile-wallet-test-harness) 92 | 93 | ## Issue Tracker 94 | 95 | Issues are tracked using GitHub's Issues feature in the corresponding repository. 96 | 97 | ## External Dependencies 98 | 99 | The Agent Test Harness part of OWL is built in [Python](https://www.python.org/) using the [Behave](https://github.com/behave/behave) [behavior-driven development](https://en.wikipedia.org/wiki/Behavior-driven_development) (BDD) engine. The repository also contains a component per agent implementation that uses Agent Test Harness. 100 | 101 | Test results from the periodic (thrice weekly) interoperability test runs are pushed for later analysis into an instance (operated by [Government of British Columbia](https://www2.gov.bc.ca/gov/content/home)) of the [Allure](https://allurereport.org/docs/pytestbdd/) behavior driven development reporting tool. Those results are in turn published to [https://aries-interop.info](https://aries-interop.info) via a GitHub action in the Agent Test Harness repository. 102 | 103 | Akrida is built on [Locust](https://locust.io/) and [Credo-TS](https://github.com/openwallet-foundation/credo-ts) to generate loads applied to any deployment. 104 | 105 | ## Release Methodology 106 | 107 | The only “release” from OWL is the test execution results summary published here: [https://aries-interop.info](https://aries-interop.info) 108 | 109 | ## Initial Maintainers 110 | 111 | | Name | Github | Organization | 112 | | --------------- | ----------- | ---------------------------------------- | 113 | | Sheldon Regular | nodlesh | Funded by Government of British Columbia | 114 | | Stephen Curran | swcurran | Funded by Government of British Columbia | 115 | | Kim Ebert | KimEbert42 | Indicio, PBC | 116 | | Alex Walker | anwalker293 | Inidicio, PBC | 117 | | Ian Costanzo | ianco | Funded by Government of British Columbia | 118 | | Timo Glastra | TimoGlastra | Animo Solutions | 119 | 120 | ## Proposed Project Governance 121 | 122 | The current governance model under Hyperledger is consensus-based. This means that decisions are made through discussions, with the aim of community consensus, as outlined in the [Aries Project Charter](https://docs.google.com/document/d/1F6RbR7xDaBt5CDJhqLJzR4c1pDJtyPGshp9fy6eVtSM/edit?usp=sharing). In cases where no clear consensus is established, a project Technical Steering Committee, or the maintainers (those with escalated GitHub privileges) are granted a louder voice. This approach has proven effective. 123 | 124 | ## Links to Documented Governance Practices 125 | 126 | [Project Charter for Aries](https://docs.google.com/document/d/1F6RbR7xDaBt5CDJhqLJzR4c1pDJtyPGshp9fy6eVtSM/edit?usp=sharing). 127 | 128 | ## Financial Sponsorship 129 | 130 | Hyperledger has covered infrastructure related costs. Besides that, None. 131 | 132 | ## Infrastructure 133 | 134 | * GitHub repositories 135 | * CI (GitHub actions) 136 | * Bug Tracking (GitHub Issues and GitHub Projects) 137 | * Communication channels (Discord) 138 | * Mailing list 139 | * Video conference (Zoom) 140 | * Wiki / Meeting Pages (Confluence, likely to move to GitHub/Mkdocs) 141 | * Published Artifacts — Allure (using a Government of British Columbia instance), mkdocs/GH-Pages 142 | -------------------------------------------------------------------------------- /projects/README.md: -------------------------------------------------------------------------------- 1 | Directory that holds the project proposals. 2 | -------------------------------------------------------------------------------- /projects/aca-py.md: -------------------------------------------------------------------------------- 1 | # ACA-Py 2 | 3 | ## Project Name: ACA-Py 4 | 5 | At this time we are planning to keep the name ACA-Py, although we may drop that it is an acronym or change the full name to something that produces the same acronym (perhaps “A Cloud Agent Python” or “ACA-Py is Cloud Agent Python”). Or perhaps someone will come up with a new naming. Naming is hard! 6 | 7 | ## Preferred Maturity Level 8 | 9 | Given the “[1.0.0](https://aca-py.org/latest/CHANGELOG/#100)” maturity of this project, its global recognition (including a [UN “Future of Digital Government” award](https://www.undp.org/policy-centre/singapore/blog/celebrating-future-digital-government)) and its widespread production use, we think ACA-Py should be an “Impact” project at OWF. ACA-Py is broadly used across the world (with [50M+ docker image downloads](https://hub.docker.com/r/bcgovimages/aries-cloudagent)), contains years of evolving contributions, and an [LTS Policy](https://aca-py.org/latest/LTS-Strategy/). ACA-Py includes a “plugins” capability, a [repository](https://plugins.aca-py.org) of up-to-date extensions, and a mature process for contributing and maintaining those plugins. 10 | 11 | The following sub-sections cover how ACA-Py meets OpenWallet Foundation maturity level criteria for Growth and Impact projects. 12 | 13 | ### Growth 14 | 15 | * 2 TAC sponsors to champion the project and provide mentorship as needed. 16 | * Development of a growth plan, to be done in conjunction with their project mentor(s) at the TAC. 17 | * Development of a project roadmap that provides differentiated features and capabilities and the timeframe for completion. 18 | * Defined Roadmap Activities: 19 | * Broader DID registration support, including did:web, did:tdw and others. 20 | * Integration with Servers for publishing did:web and did:tdw DIDs 21 | * Encouragement of [plugins](https://plugins.aca-py.org) publication and continued optimization of plugins 22 | * Expanded support for OpenID4VCs, largely implemented as a [plugin](https://plugins.aca-py.org/latest/oid4vc/) 23 | * Expanded SD-JWT issuing and verification support, based on the OWF [sd-jwt-py](https://github.com/openwallet-foundation-labs/sd-jwt-python) project. 24 | * Support for DIDComm v2 and [TSP](https://trustoverip.github.io/tswg-tsp-specification/) 25 | * Orderly deprecation of AIP v1.0 features 26 | * 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. 27 | * [Government of British Columbia](https://digital.gov.bc.ca/digital-trust/home/) 28 | * [Indicio, PBC](https://indicio.tech/) 29 | * [AYANWORKS](https://www.ayanworks.com/) 30 | * [Anonyome Labs](https://anonyome.com/) 31 | * [DIDx](https://www.didx.co.za/) 32 | * [Northern Block](https://northernblock.io/) 33 | * [CPQD](https://www.cpqd.com.br/) 34 | * [SCOPEfusion](https://scopefusion.net/) 35 | * [GAN](https://gan.foundation/) 36 | * Open Security and Identity inc. 37 | * Demonstrate a substantial ongoing flow of commits and merged contributions. 38 | * 100 [Contributors](https://github.com/hyperledger/aries-cloudagent-python/graphs/contributors) since project inception 39 | * [314 PRs merged since 2024.01.01](https://github.com/hyperledger/aries-cloudagent-python/pulls?q=is%3Apr+is%3Amerged+merged%3A%3E2024-01-01+) 40 | * [50M+ Docker Hub pulls](https://hub.docker.com/r/bcgovimages/aries-cloudagent) 41 | * Demonstrate that the current level of community participation is sufficient to meet the goals outlined in the growth plan and roadmap. 42 | * Contributors driven by organizations with diverse goals — [AIP v2.0](https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0302-aries-interop-profile#aries-interop-profile-version-20) and beyond, OpenID4VCs, DIDComm v2, mDL, [UN Transparency Protocol](https://uncefact.github.io/spec-untp/), [W3C VC-API](https://w3c-ccg.github.io/vc-api/), technical debt elimination, and so on. The community participation allows for coherent progress on a variety of goals in parallel. The maintainer community coordinates the additions, recommending new features be added in the core and in plugins. 43 | * Since these metrics can vary significantly depending on the type, scope and size of a project, the TAC has final judgment over the level of activity that is adequate to meet these criteria. 44 | * Demonstrates how this project differs from existing projects in the Growth and Impact stages. 45 | * ACA-Py is a companion to the [Credo-TS](https://github.com/openwallet-foundation/credo-ts) and [Bifold Wallet](https://github.com/openwallet-foundation/bifold-wallet) projects— a server side digital trust framework and toolkit. 46 | * ACA-Py has a dependency on the OWF [sd-jwt-py](https://github.com/openwallet-foundation-labs/sd-jwt-python) project. 47 | * Several other OWF Projects are candidates to be imported into ACA-Py. 48 | 49 | ### Impact 50 | 51 | * Have a defined governing body of at least 5 or more members (owners and core maintainers), of which no more than one-third is affiliated with the same employer. In the case there are 5 governing members, 2 may be from the same employer. 52 | * [Government of British Columbia](https://digital.gov.bc.ca/digital-trust/home/) 53 | * [Indicio, PBC](https://indicio.tech/) 54 | * [AYANWORKS](https://www.ayanworks.com/) 55 | * [Anonyome Labs](https://anonyome.com/) 56 | * [Northern Block](https://northernblock.io/) 57 | * [CPQD](https://www.cpqd.com.br/) 58 | * Have a documented and publicly accessible description of the project's governance, decision-making, and release processes. 59 | * Initially the [Aries Project Charter](https://docs.google.com/document/d/1F6RbR7xDaBt5CDJhqLJzR4c1pDJtyPGshp9fy6eVtSM/edit?usp=drive_link) and Aries [TSC.md](https://github.com/hyperledger/aries/blob/main/TSC.md) and [MAINTAINERS.md](https://github.com/hyperledger/aries/blob/main/MAINTAINERS.md) and evolving them to be ACA-Py specific in the OWF context. 60 | * Have a healthy number of maintainers from at least two organizations. A maintainer is defined as someone with the commit bit; i.e., someone who can accept contributions to some or all of the project. 61 | * 100 total [contributors](https://github.com/hyperledger/aries-cloudagent-python/graphs/contributors) 62 | * Maintainers are currently from 2 Organizations (BC Gov, Indicio), but we have a number of other contributors more than capable of being maintainers, with the process started for one to become a maintainer. 63 | * Have a Code of Conduct in a form acceptable to the OpenWallet Foundation. 64 | * Based on the Hyperledger Code of Conduct 65 | * Explicitly define a project governance and maintainer process. This is preferably laid out in a GOVERNANCE.md file and references a CONTRIBUTING.md and MAINTAINERS.md file showing the current and emeritus maintainers (see MAINTAINERS.md File Contents for more information). 66 | * Initially the[ Aries Project Charter](https://docs.google.com/document/d/1F6RbR7xDaBt5CDJhqLJzR4c1pDJtyPGshp9fy6eVtSM/edit?usp=drive_link) and Aries[ TSC.md](https://github.com/hyperledger/aries/blob/main/TSC.md) and[ MAINTAINERS.md](https://github.com/hyperledger/aries/blob/main/MAINTAINERS.md) and evolving them to be ACA-Py specific in the OWF context. 67 | * Document that it is being used successfully in production by at least two independent end users which, in the TAC’s judgment, are of adequate quality and scope. 68 | * [Government of British Columbia](https://digital.gov.bc.ca/digital-trust/home/) 69 | * [Indicio, PBC](https://indicio.tech/) 70 | * [AYANWORKS](https://www.ayanworks.com/) 71 | * [Anonyome Labs](https://anonyome.com/) 72 | * [DIDx](https://www.didx.co.za/) 73 | * [Northern Block](https://northernblock.io/) 74 | * [CPQD](https://www.cpqd.com.br/) 75 | * Have a public list of project adopters for at least the primary repo (e.g., ADOPTERS.md or logos on the project website). 76 | * We have not collected this information to now, but will add it to the repo. 77 | * Have a good standing with respect to security. 78 | * We have excellent practices around the use of dependabot, and the regular updating of all dependencies, including a track record of updating the version of Python supported. 79 | * Other metrics as defined by the applying Project during the application process in cooperation with the TAC. 80 | * Receive a supermajority vote from the TAC to move to Impact stage. Projects can move directly from Labs to Impact, if they can demonstrate sufficient maturity and have met all requirements. 81 | 82 | ## Project Description 83 | 84 | ACA-Py (Aries Cloud Agent Python) is an open-source framework designed to facilitate the creation, management, and utilization of decentralized digital identities. ACA-Py enables secure, interoperable communication between entities using decentralized identifiers (DIDs) and verifiable credentials, adhering to standards such as DIDComm, OpenID4VCs and the W3C Verifiable Credentials. 85 | 86 | It is both a full implementation of Aries Interop Profile (AIP) 2.0 and a toolkit for building issuers and verifiers beyond the AIP protocols, such as using [OpenID4VCs](https://openid.net/sg/openid4vc/) and the [UN Transparency Protocol](https://uncefact.github.io/spec-untp/) (UNTP). ACA-Py operates in the second and third layers of the [Trust Over IP framework](https://trustoverip.org/toip-model/) using DIDComm messaging and Aries DIDComm and other credential exchange protocols. The "cloud" in the name means that ACA-Py runs on servers (cloud, enterprise, IoT devices, and so forth), and is not designed to run on mobile devices. 87 | 88 | While ACA-Py continues to support its initial DIDComm and Aries technical stack, it has evolved to include support for other important Verifiable Credential technologies, including OpenID4VCs and SD-JWTs, W3C VCDM Data Integrity credentials, a variety of DID Methods, and more. The “toolkit” nature of ACA-Py allows for it to be easily deployed in a wide variety of decentralized trust use cases. ACA-Py’s welcoming community and plugin-based extensibility makes it easy for others to build on its strong foundations. 89 | 90 | ACA-Py emphasizes security, privacy, and user control, aligning with the broader goals of fostering an open, interoperable, and decentralized identity ecosystem. It is actively maintained and developed by a global community, contributing to the advancement of digital identity solutions. 91 | 92 | ACA-Py includes [published documentation](https://aca-py.org/), a formal plugins model with a [repository of maintained plugins](plugins.aca-py.org), a tools repository, a powerful deployment load testing capability, and a repository of example controllers. 93 | 94 | ## Alignment with the OpenWallet Foundation Mission 95 | 96 | ACA-Py supports the OWF’s goals by providing the technological foundation necessary for secure, interoperable, and user-centric digital identity management within open-source digital wallets. Notably, ACA-Py’s goals in common with the OpenWallet Foundation are: 97 | 98 | 1. **Interoperability**: A core mission of ACA-Py is to enable interoperability between different agents and systems in the decentralized identity ecosystem. It is designed to support various protocols like DIDComm and OpenID4VCs and credential formats like AnonCreds and the W3C Verifiable Credentials Data Model, allowing different entities to communicate securely and efficiently. 99 | 2. **Open-Source Collaboration**: As an open-source project, ACA-Py encourages collaboration among developers, organizations, and governments to build and improve decentralized identity solutions. This open-source approach ensures transparency, security, and continuous innovation. 100 | 3. **Decentralized Identity**: ACA-Py is at the forefront of decentralized identity management, providing tools for creating, managing, and using decentralized identifiers (DIDs) and verifiable credentials. ACA-Py enables a user-centric approach to identity, where individuals control their own data and how it is shared. 101 | 4. **Security and Privacy**: Security and privacy are foundational to ACA-Py’s architecture, focusing on secure communication, storage, key management and data minimization. 102 | 103 | ## Code of Conduct 104 | 105 | ACA-Py follows the [Hyperledger Code of Conduct](https://github.com/hyperledger/aries-cloudagent-python/blob/main/CODE_OF_CONDUCT.md), which is what the OWF code of conduct is based on. 106 | 107 | ## TAC Sponsor 108 | 109 | * Tracy Kuhrt 110 | * Wenjing Chu 111 | 112 | ## Project License 113 | 114 | The project has an Apache 2.0 license: [ACA-Py - License](https://github.com/hyperledger/aries-cloudagent-python/blob/main/LICENSE) 115 | 116 | ## Source Control 117 | 118 | The project is hosted in GitHub and includes the following repositories: 119 | 120 | * [ACA-Py](https://github.com/hyperledger/aries-cloudagent-python) — documentation published to https://aca-py.org 121 | * [ACA-Py Plugins](https://github.com/hyperledger/aries-acapy-plugins) — registry published to [https://plugins.aca-py.org](https://plugins.aca-py.org) 122 | * [ACA-Py Tools](https://github.com/hyperledger/aries-acapy-tools) — various tools related to ACA-Py including those for upgrade data migrations. 123 | * [ACA-Py Controllers](https://github.com/hyperledger/aries-acapy-controllers/blob/main/AliceFaberAcmeDemo/README.md) — demos of Aries ACA-Py controllers (business logic) using different technical stacks. 124 | * [VC-Authn-OIDC](https://github.com/bcgov/vc-authn-oidc) — a multi-tenant OpenIDConnect Identity Provider (IdP) component to enable OIDC Relying Parties to use Verifiable Credential presentations for authentication. 125 | 126 | ## Issue Tracker 127 | 128 | Issues are tracked using GitHub's Issues feature in the corresponding repository. 129 | 130 | ## External Dependencies 131 | 132 | The ACA-Py dependency list is maintained in the [source repository](https://github.com/hyperledger/aries-cloudagent-python/blob/main/pyproject.toml). A NOTICES file is also in the repository, but needs to be updated. All of the 133 | dependencies are open source, and we believe most use the Apache 2 license, but some legwork may be required to verify that. 134 | 135 | ## Release Methodology 136 | 137 | All proposed repositories have continuous deployment/delivery pipelines built using [GitHub Actions](https://github.com/features/actions). The individual packages follow the [semantic versioning](https://semver.org/) method, ensuring consistency and safety. 138 | 139 | ## Initial Maintainers 140 | 141 | | Name | Github | Organization | 142 | | ---------------- | --------------- | ---------------------------------------- | 143 | | Daniel Bluhm | dbluhm | Indicio, PBC | 144 | | Stephen Curran | swcurran | Funded by Government of British Columbia | 145 | | Wade Barnes | WadeBarnes | Funded by Government of British Columbia | 146 | | Jamie Hale | jamshale | Funded by Government of British Columbia | 147 | | Andrew Whitehead | andrewwhitehead | Funded by Government of British Columbia | 148 | | Clement Humbert | chumbert | SICPA | 149 | 150 | ## Proposed Project Governance 151 | 152 | The current governance model under Hyperledger is consensus-based. This means that decisions are made through discussions, with the aim of community consensus, as outlined in the [Aries Project Charter](https://docs.google.com/document/d/1F6RbR7xDaBt5CDJhqLJzR4c1pDJtyPGshp9fy6eVtSM/edit?usp=sharing). In cases where no clear consensus is established, a project Technical Steering Committee, or the maintainers (those with escalated GitHub privileges) are granted a louder voice. This approach has proven effective. 153 | 154 | ## Links to Documented Governance Practices 155 | 156 | [Project Charter for Aries](https://docs.google.com/document/d/1F6RbR7xDaBt5CDJhqLJzR4c1pDJtyPGshp9fy6eVtSM/edit?usp=sharing). 157 | 158 | ## Financial Sponsorship 159 | 160 | Hyperledger has covered infrastructure related costs. Besides that, None. 161 | 162 | ## Infrastructure 163 | 164 | * GitHub repositories 165 | * CI (GitHub actions) 166 | * Bug Tracking (GitHub Issues and GitHub Projects) 167 | * Communication channels (Discord) 168 | * Mailing list 169 | * Video conference (Zoom) 170 | * Wiki / Meeting Pages (Confluence, likely to move to GitHub/Mkdocs) 171 | * Published Artifacts — PyPi, GHCR, mkdocs/GH-Pages 172 | -------------------------------------------------------------------------------- /projects/agent-framework-javascript/afj-high-level-arch.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/openwallet-foundation/project-proposals/923a60087448b8a0046e7cd2635e3cd9017b229c/projects/agent-framework-javascript/afj-high-level-arch.png -------------------------------------------------------------------------------- /projects/agent-framework-javascript/agent-framework-javascript.md: -------------------------------------------------------------------------------- 1 | # Project Name 2 | 3 | This is still up for debate. Until then, the working title is _Agent Framework JavaScript_. 4 | 5 | # Preferred Maturity Level 6 | 7 | Considering the fact that the project has been adopted by various companies and governments, and powers a number of production use cases, the _impact_ stage seems appropriate. However, the project does not fulfill the "is commonly used in enterprise production environments". 8 | 9 | Therefore, the project is estimated to be in the _growth_ stage, approaching the _impact_ stage. 10 | 11 | # Project Description 12 | 13 | Aries Framework JavaScript has evolved significantly since its inception as a Hyperledger Aries project. Initially, it heavily relied on Hyperledger standards such as DIDComm, Indy, and AnonCreds. However, with advancements in verifiable credential technology and the emergence of new standards, the framework underwent multiple refactoring and modularization processes to maintain interoperability. 14 | 15 | This allowed for the inclusion of non-Hyperledger standards like W3C Verifiable Credentials with Data Integrity Proofs, DIF Presentation Exchange, OpenID4VC, and SD-JWT integration. As industry requirements shifted towards greater modularity, it became apparent that a unified framework may be better. 16 | 17 | The future direction for Aries Framework JavaScript involves adopting a compartmentalized approach consisting of single-purpose libraries designed to work together seamlessly, building on what is already out there. This transition will take considerable effort and will, therefore, be gradual. 18 | 19 | In order to expand the framework's support for standards beyond the Hyperledger ecosystem, a reassessment of its governance was necessary. The OpenWallet Foundation (OWF) has been considered a potential steward due to its commitment to promoting interoperability without directly developing or maintaining standard protocols. 20 | 21 | ![afj-high-level-arch.png](./afj-high-level-arch.png) 22 | 23 | > **NOTE1:** In addition to the [Aries Framework JavaScript repository](https://github.com/hyperledger/aries-framework-javascript), we propose moving the [Aries Framework JavaScript Extensions](https://github.com/hyperledger/aries-framework-javascript-ext) repository too, due to its tight relationship with the framework. 24 | > 25 | > **NOTE2:** Another Hyperledger project that is tightly related to the framework is [Aries Mobile Agent React Native (a.k.a. Bifold)](https://github.com/hyperledger/aries-mobile-agent-react-native). This project is maintained by a different set of people and is therefore not included in this proposal. 26 | 27 | # Alignment with the OpenWallet Foundation Mission 28 | 29 | The objective is to promote interoperability by supporting numerous standards, as was outlined earlier. As a Hyperledger project, all components have been open source from the beginning. 30 | 31 | Maintainers will persist in collaborating with Standards Development Organizations (SDOs) across ecosystems, as done previously. 32 | 33 | # Code of Conduct 34 | 35 | Both Hyperledger and the OpenWallet Foundation follow the [Linux Foundation's Europe Policies](https://8112310.fs1.hubspotusercontent-na1.net/hubfs/8112310/Exhibit%20B%20--%20Linux%20Foundation%20Europe%20Policies.pdf) 36 | 37 | # TAC Sponsor 38 | 39 | - Tracy Kuhrt 40 | - Stavros Kounis 41 | 42 | # Project License 43 | 44 | The project has an Apache 2.0 license: [Aries Framework JavaScript - License)](https://github.com/hyperledger/aries-framework-javascript%23license) 45 | 46 | # Source Control 47 | 48 | The project is hosted in GitHub and includes the following repositories: 49 | 50 | - The framework [Aries Framework JavaScript)](https://github.com/hyperledger/aries-framework-javascript%23license) 51 | - The framework's extensions: [Aries Framework JavaScript Extensions](https://github.com/hyperledger/aries-framework-javascript-ext%23license) 52 | 53 | # Issue Tracker 54 | 55 | The issues are tracked using GitHub's Issues feature in the corresponding repository. For issues that span across multiple repositories, GitHub's Projects feature may be used. 56 | 57 | # External Dependencies 58 | 59 | Please see [Aries Framework JavaScript - Dependency Licenses](./dependency-licensing-overview.md) 60 | 61 | # Release Methodology 62 | 63 | All proposed repositories have continuous deployment/delivery pipelines built using [GitHub Actions](https://github.com/features/actions). The individual packages follow the [_semantic versioning_](https://semver.org/) method, ensuring consistency and safety. Whenever a pull request is merged into the `main` branch that doesn't cause a _major_, _minor_ or _patch_ version increase, an _alpha_ version is released. 64 | 65 | # Initial Maintainers 66 | 67 | | name | Github | Organization | 68 | | ------------------ | ---------------------------------------------------------- | --------------- | 69 | | Berend Sliedrecht | [@berendsliedrecht](https://github.com/berendsliedrecht) | Animo Solutions | 70 | | Jakub Kočí | [@jakubkoci](https://github.com/jakubkoci) | Absa Group | 71 | | James Ebert | [@JamesKEbert](https://github.com/JamesKEbert) | Indicio | 72 | | Karim Stekelenburg | [@karimStekelenburg](https://github.com/karimStekelenburg) | Animo Solutions | 73 | | Timo Glastra | [@TimoGlastra](https://github.com/TimoGlastra) | Animo Solutions | 74 | | Ariel Gentile | [@genaris](https://github.com/genaris) | 2060.io | 75 | | Jan Rietveld | [@janrtvld](https://github.com/janrtvld) | Animo Solutions | 76 | | | | | 77 | 78 | # Proposed Project Governance 79 | 80 | The current governance model under Hyperledger is community-based. This means that decisions are made democratically, with the aim of community consensus. In cases where no clear consensus is established, active contributors may be granted a louder voice. 81 | 82 | This approach has proven effective and will be continued as the chosen governance model. 83 | 84 | # Links to Documented Governance Practices 85 | 86 | > Work in progress. The intake form has been submitted. 87 | 88 | # Financial Sponsorship 89 | 90 | Hyperledger has covered infrastructure related costs. Besides that, None. 91 | 92 | # Infrastructure 93 | 94 | - GitHub repositories 95 | - CI (GitHub actions) 96 | - Bug Tracking (GitHub Issues and GitHub Projects) 97 | - Communication channels (Discord) 98 | - Mailing list 99 | - Video conference (Zoom) 100 | -------------------------------------------------------------------------------- /projects/agent-framework-javascript/dependency-licensing-overview.md: -------------------------------------------------------------------------------- 1 | # Aries Framework JavaScript - Dependency Licenses 2 | 3 | This document is aimed at providing insight about licensing for all **direct** dependencies of the repositories proposed to move. Each of the following sections is divided into sub sections. This is because all repositories are so called *mono-repos* and contains multiple packages. These packages are ultimately what ends up in the package manager repositories. 4 | 5 | ## Aries Framework JavaScript 6 | 7 | ### @aries-framework/action-menu 8 | 9 | |
Dependency
|
Version
|
License
|
Link
| 10 | | ---------- | ------- | ------- | ---- | 11 | | @aries-framework/core | 0.4.2 | Apache-2.0 | [@aries-framework/core](git+https://github.com/hyperledger/aries-framework-javascript.git) | 12 | | class-transformer | 0.5.1 | MIT | [class-transformer](git+https://github.com/typestack/class-transformer.git) | 13 | | class-validator | 0.14.0 | MIT | [class-validator](git+https://github.com/typestack/class-validator.git) | 14 | | rxjs | 7.8.0 | Apache-2.0 | [rxjs](git+https://github.com/reactivex/rxjs.git) | 15 | 16 | ### @aries-framework/anoncreds-rs 17 | 18 | |
Dependency
|
Version
|
License
|
Link
| 19 | | ---------- | ------- | ------- | ---- | 20 | | @aries-framework/anoncreds | 0.4.2 | Apache-2.0 | [@aries-framework/anoncreds](git+https://github.com/hyperledger/aries-framework-javascript.git) | 21 | | @aries-framework/core | 0.4.2 | Apache-2.0 | [@aries-framework/core](git+https://github.com/hyperledger/aries-framework-javascript.git) | 22 | | class-transformer | 0.5.1 | MIT | [class-transformer](git+https://github.com/typestack/class-transformer.git) | 23 | | class-validator | 0.14.0 | MIT | [class-validator](git+https://github.com/typestack/class-validator.git) | 24 | | rxjs | 7.8.0 | Apache-2.0 | [rxjs](git+https://github.com/reactivex/rxjs.git) | 25 | | tsyringe | 4.8.0 | MIT | [tsyringe](git+https://github.com/Microsoft/tsyringe.git) | 26 | 27 | ### @aries-framework/anoncreds 28 | 29 | |
Dependency
|
Version
|
License
|
Link
| 30 | | ---------- | ------- | ------- | ---- | 31 | | @aries-framework/core | 0.4.2 | Apache-2.0 | [@aries-framework/core](git+https://github.com/hyperledger/aries-framework-javascript.git) | 32 | | bn.js | 5.2.1 | MIT | [bn.js](git+ssh://git@github.com/indutny/bn.js.git) | 33 | | class-transformer | 0.5.1 | MIT | [class-transformer](git+https://github.com/typestack/class-transformer.git) | 34 | | class-validator | 0.14.0 | MIT | [class-validator](git+https://github.com/typestack/class-validator.git) | 35 | | reflect-metadata | 0.1.13 | Apache-2.0 | [reflect-metadata](git+https://github.com/rbuckton/reflect-metadata.git) | 36 | 37 | ### @aries-framework/askar 38 | 39 | |
Dependency
|
Version
|
License
|
Link
| 40 | | ---------- | ------- | ------- | ---- | 41 | | @aries-framework/core | 0.4.2 | Apache-2.0 | [@aries-framework/core](git+https://github.com/hyperledger/aries-framework-javascript.git) | 42 | | bn.js | 5.2.1 | MIT | [bn.js](git+ssh://git@github.com/indutny/bn.js.git) | 43 | | class-transformer | 0.5.1 | MIT | [class-transformer](git+https://github.com/typestack/class-transformer.git) | 44 | | class-validator | 0.14.0 | MIT | [class-validator](git+https://github.com/typestack/class-validator.git) | 45 | | rxjs | 7.8.0 | Apache-2.0 | [rxjs](git+https://github.com/reactivex/rxjs.git) | 46 | | tsyringe | 4.8.0 | MIT | [tsyringe](git+https://github.com/Microsoft/tsyringe.git) | 47 | 48 | ### @aries-framework/bbs-signatures 49 | 50 | |
Dependency
|
Version
|
License
|
Link
| 51 | | ---------- | ------- | ------- | ---- | 52 | | @aries-framework/core | 0.4.2 | Apache-2.0 | [@aries-framework/core](git+https://github.com/hyperledger/aries-framework-javascript.git) | 53 | | @mattrglobal/bbs-signatures | 1.3.1 | Apache-2.0 | [@mattrglobal/bbs-signatures](https://github.com/mattrglobal/bbs-signatures) | 54 | | @mattrglobal/bls12381-key-pair | 1.0.0 | n/a | [@mattrglobal/bls12381-key-pair](git+https://github.com/mattrglobal/bls12381-key-pair) | 55 | | @stablelib/random | 1.0.2 | MIT | [@stablelib/random](git+https://github.com/StableLib/stablelib.git) | 56 | 57 | ### @aries-framework/cheqd 58 | 59 | |
Dependency
|
Version
|
License
|
Link
| 60 | | ---------- | ------- | ------- | ---- | 61 | | @aries-framework/anoncreds | 0.4.2 | Apache-2.0 | [@aries-framework/anoncreds](git+https://github.com/hyperledger/aries-framework-javascript.git) | 62 | | @aries-framework/core | 0.4.2 | Apache-2.0 | [@aries-framework/core](git+https://github.com/hyperledger/aries-framework-javascript.git) | 63 | | @cheqd/sdk | 2.3.0 | Apache-2.0 | [@cheqd/sdk](git+https://github.com/cheqd/sdk.git) | 64 | | @cheqd/ts-proto | 2.2.2 | Apache-2.0 | [@cheqd/ts-proto](git+https://github.com/cheqd/ts-proto.git) | 65 | | @cosmjs/crypto | 0.29.5 | Apache-2.0 | [@cosmjs/crypto](https://github.com/cosmos/cosmjs/tree/main/packages/crypto) | 66 | | @cosmjs/proto-signing | 0.31.1 | Apache-2.0 | [@cosmjs/proto-signing](https://github.com/cosmos/cosmjs/tree/main/packages/proto-signing) | 67 | | @stablelib/ed25519 | 1.0.3 | MIT | [@stablelib/ed25519](git+https://github.com/StableLib/stablelib.git) | 68 | | class-transformer | 0.5.1 | MIT | [class-transformer](git+https://github.com/typestack/class-transformer.git) | 69 | | class-validator | 0.14.0 | MIT | [class-validator](git+https://github.com/typestack/class-validator.git) | 70 | | rxjs | 7.8.0 | Apache-2.0 | [rxjs](git+https://github.com/reactivex/rxjs.git) | 71 | | tsyringe | 4.8.0 | MIT | [tsyringe](git+https://github.com/Microsoft/tsyringe.git) | 72 | 73 | ### @aries-framework/core 74 | 75 | |
Dependency
|
Version
|
License
|
Link
| 76 | | ---------- | ------- | ------- | ---- | 77 | | @digitalcredentials/jsonld | 5.2.1 | BSD-3-Clause | [@digitalcredentials/jsonld](git+https://github.com/digitalcredentials/jsonld.js.git) | 78 | | @digitalcredentials/jsonld-signatures | 9.3.2 | BSD-3-Clause | [@digitalcredentials/jsonld-signatures](git+https://github.com/digitalcredentials/jsonld-signatures.git) | 79 | | @digitalcredentials/vc | 1.1.2 | BSD-3-Clause | [@digitalcredentials/vc](git+https://github.com/digitalcredentials/vc-js.git) | 80 | | @multiformats/base-x | 4.0.1 | MIT | [@multiformats/base-x](https://github.com/gozala/@multiformats/base-x.git) | 81 | | @stablelib/ed25519 | 1.0.3 | MIT | [@stablelib/ed25519](git+https://github.com/StableLib/stablelib.git) | 82 | | @stablelib/random | 1.0.2 | MIT | [@stablelib/random](git+https://github.com/StableLib/stablelib.git) | 83 | | @stablelib/sha256 | 1.0.1 | MIT | [@stablelib/sha256](git+https://github.com/StableLib/stablelib.git) | 84 | | @types/ws | 8.5.5 | MIT | [@types/ws](https://github.com/DefinitelyTyped/DefinitelyTyped.git) | 85 | | abort-controller | 3.0.0 | MIT | [abort-controller](git+https://github.com/mysticatea/abort-controller.git) | 86 | | big-integer | 1.6.51 | Unlicense | [big-integer](git+ssh://git@github.com/peterolson/BigInteger.js.git) | 87 | | borc | 3.0.0 | MIT | [borc](git+https://github.com/dignifiedquire/borc.git) | 88 | | buffer | 6.0.3 | MIT | [buffer](git://github.com/feross/buffer.git) | 89 | | class-transformer | 0.5.1 | MIT | [class-transformer](git+https://github.com/typestack/class-transformer.git) | 90 | | class-validator | 0.14.0 | MIT | [class-validator](git+https://github.com/typestack/class-validator.git) | 91 | | did-resolver | 4.1.0 | Apache-2.0 | [did-resolver](git+ssh://git@github.com/decentralized-identity/did-resolver.git) | 92 | | lru_map | 0.4.1 | MIT | [lru_map](git+https://github.com/rsms/js-lru.git) | 93 | | luxon | 3.3.0 | MIT | [luxon](git+https://github.com/moment/luxon.git) | 94 | | make-error | 1.3.6 | ISC | [make-error](git://github.com/JsCommunity/make-error.git) | 95 | | object-inspect | 1.12.3 | MIT | [object-inspect](git://github.com/inspect-js/object-inspect.git) | 96 | | query-string | 7.1.3 | MIT | [query-string](git+https://github.com/sindresorhus/query-string.git) | 97 | | reflect-metadata | 0.1.13 | Apache-2.0 | [reflect-metadata](git+https://github.com/rbuckton/reflect-metadata.git) | 98 | | rxjs | 7.8.0 | Apache-2.0 | [rxjs](git+https://github.com/reactivex/rxjs.git) | 99 | | tsyringe | 4.8.0 | MIT | [tsyringe](git+https://github.com/Microsoft/tsyringe.git) | 100 | | uuid | 9.0.1 | MIT | [uuid](git+https://github.com/uuidjs/uuid.git) | 101 | | varint | 6.0.0 | MIT | [varint](git://github.com/chrisdickinson/varint.git) | 102 | | web-did-resolver | 2.0.27 | Apache-2.0 | [web-did-resolver](git+ssh://git@github.com/decentralized-identity/web-did-resolver.git) | 103 | 104 | ### @aries-framework/indy-sdk-to-askar-migration 105 | 106 | |
Dependency
|
Version
|
License
|
Link
| 107 | | ---------- | ------- | ------- | ---- | 108 | | @aries-framework/anoncreds | 0.4.2 | Apache-2.0 | [@aries-framework/anoncreds](git+https://github.com/hyperledger/aries-framework-javascript.git) | 109 | | @aries-framework/askar | 0.4.2 | Apache-2.0 | [@aries-framework/askar](git+https://github.com/hyperledger/aries-framework-javascript.git) | 110 | | @aries-framework/core | 0.4.2 | Apache-2.0 | [@aries-framework/core](git+https://github.com/hyperledger/aries-framework-javascript.git) | 111 | | @aries-framework/node | 0.4.2 | Apache-2.0 | [@aries-framework/node](git+https://github.com/hyperledger/aries-framework-javascript.git) | 112 | 113 | ### @aries-framework/indy-sdk 114 | 115 | |
Dependency
|
Version
|
License
|
Link
| 116 | | ---------- | ------- | ------- | ---- | 117 | | @aries-framework/anoncreds | 0.4.2 | Apache-2.0 | [@aries-framework/anoncreds](git+https://github.com/hyperledger/aries-framework-javascript.git) | 118 | | @aries-framework/core | 0.4.2 | Apache-2.0 | [@aries-framework/core](git+https://github.com/hyperledger/aries-framework-javascript.git) | 119 | | @stablelib/ed25519 | 1.0.3 | MIT | [@stablelib/ed25519](git+https://github.com/StableLib/stablelib.git) | 120 | | @types/indy-sdk | 1.16.27 | MIT | [@types/indy-sdk](https://github.com/DefinitelyTyped/DefinitelyTyped.git) | 121 | | class-transformer | 0.5.1 | MIT | [class-transformer](git+https://github.com/typestack/class-transformer.git) | 122 | | class-validator | 0.14.0 | MIT | [class-validator](git+https://github.com/typestack/class-validator.git) | 123 | | rxjs | 7.8.0 | Apache-2.0 | [rxjs](git+https://github.com/reactivex/rxjs.git) | 124 | | tsyringe | 4.8.0 | MIT | [tsyringe](git+https://github.com/Microsoft/tsyringe.git) | 125 | 126 | ### @aries-framework/indy-vdr 127 | 128 | |
Dependency
|
Version
|
License
|
Link
| 129 | | ---------- | ------- | ------- | ---- | 130 | | @aries-framework/anoncreds | 0.4.2 | Apache-2.0 | [@aries-framework/anoncreds](git+https://github.com/hyperledger/aries-framework-javascript.git) | 131 | | @aries-framework/core | 0.4.2 | Apache-2.0 | [@aries-framework/core](git+https://github.com/hyperledger/aries-framework-javascript.git) | 132 | 133 | ### @aries-framework/node 134 | 135 | |
Dependency
|
Version
|
License
|
Link
| 136 | | ---------- | ------- | ------- | ---- | 137 | | @2060.io/ffi-napi | 4.0.8 | MIT | [@2060.io/ffi-napi](git+ssh://git@github.com/node-ffi-napi/node-ffi-napi.git) | 138 | | @2060.io/ref-napi | 3.0.6 | MIT | [@2060.io/ref-napi](git://github.com/node-ffi-napi/ref-napi.git) | 139 | | @aries-framework/core | 0.4.2 | Apache-2.0 | [@aries-framework/core](git+https://github.com/hyperledger/aries-framework-javascript.git) | 140 | | @types/express | 4.17.18 | MIT | [@types/express](https://github.com/DefinitelyTyped/DefinitelyTyped.git) | 141 | | express | 4.18.2 | MIT | [express](git+https://github.com/expressjs/express.git) | 142 | | ws | 8.13.0 | MIT | [ws](git+https://github.com/websockets/ws.git) | 143 | 144 | ### @aries-framework/openid4vc-client 145 | 146 | |
Dependency
|
Version
|
License
|
Link
| 147 | | ---------- | ------- | ------- | ---- | 148 | | @aries-framework/core | 0.4.2 | Apache-2.0 | [@aries-framework/core](git+https://github.com/hyperledger/aries-framework-javascript.git) | 149 | | @sphereon/openid4vci-client | 0.4.0 | Apache-2.0 | [@sphereon/openid4vci-client](https://registry.npmjs.org/@sphereon/openid4vci-client/-/openid4vci-client-0.4.0.tgz) | 150 | | @stablelib/random | 1.0.2 | MIT | [@stablelib/random](git+https://github.com/StableLib/stablelib.git) | 151 | 152 | ### @aries-framework/question-answer 153 | 154 | |
Dependency
|
Version
|
License
|
Link
| 155 | | ---------- | ------- | ------- | ---- | 156 | | @aries-framework/core | 0.4.2 | Apache-2.0 | [@aries-framework/core](git+https://github.com/hyperledger/aries-framework-javascript.git) | 157 | | class-transformer | 0.5.1 | MIT | [class-transformer](git+https://github.com/typestack/class-transformer.git) | 158 | | class-validator | 0.14.0 | MIT | [class-validator](git+https://github.com/typestack/class-validator.git) | 159 | | rxjs | 7.8.0 | Apache-2.0 | [rxjs](git+https://github.com/reactivex/rxjs.git) | 160 | 161 | ### @aries-framework/react-native 162 | 163 | |
Dependency
|
Version
|
License
|
Link
| 164 | | ---------- | ------- | ------- | ---- | 165 | | @aries-framework/core | 0.4.2 | Apache-2.0 | [@aries-framework/core](git+https://github.com/hyperledger/aries-framework-javascript.git) | 166 | | @azure/core-asynciterator-polyfill | 1.0.2 | MIT | [@azure/core-asynciterator-polyfill](https://github.com/Azure/azure-sdk-for-js/tree/main/sdk/core/core-asynciterator-polyfill/README.md) | 167 | | events | 3.3.0 | MIT | [events](git://github.com/Gozala/events.git) | 168 | 169 | ### @aries-framework/sd-jwt-vc 170 | 171 | |
Dependency
|
Version
|
License
|
Link
| 172 | | ---------- | ------- | ------- | ---- | 173 | | @aries-framework/askar | 0.4.2 | Apache-2.0 | [@aries-framework/askar](git+https://github.com/hyperledger/aries-framework-javascript.git) | 174 | | @aries-framework/core | 0.4.2 | Apache-2.0 | [@aries-framework/core](git+https://github.com/hyperledger/aries-framework-javascript.git) | 175 | | class-transformer | 0.5.1 | MIT | [class-transformer](git+https://github.com/typestack/class-transformer.git) | 176 | | class-validator | 0.14.0 | MIT | [class-validator](git+https://github.com/typestack/class-validator.git) | 177 | | jwt-sd | 0.1.2 | (MIT OR Apache-2.0) | [jwt-sd](git+https://github.com/berendsliedrecht/sd-jwt-ts.git) | 178 | 179 | ### @aries-framework/tenants 180 | 181 | |
Dependency
|
Version
|
License
|
Link
| 182 | | ---------- | ------- | ------- | ---- | 183 | | @aries-framework/core | 0.4.2 | Apache-2.0 | [@aries-framework/core](git+https://github.com/hyperledger/aries-framework-javascript.git) | 184 | | async-mutex | 0.4.0 | MIT | [async-mutex](git+https://github.com/DirtyHairy/async-mutex.git) | 185 | 186 | ## Aries Framework JavaScript Extensions 187 | 188 | ### @aries-framework/push-notifications 189 | 190 | |
Dependency
|
Version
|
License
|
Link
| 191 | | ---------- | ------- | ------- | ---- | 192 | | class-transformer | 0.5.1 | MIT | [class-transformer](git+https://github.com/typestack/class-transformer.git) | 193 | | class-validator | 0.14.0 | MIT | [class-validator](git+https://github.com/typestack/class-validator.git) | 194 | | reflect-metadata | 0.1.13 | Apache-2.0 | [reflect-metadata](git+https://github.com/rbuckton/reflect-metadata.git) | 195 | | tsyringe | 4.7.0 | MIT | [tsyringe](git+https://github.com/Microsoft/tsyringe.git) | 196 | 197 | ### @aries-framework/react-hooks 198 | 199 | |
Dependency
|
Version
|
License
|
Link
| 200 | | ---------- | ------- | ------- | ---- | 201 | | rxjs | 7.5.6 | Apache-2.0 | [rxjs](git+https://github.com/reactivex/rxjs.git) | 202 | 203 | ### @aries-framework/redux-store 204 | 205 | |
Dependency
|
Version
|
License
|
Link
| 206 | | ---------- | ------- | ------- | ---- | 207 | | @reduxjs/toolkit | 1.8.3 | MIT | [@reduxjs/toolkit](git+https://github.com/reduxjs/redux-toolkit.git) | 208 | | react-redux | 7.2.8 | MIT | [react-redux](git+https://github.com/reduxjs/react-redux.git) | 209 | 210 | ### @aries-framework/rest 211 | 212 | |
Dependency
|
Version
|
License
|
Link
| 213 | | ---------- | ------- | ------- | ---- | 214 | | @aries-framework/core | 0.2.3 | Apache-2.0 | [@aries-framework/core](git+https://github.com/hyperledger/aries-framework-javascript.git) | 215 | | @aries-framework/node | 0.2.3 | Apache-2.0 | [@aries-framework/node](git+https://github.com/hyperledger/aries-framework-javascript.git) | 216 | | @types/ws | 7.4.7 | MIT | [@types/ws](https://github.com/DefinitelyTyped/DefinitelyTyped.git) | 217 | | body-parser | 1.20.0 | MIT | [body-parser](git+https://github.com/expressjs/body-parser.git) | 218 | | cors | 2.8.5 | MIT | [cors](git+https://github.com/expressjs/cors.git) | 219 | | express | 4.18.1 | MIT | [express](git+https://github.com/expressjs/express.git) | 220 | | node-fetch | 2.6.7 | MIT | [node-fetch](git+https://github.com/bitinn/node-fetch.git) | 221 | | reflect-metadata | 0.1.13 | Apache-2.0 | [reflect-metadata](git+https://github.com/rbuckton/reflect-metadata.git) | 222 | | swagger-ui-express | 4.4.0 | MIT | [swagger-ui-express](git+ssh://git@github.com/scottie1984/swagger-ui-express.git) | 223 | | tslog | 3.3.3 | MIT | [tslog](git+https://github.com/fullstack-build/tslog.git) | 224 | | tsoa | 4.1.2 | MIT | [tsoa](git+https://github.com/lukeautry/tsoa.git) | 225 | | tsyringe | 4.7.0 | MIT | [tsyringe](git+https://github.com/Microsoft/tsyringe.git) | 226 | | ws | 7.5.8 | MIT | [ws](git+https://github.com/websockets/ws.git) | 227 | | yargs | 17.5.1 | MIT | [yargs](git+https://github.com/yargs/yargs.git) | 228 | -------------------------------------------------------------------------------- /projects/android-identity-library.md: -------------------------------------------------------------------------------- 1 | # Project Name 2 | Android Identity Library. 3 | 4 | # Project Description 5 | Libraries and reference applications for working with real-world identity. 6 | 7 | The initial focus for this work was mdoc/mDL according to [ISO/IEC 18013-5:2021](https://www.iso.org/standard/69084.html) 8 | and related standards (mainly ISO 23220 series and ISO 18013-7) on Android. Current focus 9 | includes other credential formats and operating environments. 10 | 11 | ## Libraries 12 | 13 | The project includes two libraries written in Java and Kotlin. The 14 | first is `identity` which provides the core building blocks and which 15 | can also be used on server-side environments. The other is `identity-android` 16 | which provides Android-specific extensions to the former. It is designed to 17 | run on Android (API 24 or later) and will take advantage of Android-specific 18 | features including hardware-backed Keystore, NFC, Bluetooth 19 | Low Energy, and so on. 20 | 21 | The libraries are intended to be used by Wallet Applications (mobile 22 | applications on the credential holder's device), Reader Applications (applications 23 | operated on device controlled by the verifier), and Issuance Systems (applications 24 | operated by the credential issuer or their agent). They provide the following 25 | building blocks 26 | 27 | - A light-weight _Secure Area_ abstraction for hardware-backed keystore 28 | - Applications can create hardware-backed Elliptic Curve Cryptography 29 | keys which can be used for creating Signatures or performing Key Agreement. 30 | Each key will have an attestation which can be used to prove to Relying Parties 31 | (such as a credential issuer) that the private part of the key only exists 32 | in a Secure Area. 33 | - The `identity-android` library includes an implementation based on 34 | [Android Keystore](https://developer.android.com/training/articles/keystore) 35 | with support for requiring user authentication (biometric or lock-screen knowledge 36 | factor, e.g. system PIN) for unlocking the key and also can use 37 | [StrongBox](https://source.android.com/docs/compatibility/13/android-13-cdd#9112_strongbox) 38 | if available on the device. This is appropriate to use in Android applications 39 | implementing ISO/IEC 18013-5:2021 for storing `DeviceKey`. 40 | - The `identity` library includes an implementation backed by BouncyCastle 41 | with support for passphrase-protected keys. This isn't suitable for use 42 | in Mobile Applications as its not backed by Secure Hardware. 43 | - Applications can supply their own _Secure Area_ implementations for e.g. 44 | externally attached dongles, cloud based HSMs, or whatever the issuer 45 | deems appropriate to protect key material associated with their credential. 46 | - A _Credential Store_ for storage of one or more _Credentials_ 47 | - Each Credential has a _Credential Key_ which can be used by the issuer 48 | to bind a credential to a specific device which is useful when 49 | issuing updates or refreshing a credential. 50 | - Additionally, each Credential has one or more _Authentication Keys_ which 51 | can be endorsed by the issuer and used at presentation time. 52 | - Finally, namespaced data and arbitrary key/value pairs can be stored 53 | in a _Credential_ which can be used for credential data and claims. This 54 | data is stored encrypted at rest. 55 | - Data structures and code for provisioning of mdoc/mDLs 56 | - This code can can be used both on the device and issuer side. No networking 57 | protocol is defined, the application has to define its own. 58 | - Parsers and generators for all data structures used in ISO/IEC 18013-5:2021 59 | presentations, including `DeviceResponse`, `DeviceRequest`, `MobileSecurityObject` 60 | and many other CBOR data structures. 61 | - An implementation of the ISO/IEC 18013-5:2021 presentation flows including 62 | QR engagement, NFC engagement (both static and negotiated), device retrieval 63 | (BLE, Wifi Aware, and NFC) 64 | 65 | ## Wallet and Reader Android applications 66 | 67 | This repository also contains two Android applications using this library 68 | in the `appholder` and `appverifier` modules. The Wallet application is a simple 69 | self-contained application which allows creating a number of mdoc credentials 70 | using four different mdoc Document Types: 71 | 72 | - `org.iso.18013.5.1.mDL`: Mobile Driving License 73 | - `org.micov.1`: mdoc for eHealth ([link](https://github.com/18013-5/micov)) 74 | - `nl.rdw.mekb.1`: mdoc for Vehicle Registration ([link](https://github.com/18013-5/mVR)) 75 | - `eu.europa.ec.eudiw.pid.1`: mdoc for Personal Identification 76 | 77 | and their associated mdoc name spaces. The first one is defined in 78 | ISO/IEC 18013-5:2021 and the other three have been used at mdoc/mDL 79 | test events organized by participants of the ISO/IEC JTC1 SC17 WG10 80 | working group. 81 | 82 | ## ISO 18013-7 Reader Website 83 | 84 | The `wwwverifier` module contains the source code for a website acting as an 85 | mdoc reader according to the latest ISO 18013-7 working draft (as of Sep 2023) 86 | and it's implementing the so-called REST API. There is currently a test instance 87 | of this application available at https://mdoc-reader-external.uc.r.appspot.com/. 88 | The Wallet Android application also has support for the REST API and registers 89 | on Android for the `mdoc://` URI scheme. This can be tested end-to-end by going 90 | to the reader website (URL above) and clicking on one of the "Request" buttons, 91 | and then hitting the `mdoc://` link presented on the site. This will cause the 92 | browser to invoke the Wallet app which will then connect to the reader and send 93 | the credential after user consent. 94 | 95 | # Alignment with the OpenWallet Foundation Mission 96 | 97 | The project is already open-source and operating as such. It implements an important 98 | standard for digital wallets on a widely used mobile platform and is already 99 | in use in production applications, including Google Wallet. 100 | 101 | # Current Code of Conduct 102 | 103 | The project is currently using the [Google Code of Conduct](https://github.com/google/identity-credential/blob/master/docs/code-of-conduct.md). 104 | 105 | # TAC Sponsor 106 | -- 107 | 108 | # Project License 109 | Apache 2.0 110 | 111 | # Source Control 112 | https://github.com/google/identity-credential 113 | 114 | # Issue Tracker 115 | https://github.com/google/identity-credential/issues 116 | 117 | # External Dependencies 118 | -- 119 | 120 | # Release Methodology 121 | Releases are made on Google Maven. 122 | 123 | # Initial Maintainers 124 | David Zeuthen. 125 | 126 | # Proposed Project Governance 127 | -- 128 | 129 | # Links to Documented Governance Practices 130 | -- 131 | 132 | # Preferred Maturity Level 133 | -- 134 | 135 | # Communication Channels 136 | -- 137 | 138 | # Project Website 139 | -- 140 | 141 | # Social Media 142 | -- 143 | 144 | # Financial Sponsorship 145 | -- 146 | 147 | # Infrastructure 148 | -- 149 | -------------------------------------------------------------------------------- /projects/askar.md: -------------------------------------------------------------------------------- 1 | # Askar 2 | 3 | ## Project Name: Askar 4 | 5 | We plan to keep the name Askar, dropping the “Aries” prefix. The project is well known in the global identity community. 6 | 7 | ## Preferred Maturity Level 8 | 9 | The project should a “Growth” project, given its maturity, robustness, the number of projects (all Aries frameworks, Credo-TS, and others outside of Aries) in which it is embedded, and the myriad of production deployments of those projects. The project is lacking sufficient documentation / documentation website and has little business and marketing contributors. It is a project for developers, by developers. 10 | 11 | The following sub-sections cover how Askar meets OpenWallet Foundation maturity level criteria for Growth projects. 12 | 13 | ### Impact 14 | 15 | * Have a defined governing body of at least 5 or more members (owners and core maintainers), of which no more than one-third is affiliated with the same employer. In the case there are 5 governing members, 2 may be from the same employer. 16 | * [Government of British Columbia](https://digital.gov.bc.ca/digital-trust/home/) 17 | * [Indicio, PBC](https://indicio.tech/) 18 | * [SICPA](https://www.sicpa.com/) 19 | * Have a documented and publicly accessible description of the project's governance, decision-making, and release processes. 20 | * Start from the[ Aries Project Charter](https://docs.google.com/document/d/1F6RbR7xDaBt5CDJhqLJzR4c1pDJtyPGshp9fy6eVtSM/edit?usp=drive_link) and Aries[ TSC.md](https://github.com/hyperledger/aries/blob/main/TSC.md) and[ MAINTAINERS.md](https://github.com/hyperledger/aries/blob/main/MAINTAINERS.md) and evolve them to be Askar specific in the OWF context. 21 | * Have a healthy number of maintainers from at least two organizations. A maintainer is defined as someone with the commit bit; i.e., someone who can accept contributions to some or all of the project. 22 | * 19 [Contributors](https://github.com/hyperledger/aries-askar/graphs/contributors) Total 23 | * Maintainers from 3 Organizations — BC Gov, Indicio, [Animo Solutions](https://animo.id/) 24 | * Have a Code of Conduct in a form acceptable to the OpenWallet Foundation. 25 | * Evolve from the Hyperledger Code of Conduct 26 | * Explicitly define a project governance and maintainer process. This is preferably laid out in a GOVERNANCE.md file and references a CONTRIBUTING.md and MAINTAINERS.md file showing the current and emeritus maintainers (see MAINTAINERS.md File Contents for more information). 27 | * Evolve from the Aries Governance documentation. 28 | * Document that it is being used successfully in production by at least two independent end users which, in the TAC’s judgment, are of adequate quality and scope. 29 | * [Government of British Columbia](https://digital.gov.bc.ca/digital-trust/home/) 30 | * [Indicio, PBC](https://indicio.tech/) 31 | * Anyone using[ Credo-TS](https://credo.js.org/),[ Bifold Wallet](https://github.com/openwallet-foundation/bifold-wallet) and[ ACA-Py](https://aca-py.org/) in production 32 | * Have a public list of project adopters for at least the primary repo (e.g., ADOPTERS.md or logos on the project website). 33 | * To be added to the repository. 34 | * Have a good standing with respect to security. 35 | * Other metrics as defined by the applying Project during the application process in cooperation with the TAC. 36 | * Receive a supermajority vote from the TAC to move to Impact stage. Projects can move directly from Labs to Impact, if they can demonstrate sufficient maturity and have met all requirements. 37 | 38 | ## Project Description 39 | 40 | Askar is an open-source, secure storage and key management service implemented in Rust (with wrappers for Python and JavaScript/TypeScript), designed to support the needs of decentralized trust systems within and beyond the Aries ecosystem. It is a critical component that securely manages cryptographic keys, credentials, and other sensitive data used in decentralized identity frameworks. Askar is the secure storage/key management solution for Credo-TS, ACA-Py, Identus, Aries VCX, and other decentralized trust projects. 41 | 42 | Askar implements a lightweight, efficient, and secure way to store and manage decentralized trust data such as keys, credentials, and DIDs (Decentralized Identifiers). It is designed to work seamlessly with Aries and other decentralized identity agents, ensuring that the data these agents require is stored securely and can be accessed and used as needed. The project focuses on offering robust cryptographic support, including encryption, signing, and key management, all essential for secure decentralized identity operations. Contributors have extended Askar to work with HSM-based keys. 43 | 44 | Askar supports various backend storage options from SQLite to Postgres, making it adaptable to different environments and use cases from mobile and IoT to large scale Enterprise deployments. It is designed to be embedded in a wide variety of decentralized trust implementations and includes wrappers for Python and JavaScript/TypeScript (for NodeJS and React Native implementations). 45 | 46 | The project is developed and maintained by a community of sophisticated developers that are building Askar into their own digital trust projects and deployments. It contributes to the broader goal of creating secure, scalable, open-source infrastructure for decentralized identity management. 47 | 48 | ## Alignment with the OpenWallet Foundation Mission 49 | 50 | Askar supports the OWF’s goals by providing a secure, scalable technological foundation necessary for storage and key management. Notably, Askar’s goals in common with the OpenWallet Foundation are: 51 | 52 | 1. Secure Data Management: Askar is designed to provide secure storage for cryptographic keys, credentials, DIDs, and other sensitive data. It emphasizes strong encryption, key management, and secure storage practices, which are critical for ensuring the integrity and confidentiality of digital identity data. 53 | 2. Interoperability: Askar is built to be interoperable with various components of the Aries ecosystem and other decentralized identity systems. It supports different backend storage options and is adaptable to a variety of environments from mobile to enterprise, ensuring that it can be used in conjunction with a wide range of digital identity and wallet solutions. 54 | 3. Open Source Development: Askar is an open-source project, inviting collaboration and contributions from developers around the world. This approach ensures that the project benefits from diverse input and continuous improvement, fostering innovation and transparency in the development of secure storage solutions. 55 | 4. Support for Decentralized Identity: As a secure storage solution tailored to decentralized identity systems, Askar plays a critical role in enabling decentralized, user-controlled identity management. It ensures that the cryptographic materials required for decentralized identities are stored securely and can be accessed reliably by agents and wallets. 56 | 57 | ## Code of Conduct 58 | 59 | Askar follows the [Hyperledger Code of Conduct](https://github.com/hyperledger/aries-askar/blob/main/CODE_OF_CONDUCT.md), which is what the OWF code of conduct is based on. 60 | 61 | ## TAC Sponsor 62 | 63 | * Tracy Kuhrt 64 | * Wenjing Chu 65 | 66 | ## Project License 67 | 68 | The project has an Apache 2.0 and MIT License: [Askar - Apache License](https://github.com/hyperledger/aries-askar/blob/main/APACHE_LICENSE) and [Askar - MIT License](https://github.com/hyperledger/aries-askar/blob/main/MIT_LICENSE) 69 | 70 | ## Source Control 71 | 72 | The project is hosted in GitHub and includes the following repositories: 73 | 74 | * [Askar](https://github.com/hyperledger/aries-askar) — code and documentation for Askar 75 | 76 | ## Issue Tracker 77 | 78 | The issues are tracked using GitHub's Issues feature in the corresponding repository. 79 | 80 | ## External Dependencies 81 | 82 | The ACA-Py dependency list is maintained in the [source repository](https://github.com/hyperledger/aries-askar/blob/main/Cargo.toml). All are open source and we believe (but to be verified) that the majority use the Apache 2 License. 83 | 84 | ## Release Methodology 85 | 86 | All proposed repositories have continuous deployment/delivery pipelines built using [GitHub Actions](https://github.com/features/actions). The individual packages follow the [semantic versioning](https://semver.org/) method, ensuring consistency and safety. Whenever a pull request is merged into the main branch that doesn't cause a major, minor or patch version increase, an alpha version is released. 87 | 88 | ## Initial Maintainers 89 | 90 | | Name | Github | Organization | 91 | | ----------------- | ---------------- | ---------------------------------------- | 92 | | Andrew Whitehead | andrewwhitehead | Funded by Government of British Columbia | 93 | | Wade Barnes | WadeBarnes | Funded by Government of British Columbia | 94 | | Berend Sliedrecht | berendsliedrecht | Animo Solutions | 95 | | Timo Glastra | TimoGlastra | Animo Solutions | 96 | 97 | ## Proposed Project Governance 98 | 99 | The current governance model under Hyperledger is consensus-based. This means that decisions are made through discussions, with the aim of community consensus, as outlined in the [Aries Project Charter](https://docs.google.com/document/d/1F6RbR7xDaBt5CDJhqLJzR4c1pDJtyPGshp9fy6eVtSM/edit?usp=sharing). In cases where no clear consensus is established, a project Technical Steering Committee, or the maintainers (those with escalated GitHub privileges) are granted a louder voice. This approach has proven effective. 100 | 101 | ## Links to Documented Governance Practices 102 | 103 | Hyperledger [Project Charter for Aries](https://docs.google.com/presentation/d/18vMC85R_UqSirTatMQnj7iCFEUX0QP7EZE7lD1FgEa0/edit?usp=sharing). 104 | 105 | ## Financial Sponsorship 106 | 107 | Hyperledger has covered infrastructure related costs. Besides that, None. 108 | 109 | ## Infrastructure 110 | 111 | * GitHub repositories 112 | * CI (GitHub actions) 113 | * Bug Tracking (GitHub Issues and GitHub Projects) 114 | * Communication channels (Discord) 115 | * Mailing list 116 | * Video conference (Zoom) 117 | * Published Artifacts — Cargo, PyPi, NPM 118 | -------------------------------------------------------------------------------- /projects/bifold-wallet/README.md: -------------------------------------------------------------------------------- 1 | # Project Name 2 | 3 | Right now, we often refer to our project as "Aries Bifold," but its official name on GitHub is [Aries Mobile Agent React Native](https://github.com/hyperledger/aries-mobile-agent-react-native). If the OpenWallet Foundation (OWF) accepts our project, we're likely change its official name to either "Aries Bifold" or possibly substitute the "Aries" part altogether. This would help us differentiate our project from the "Aries Hyperledger" initiative. We plan to start discussing this name change as soon as we are part of the OWF. 4 | 5 | # Project Description 6 | 7 | Aries Bifold is an open-source project designed to enhance the way we interact with digital identities, making the process both secure and user-friendly. It is based on React Native, which lets it run smoothly on different devices and platforms, such as iOS, and Android. It is a leading example of digital wallets, with a focus on making verifiable credentials (VCs) simple and convenient for everyone. Our mission is to create a collaborative community that enhances the way digital credentials are handled, making them accessible and straightforward for all. 8 | 9 | **Key Features and Benefits:** 10 | 11 | - **Unified Digital Identity Management:** Emphasizing security and user-friendliness, Aries Bifold excels in consolidating and managing digital identities across various standards like AnonCreds and W3C VC Data Model. This capability positions Bifold as a pivotal resource for secure and private handling of digital identities, accessible to all. 12 | 13 | - **Seamless Multi-Platform Use:** Thanks to its React Native architecture, Bifold delivers a smooth experience on any device, enabling users to manage their digital identities whether they are using a phone or a tablet. This cross-platform flexibility means that developers can create applications once and deploy them on both iOS and Android, ensuring a consistent and accessible user experience. 14 | 15 | - **Community-Driven Development:** Aries Bifold is more than a tool; it's a community initiative aimed at fostering collaboration and sharing innovations. By bringing together diverse groups, from organizations to individuals, Bifold encourages the pooling of resources and knowledge to facilitate the broader adoption and understanding of verifiable credentials. 16 | 17 | - **Widespread Adoption and Trust:** With a growing list of users around the globe, including governmental bodies in Canada and teams in Brazil, Bifold has proven its reliability and relevance. Its international use showcases the platform's adaptability to various needs and its role in advancing digital identity management on a global scale. 18 | 19 | - **Adaptability to Diverse Needs:** Bifold's design caters to a wide range of project types and complexities, offering tailored solutions for managing digital identities. This adaptability ensures that users can streamline their processes related to verifiable credentials, improving efficiency and simplification in digital identity initiatives. 20 | 21 | # Alignment with the OpenWallet Foundation Mission 22 | 23 | Aries Bifold aligns seamlessly with the mission of the OpenWallet Foundation (OWF) as laid out by the Linux Foundation. By developing a secure, versatile, and user-friendly mobile client for managing digital identities, Aries Bifold embodies the OWF's goal of advancing interoperability and setting best practices in digital wallet technology. As an open-source initiative, Aries Bifold contributes to the collective effort of creating an open software product that empowers organizations and individuals to build interoperable, privacy-protecting wallets without reinventing the wheel. Our project's focus on simplifying interactions with verifiable credentials and fostering a collaborative community echoes the OWF's mission to develop a multi-purpose engine that serves as a starting point for anyone looking to innovate in the digital wallet space. By participating in this shared vision, Aries Bifold helps pave the way for a future where digital wallets are accessible, secure, and capable of supporting a wide range of use cases for identity verification1. 24 | 25 | > **1** Based on an understanding of [Join us in Building a Truly “Open” Wallet Foundation](https://openwallet.foundation/2023/08/23/join-us-in-building-a-truly-open-wallet-foundation/) and [Linux Foundation Announces an Intent to Form the OpenWallet Foundation](https://www.linuxfoundation.org/press/linux-foundation-announces-an-intent-to-form-the-openwallet-foundation). 26 | 27 | # TAC Sponsor(s) 28 | 29 | - Tracy Kuhrt 30 | - Wenjing Chu 31 | 32 | # Project License 33 | 34 | Our project is open and free to use under the [Apache 2.0 license](https://github.com/hyperledger/aries-mobile-agent-react-native/blob/main/LICENSE). This means you can use, modify, and distribute it, subject to the terms of this license. 35 | 36 | # Source Control 37 | 38 | We manage our code on GitHub, within the [Hyperledger organization](https://github.com/hyperledger). You can find our project here: 39 | 40 | - [Aries Mobile Agent React Native](https://github.com/hyperledger/aries-mobile-agent-react-native). 41 | 42 | # Issue Tracking 43 | 44 | We keep track of any project issues directly on GitHub using the Issues feature. If there are problems that affect multiple parts of the project, we might use GitHub's Projects feature to manage them. 45 | 46 | # External Dependencies 47 | 48 | Our project uses several smaller libraries, too many to list here. However, one key dependency we heavily rely on is [Credo-ts](https://github.com/openwallet-foundation/credo-ts/issues) from the OpenWallet Foundation, which was previously known as Aries Framework JavaScript. 49 | 50 | # Release Methodology 51 | 52 | Our release process is designed to ensure our software is secure, high-quality, and up-to-date: 53 | 54 | - **Automated Checks**: We employ automated tools to perform code quality and security scans, catching potential issues early. 55 | 56 | - **Peer Review**: All code changes are peer-reviewed, ensuring a second set of eyes evaluates every update for quality and reliability. 57 | 58 | - **CI/CD Pipelines**: Our automated pipelines handle integration, testing, and deployment, keeping our codebase deployable at all times. 59 | 60 | - **NPM Packages**: The outcome of our process is the regular release of updated NPM packages, providing users with the latest features and improvements efficiently. 61 | 62 | This streamlined approach allows us to maintain a high standard for our releases, ensuring our users always have access to the best version of our software. 63 | 64 | # Initial Maintainers 65 | 66 | Our initial [maintainers](https://github.com/hyperledger/aries-mobile-agent-react-native/blob/main/MAINTAINERS.md) are as follows: 67 | 68 | | Name | Github | 69 | | ---------------------- | ------------- | 70 | | Akiff Manji | amanji | 71 | | Bryce McMath | bryce-mcmath | 72 | | Clécio Varjão | cvarjao | 73 | | James Ebert | JamesKEbert | 74 | | Jean-Christophe Drouin | jcdrouin21 | 75 | | Jason C. Leach | jleach | 76 | | Mostafa Gamal | MosCD3 | 77 | | Ryan Koch | ryankoch13 | 78 | | Thiago Romano | thiagoromanos | 79 | | Wade King | wadeking98 | 80 | 81 | # Proposed Project Governance 82 | 83 | The current governance model under Hyperledger is community-based. This means that decisions are made democratically, with the aim of community consensus. In cases where no clear consensus is established, active contributors may be granted a louder voice. 84 | 85 | This approach has proven effective and will be continued as the chosen governance model. 86 | 87 | # Links to Documented Governance Practices 88 | 89 | Work in progress. The intake form has been submitted. 90 | 91 | # Preferred Maturity Level 92 | 93 | We are proposing to be a "growth" project as we have been been in active development for several years. We have deployed our product in British Columbia, Canada and other places where we have ongoing or completed proof-of-concept projects. We also have a Brazilian team that is working with us and contributing to our project. 94 | 95 | # Communication 96 | 97 | Discord channel in OWF. 98 | 99 | # Project Website 100 | 101 | GitHub project 102 | 103 | # Social Media 104 | 105 | None 106 | 107 | # Financial Sponsorship 108 | 109 | There are no financial obligations or sponsorship outside of what is covered by the Hyperledger Foundation for infrastructure related costs. 110 | 111 | # Infrastructure 112 | 113 | - GitHub repositories and Actions 114 | - Atlassian Confluence for community meetings via Wiki 115 | - npmjs.org for package publishing 116 | -------------------------------------------------------------------------------- /projects/build-wallet-core.md: -------------------------------------------------------------------------------- 1 | # Project Name 2 | Build Wallet Core 3 | 4 | # Preferred Maturity Level 5 | Labs - 6 | We're in production using this library on our wallet and looking for more active support from the Foundation or TAC mentorship to reach bigger goals. 7 | 8 | # Project Description 9 | ### What it Does: 10 | Begin.is is a cryptographic wallet that provides a secure and user-friendly platform for storing, managing, and transacting digital assets. It aims to simplify the complex processes associated with cryptocurrency management, offering a streamlined interface that caters to both novice and experienced users. The wallet supports a wide range of cryptocurrencies and integrates advanced security features to protect users’ assets. 11 | 1. Key Features: Multi-Currency Support: Supports various cryptocurrencies, allowing users to manage multiple assets within a single platform. 12 | 2. User-Friendly Interface: Designed to be intuitive, making it accessible for users with varying levels of experience in cryptocurrency. 13 | 3. High Security: Incorporates state-of-the-art security measures such as encryption, multi-signature support, and secure key management to safeguard user assets. 14 | 4. Interoperability: Compatible with various blockchain networks, enabling seamless transactions across different platforms. 15 | 5. Decentralized Identity: Integrates with decentralized identity solutions to enhance user privacy and control over personal information. Partner for is our main shareholder IAMX.id 16 | 17 | ### Why it is Valuable? 18 | Begin.is addresses the critical need for secure and efficient management of digital assets in the rapidly growing cryptocurrency market. Its value proposition includes: 19 | 1. Security: Provides robust security features to protect against hacking and unauthorized access. 20 | 2. Convenience: Simplifies cryptocurrency management, making it easier for users to store, send, and receive digital assets. 21 | 3. Accessibility: Designed to be user-friendly, lowering the barrier to entry for individuals new to cryptocurrencies. 22 | 4. Interoperability: Supports multiple cryptocurrencies and blockchain networks like Bitcoin and Ethereum, offering a versatile solution for managing diverse digital assets. 23 | 5. Privacy: Enhances user privacy through decentralized identity integrations, giving users more control over their personal data. 24 | 25 | 26 | ### Origin and History 27 | Begin.is was founded with the mission to create a more secure and accessible platform for cryptocurrency users. The team behind Begin.is recognized the challenges faced by users in managing digital assets securely and sought to develop a solution that addressed these issues. 28 | * Francis Luz (Founder & CEO): IT Security Banking Sector 29 | * Tim Brückmann (CMO): Founder IAMX AG and more 30 | 31 | ### Key Milestones: 32 | 1. Foundation: The project was initiated by a team of experts in cryptography and blockchain technology who identified the need for a more secure and user-friendly wallet solution. 33 | 2. Development: Extensive research and development were conducted to design a platform that integrates advanced security features while maintaining ease of use. 34 | 3. Launch: Begin.is was officially launched, offering a robust Cardano blockchain wallet solution that quickly gained traction among cryptocurrency enthusiasts. 35 | 4. Growth: The platform has seen steady growth, with continuous updates and feature enhancements to meet the evolving needs of its user base. Now Begin is more focussed to tackle “real-world-problems”. 36 | 37 | 38 | # Alignment with the OpenWallet Foundation Mission 39 | Begin.is wallet’s focus on security, interoperability, user control, scalability, and community collaboration aligns well with the OpenWallet Foundation’s mission. Both aim to create a secure, open, and user-friendly framework for managing digital assets and identities, fostering innovation and interoperability in the digital wallet space. 40 | 41 | # Code of Conduct 42 | No 43 | 44 | # TAC Sponsor 45 | No 46 | 47 | # Project License 48 | Apache 2.0 49 | 50 | # Source Control 51 | [GitHub](https://github.com/BeginWallet/begin-core) 52 | * We'll amend the commit history to include DCO sign-off for each of the commits before we transfer this repo. 53 | 54 | # Issue Tracker 55 | [GitHub](https://github.com/BeginWallet/begin-core) 56 | 57 | # External Dependencies 58 | - @dcspark/cardano-multiplatform-lib-(nodejs & browser) - (MIT) 59 | - @emurgo/cardano-message-signing-(nodejs & browser) - (MIT) 60 | - bip39 - (ISC) 61 | - @apollo/client - (MIT) 62 | - graphql - (MIT) 63 | 64 | 65 | # Release Methodology 66 | Feature branches and Pull request 67 | 68 | # Initial Maintainers 69 | * Francis Luz 70 | * Tim Brückmann 71 | 72 | 73 | # Proposed Project Governance 74 | The leadership team is Francis Luz and Tim Brückmann, and decisions are based on our Roadmap and Client needs. 75 | 76 | # Links to Documented Governance Practices 77 | _Include a link to the project charter. The project charter can be obtained by completing the [project intake form](https://docs.google.com/forms/d/e/1FAIpQLSeO1bDGHUP-ZpCo1uynm94YOxZlek6RhCH7o3FnX1lZSXXfSQ/viewform?fbzx=4351560609072672295)._ 78 | 79 | # Financial Sponsorship 80 | The team took part in Cardano Catalyst (decentralized fund) and wrote the first proposals. We will go on and write more proposals also together with partners from blockchain and “in-real-life” space 81 | 82 | # Infrastructure 83 | - GitHub 84 | - Page on the OpenWallet Foundation site 85 | - Creation of an official project name and logo 86 | - Coordinate promotion of major project milestones and releases 87 | -------------------------------------------------------------------------------- /projects/credhub.md: -------------------------------------------------------------------------------- 1 | # Project Name 2 | credhub 3 | 4 | # Preferred Maturity Level 5 | Labs 6 | 7 | # Project Description 8 | When talking about wallets for natural persons, a lot of people think that a smartphone based wallet is the only way to go. The user should feel the security and privacy by being independent from an external provider. But we are forgetting that online based services have a great user experience in daily life: 9 | - As a user I can use multiple clients where my data is synced, we do not have to care about backups or data recovery. 10 | - As a developer I can implement the business logic into the cloud and only need the rendering on the client side. 11 | 12 | Yes, when I am offline, I do not have access to my data anymore. But beside that the user experience is great! 13 | 14 | The credhub project is a typescript based monorepo, using [nx](https://nx.dev) to manage multiple components. Compared to other approaches, it also comes with an issuer and verifier service to issue and verify credentials. 15 | 16 | ## Clients 17 | There are two clients that can be used to interact with a cloud wallet 18 | - a PWA based on Angular 19 | - a Chrome Browser Extension based on Angular 20 | 21 | While the PWA is using the camera to scan QR codes, the browser extension is scanning the opened taps for QR codes and is able to show a little button next to the QR code to interact with the wallet. This approach was inspired by password managers like 1Password. In the daily use, People do not want to take out their smartphone to scan a QR code, they want an easy one click solution. 22 | 23 | By implementing the whole business logic in the cloud, the client is only responsible for the rendering. Therefore building new clients in other programming languages is easy by using the OpenAPI endpoints. For authentication the OpenID Connect protocol is used, the project is using the [Keycloak](https://www.keycloak.org/) server for that. 24 | 25 | ## Issuer and Verifier 26 | 27 | Both relying parties are implemented as separate services, each of them comes with a web client for demo purposes. Further integration like webhooks or other services can be implemented in the future. The authentication is done by using the OpenID Connect protocol. 28 | 29 | ## Modular approach 30 | The usage of NX allows reusable components with a modular approach. Each backend implementation supports low security key management by storing the keys in the filesystem or the database, or the integration with Hashicorp Vault for high security key management. Other implementations are possible. 31 | 32 | ## Identity Stack 33 | By validating existing SSI frameworks like Credo or Veramo, this project should primary focus on the architecture reference framework of the EU. Therefore other credential formats, transport protocols or key managements like multiple DIDs methods are not supported. 34 | 35 | **Credential Profile:** 36 | - Credential Format: SD-JWT-VC 37 | - Key Management (issuer): VC-ISSUER Meta data, DID, X509 38 | - Key Management (holder): CNF (json web key) 39 | - Transport Protocol: OID4VC 40 | - Signature Algorithm: P-256 41 | - Status Management: OAUTH Status List 42 | 43 | # Alignment with the OpenWallet Foundation Mission 44 | One of the primary demands is the architecture reference framework of the EU. By following the standards, it is possible to implement the different components on different platforms, but still be able to test them in a functional environment. 45 | 46 | It can also be used as a playground to test out new approaches: how can processes be automated for the best UX without a security tradeoff? Implementing alterative approaches like another signature algorithm and compare them with the current implementation. 47 | 48 | # Code of Conduct 49 | [OpenWallet Foundation code of conduct](https://tac.openwallet.foundation/governance/code-of-conduct/) 50 | 51 | # TAC Sponsor 52 | None 53 | 54 | # Project License 55 | Apache 2.0 for all projects inside the Monorepo. 56 | 57 | # Source Control 58 | [Github Repo](https://github.com/cre8/wallet) 59 | 60 | # Issue Tracker 61 | [Github Issues](https://github.com/cre8/wallet/issues) 62 | 63 | # External Dependencies 64 | None 65 | 66 | # Release Methodology 67 | Docker images will be released to the Github Registry. For versioning semantic versioning with synced version numbers should be used in the future. 68 | 69 | # Initial Maintainers 70 | Mirko Mollik [cre8](https://github.com/cre8) 71 | 72 | # Proposed Project Governance 73 | Everyone should be able to contribute to the project. As primary goal is to follow the architecture reference framework of the EU. Contributors will be able to open issues via Github or pitch their ideas in monthly calls. 74 | 75 | # Links to Documented Governance Practices 76 | 77 | 78 | # Financial Sponsorship 79 | None 80 | 81 | # Infrastructure 82 | None right now, since the hosting of a demo instance would require to define a data policy. In case the legal part in covered, a minimal setup can be realized with with small VMs and a domain. 83 | -------------------------------------------------------------------------------- /projects/dcql-ts.md: -------------------------------------------------------------------------------- 1 | # Project Name 2 | 3 | DCQL TypeScript 4 | 5 | # Preferred Maturity Level 6 | 7 | Labs 8 | 9 | # Project Description 10 | 11 | The [Digital Credentials Query Language](https://openid.net/specs/openid-4-verifiable-presentations-1_0-23.html#name-digital-credentials-query-l) (DCQL, pronounced [ˈdakl̩]) is a JSON-encoded query language that allows a verifier to request verifiable presentations that match a query. 12 | 13 | DCQL TypeScript is a generic, and low-level implementation of the query language. By providing it as a separate library from OpenID4VC we hope to see adoption of the library outside of the OpenID4VC set of standards (Credo is intending to adopt it for DIDComm protocols as replacement for DIF Presentation Exchange as well). 14 | 15 | The library was created by Animo as part of the SPRIN-D Funke wallet competition, to experiment with the new query language added to the OpenID4VP specification. 16 | 17 | # Alignment with the OpenWallet Foundation Mission 18 | 19 | The DCQL library provides a reusable library that is crucial to wallet interoperability. It is already being adopted by Credo, as well as being integrated in [Sphereon OID4VC](https://github.com/Sphereon-Opensource/OID4VC/pull/171), which is used a lot for TypeScript/JavaScript projects integrating verifiable credentials. 20 | 21 | # Code of Conduct 22 | 23 | Will adopt OWF code of conduct. 24 | 25 | # TAC Sponsor 26 | 27 | - Stephen Curran 28 | 29 | # Project License 30 | 31 | Apache 2.0 32 | 33 | # Source Control 34 | 35 | Project already exists on Github: https://github.com/auer-martin/dcql. Slug should become dcql-ts once transferred. 36 | 37 | # Issue Tracker 38 | 39 | https://github.com/auer-martin/dcql/issues?q=sort%3Aupdated-desc+is%3Aissue+is%3Aopen 40 | 41 | There are some issues related to aligning the project better with other projects we maintain at OWF and adding the needed license. 42 | 43 | # External Dependencies 44 | 45 | - [Valibot](https://github.com/fabian-hiller/valibot) - MIT 46 | 47 | # Release Methodology 48 | 49 | Package is relased on NPM, OWF will be added as owner on NPM: http://npmjs.com/package/dcql 50 | 51 | We use changesets to write changelog entries, and a bot will create a pull request for new releases. Once the PR is merged a new release will be created automatically. We have used this method extensively and it automates 99% of the process, and works well with keeping restrictions of bots pushing to main (you can use the normal PR approval and merge process to trigger releases). Example: https://github.com/auer-martin/dcql/pull/21 52 | 53 | # Initial Maintainers 54 | 55 | - Martin Auer - [@auer-martin](https://github.com/auer-martin) - Creator of the library, maintainer of Credo, contractor for Animo 56 | - Timo Glastra - [@TimoGlastra](https://github.com/TimoGlastra) - maintainer of Credo (that leverages this project) 57 | 58 | # Proposed Project Governance 59 | 60 | The projects will mostly be managed by the existing Credo maintainers. Large decisions will be initially discussed as part of the Credo working group calls, but we would still like a dedicated discord channel. Later if desired by the community, the project can be more separated from the Credo project. 61 | 62 | The design of the project is mostly led by Martin Auer, who created this library for Animo as part of the SPRIN-D Funke wallet competition. Timo Glastra will mostly assist with the general maintenance and releases of the library. Although Martin and Timo are both associated with Animo, Martin should be seen as indepdant mainainer of this library, not associated with Animo. 63 | 64 | # Financial Sponsorship 65 | 66 | The development of this library was funded by Animo, which in turn received funding through the SPRIN-D Funke wallet competition. 67 | 68 | # Infrastructure 69 | 70 | - Github repo 71 | - Discord channel 72 | - Github actions 73 | - NPM 74 | -------------------------------------------------------------------------------- /projects/didcomm-mediator.md: -------------------------------------------------------------------------------- 1 | # DIDComm Mediator Service 2 | 3 | ## Project Name: DIDComm Mediator Service 4 | 5 | The DIDComm Mediator Service supports mobile DIDComm agents as a reliable intermediary providing an addressable HTTP endpoint for secure message routing. This enables mobile agents with intermittent connectivity to receive messages from enterprise or other agents through a trusted, decentralized communication channel. In leveraging DIDComm, the service ensures end-to-end encrypted, verifiable message delivery, allowing enterprises to send notifications and initiate interactions with mobile users in a secure and trusted manner. 6 | 7 | The DIDComm Mediator Service offers a secure alternative to traditional, untrusted notification/communication methods like email, SMS, and mail. It is particularly beneficial for mobile users who need a persistent communication link without sacrificing privacy and security, playing an important role in maintaining seamless communication in decentralized identity ecosystems. 8 | 9 | ## Preferred Maturity Level 10 | 11 | We propose that the project go into OWF as a “Growth” project. The implementation has been deployed by many parties in both production and proof of concept scenarios and has proven to be reliable and scalable. It is easily deployed and “just works”. The included “SocketDoc” repository can provide expanded horizontal scalability not currently part of the current deployment. We think a fully scalable implementation of a DIDComm mediator could be an “Impact” project. 12 | 13 | The following sub-section covers how DIDComm Mediator Service meets the criteria for OpenWallet Foundation Growth projects: 14 | 15 | ### Growth 16 | 17 | * 2 TAC sponsors to champion the project and provide mentorship as needed. 18 | * Development of a growth plan, to be done in conjunction with their project mentor(s) at the TAC. 19 | * Development of a project roadmap that provides differentiated features and capabilities and the timeframe for completion. 20 | * DIDComm Mediator Service is complete and can be (and is) deployed in production use cases. 21 | * Roadmap: 22 | * Continued evolution as the underlying frameworks ([ACA-Py](https://aca-py.org), [Credo-TS](https://credo.js.org/)) evolve. 23 | * Integration of [SocketDock](https://github.com/hyperledger/aries-socketdock?search=1) into the main repository to enable scaled deployments supporting WebSocket-connected mobile agents. 24 | * Extending support to include [DIDComm v2](https://identity.foundation/didcomm-messaging/spec/) and [Trust Spanning Protocol](https://trustoverip.github.io/tswg-tsp-specification/). 25 | * 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. 26 | * [Government of British Columbia](https://digital.gov.bc.ca/digital-trust/home/) 27 | * [Indicio, PBC](https://indicio.tech/) 28 | * Likely used in [Bifold Wallet](https://github.com/openwallet-foundation/bifold-wallet) deployments 29 | * Demonstrate a substantial ongoing flow of commits and merged contributions. 30 | * DIDComm Mediator Service is built on [ACA-Py](https://aca-py.org), so all contributions to ACA-Py flow to it. 31 | * 18 [Contributors](https://github.com/hyperledger/aries-mediator-service/graphs/contributors) 32 | * Demonstrate that the current level of community participation is sufficient to meet the goals outlined in the growth plan and roadmap. 33 | * As the need arises for features, community members add them. 34 | * Since these metrics can vary significantly depending on the type, scope and size of a project, the TAC has final judgment over the level of activity that is adequate to meet these criteria. 35 | * Demonstrates how this project differs from existing projects in the Growth and Impact stages. 36 | * The only OWF project that might overlap with the DIDComm Mediator Service is the TSP project’s example “[intermediary service](https://github.com/openwallet-foundation-labs/tsp/blob/main/docs/intermediary.md)”. As DIDComm and TSP are conceptually similar, it is expected that over time, support for the Trust Spanning Protocol (TSP) will be added to DIDComm Mediator Service. 37 | 38 | ## Project Description 39 | 40 | The DIDComm Mediator Service is an open-source project designed to facilitate DIDComm communication between Aries agents, particularly in situations where agents are on mobile devices, behind firewalls, or have intermittent connectivity. A DIDComm mediator serves as a persistent endpoint for client agents, allowing them to receive messages securely and efficiently, even when direct peer-to-peer communication is not possible. This allows a peer contact, such as an enterprise issuer or verifier, to initiate a messaging exchange with a mobile agent. This is a substantial improvement of the situation today, when enterprises are limited to initiating interactions or sending notifications via untrusted emails and SMSs that are often discarded as phishing attacks. 41 | 42 | ### Key Features 43 | 44 | * **DIDComm Message Relaying**: The primary function of the DIDComm Mediator is to relay inbound DIDComm messages to client agents. It enables agents that cannot maintain an addressable endpoint to receive messages through a trusted third-party mediator, ensuring that communication remains uninterrupted. The mediator has no visibility to the embedded message being relayed. 45 | * **Routing and Delivery**: The service offers routing capabilities, directing DIDComm messages to the correct recipient even if the recipient’s agent is temporarily offline. It queues messages and delivers them when the recipient becomes available, enhancing reliability in environments with unstable connections. 46 | * **Extensibility and Customization**: DIDComm Mediator is designed to be flexible and customizable, allowing developers to extend its functionality according to specific use cases. It embeds the deployers' choice of ACA-Py or Credo-TS to handle the DIDComm messaging. That underlying power makes DIDComm Mediator Service adaptable to a wide range of deployment scenarios, from simple message relaying to more complex mediation tasks. 47 | * **Community-Driven Development**: DIDComm Mediator Service is developed and maintained by a global community of contributors. This collaborative approach ensures that the service evolves in line with the needs of the broader decentralized identity ecosystem. 48 | 49 | The service is particularly useful for agents operating on mobile devices or in environments where maintaining a constant connection is challenging. It ensures that unsolicited messages and notifications can be sent from a known peer via an established connection. 50 | 51 | ## Alignment with the OpenWallet Foundation Mission 52 | 53 | The DIDComm Mediator aligns with the mission of the Open Wallet Foundation (OWF) in several critical ways, particularly in terms of enhancing interoperability, ensuring reliable communication, and promoting open-source solutions for digital wallets and decentralized identity systems. 54 | 55 | 1. **Interoperability and Seamless Communication**: The service is designed to facilitate DIDComm communication between DIDComm agents, especially when direct peer-to-peer connections are not possible due to network constraints like firewalls or intermittent connectivity. By ensuring that messages can be reliably routed and delivered through a mediator, the service enables seamless communication between different agents and systems. 56 | 2. **Support for Decentralized Identity**: The service plays a role in decentralized identity systems by ensuring that agents without persistent endpoints can securely receive DIDComm messages. This helps maintain the integrity and confidentiality of identity-related messages, even when direct communication channels are not available. 57 | 3. **Reliability in Diverse Environments**: By acting as an intermediary that queues and relays messages, the service ensures that inbound DIDComm messages to agents are reliable, even in environments with intermittent connectivity or where agents are behind firewalls. This is particularly important for mobile devices, edge computing, and other scenarios where maintaining a continuous connection is challenging. 58 | 4. **Open-Source Collaboration and Innovation**: As an open-source project, DIDComm Mediator is developed and maintained by a global community. 59 | 5. **Security and Privacy**: The service supports secure DIDComm messaging, ensuring that communication between agents is encrypted and privacy-preserving. A DIDComm mediator cannot decrypt the contents of the message sent to a client agent. This is critical in protecting user data and maintaining the security of decentralized identity systems. 60 | 61 | ## Code of Conduct 62 | 63 | DIDComm Mediator Service follows the [Hyperledger Code of Conduct](https://github.com/hyperledger/aries-agent-test-harness/blob/main/CODE_OF_CONDUCT.md), which is what the OWF code of conduct is based on. 64 | 65 | ## TAC Sponsor 66 | 67 | * Tracy Kuhrt 68 | * Wenjing Chu 69 | 70 | ## Project License 71 | 72 | The project has an Apache 2.0 license: [Aries Mediator Service - License](https://github.com/hyperledger/aries-mediator-service/blob/main/LICENSE) 73 | 74 | ## Source Control 75 | 76 | The project is hosted in GitHub and includes the following repositories: 77 | 78 | * [Aries Mediator Service](https://github.com/hyperledger/aries-mediator-service) 79 | * [Aries SocketDock](https://github.com/hyperledger/aries-socketdock) 80 | 81 | ## Issue Tracker 82 | 83 | Issues are tracked using GitHub's Issues feature in the corresponding repository. 84 | 85 | ## External Dependencies 86 | 87 | DIDComm Mediator Service is deployed on an DIDComm Agent framework with examples 88 | included using [ACA-Py](https://aca-py.org) and 89 | [Credo-TS](https://github.com/openwallet-foundation/credo-ts). DIDComm Mediator 90 | Service also uses (via its embedded DIDComm agent) 91 | [Askar](https://github.com/hyperledger/aries-askar) for key management services 92 | and secure storage. 93 | 94 | ## Release Methodology 95 | 96 | DIDComm Mediator Service uses GitHub Actions for dependency notifications and 97 | management. The primary artifacts are Docker files that can be configured and 98 | used to deploy a fully featured, out of the box DIDComm mediator. 99 | 100 | ## Initial Maintainers 101 | 102 | | Name | Github | Organization | 103 | | -------------- | ----------- | ---------------------------------------- | 104 | | Stephen Curran | swcurran | Funded by Government of British Columbia | 105 | | Wade Barnes | WadeBarnes | Funded by Government of British Columbia | 106 | | Daniel Bluhm | dbluhm | Indicio, PBC | 107 | | Timo Glastra | TimoGlastra | Animo Solutions | 108 | 109 | ## Proposed Project Governance 110 | 111 | The current governance model under Hyperledger is consensus-based. This means that decisions are made through discussions, with the aim of community consensus, as outlined in the [Aries Project Charter](https://docs.google.com/document/d/1F6RbR7xDaBt5CDJhqLJzR4c1pDJtyPGshp9fy6eVtSM/edit?usp=sharing). In cases where no clear consensus is established, a project Technical Steering Committee, or the maintainers (those with escalated GitHub privileges) are granted a louder voice. This approach has proven effective. 112 | 113 | ## Links to Documented Governance Practices 114 | 115 | [Project Charter for Aries](https://docs.google.com/document/d/1F6RbR7xDaBt5CDJhqLJzR4c1pDJtyPGshp9fy6eVtSM/edit?usp=sharing). 116 | 117 | ## Financial Sponsorship 118 | 119 | Hyperledger has covered infrastructure related costs. Besides that, None. 120 | 121 | ## Infrastructure 122 | 123 | * GitHub repositories 124 | * CI (GitHub actions) 125 | * Bug Tracking (GitHub Issues and GitHub Projects) 126 | * Communication channels (Discord) 127 | * Mailing list 128 | * Video conference (Zoom) 129 | * Wiki / Meeting Pages (Confluence, likely to move to GitHub/Mkdocs) 130 | -------------------------------------------------------------------------------- /projects/eudi-wallet-kit-react-native.md: -------------------------------------------------------------------------------- 1 | # Project Name 2 | React Native kit for EUDI Wallet reference implementation. 3 | 4 | Proposed repository name: `eudi-wallet-kit-react-native`. 5 | 6 | # Preferred Maturity Level 7 | Labs 8 | 9 | # Project Description 10 | The project is a cross-platform React Native wrapper for [EUDI Wallet reference](https://github.com/eu-digital-identity-wallet/.github/blob/main/profile/reference-implementation.md) implementation. 11 | 12 | It allows building cross-platform Mobile Wallet applications compliant with [Electronic Identification, Authentication and Trust Services (eIDAS) Regulation](https://digital-strategy.ec.europa.eu/en/policies/eidas-regulation) and [EUDI Architecture and Reference Framework (ARF)](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework) and based on reference implementations from EUDI ([Android](https://github.com/eu-digital-identity-wallet/eudi-lib-android-wallet-core) and [iOS](https://github.com/eu-digital-identity-wallet/eudi-lib-ios-wallet-kit) correspondingly). 13 | 14 | # Alignment with the OpenWallet Foundation Mission 15 | EU has been standardising a concept of [EU Digital Identity (EUDI) Wallet](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework) based on self-sovereign identity principles and built upon [eIDAS 2.0](https://digital-strategy.ec.europa.eu/en/policies/eidas-regulation) (Electronic Identification, Authentication and Trust Services) regulation. EU Digital Identity will be available to EU citizens, residents, and businesses who want to identify themselves or provide confirmation of certain personal information. It can be used for both online and offline public and private services across the EU. Every EU citizen and resident in the Union will be able (on a voluntary basis) to use a personal digital wallet. 16 | 17 | The European Commission also released an initial [reference implementation of the EUDI Wallet software on GitHub](https://github.com/eu-digital-identity-wallet/.github/blob/main/profile/reference-implementation.md), serving as a foundation for further development by member states. 18 | 19 | EUDI Wallet reference implementation consists of native Android and iOS libraries and components. Although developing native mobile applications is a reasonable approach in many cases, it would be great to provide a possibility to easily build a cross-platform Mobile application based on the EUDI Wallet reference components. Such cross platform mobile applications can be used for Demo/PoC purposes, as well as a foundation for custom wallets compliant with EUDI ARF. 20 | 21 | React Native was selected as a basis for the project since it allows to develop high-quality cross-platform mobile applications efficiently, leveraging the power of JavaScript and the React ecosystem. React Native is a popular and demanded solution in decentralized identity space. 22 | 23 | Overall, the proposed project aligns with the OpenWallet Foundation Mission as it 24 | - provides a new open source tool for building cross-platform wallets; 25 | - guarantees wallet interoperability since it's built on top of EUDI ARF, EUDI Wallet reference libraries and corresponding interoperable standards (mDL, SD-JWT, OID4VC, etc.); 26 | - guarantees adoption of the solution since React Native and EUDI Wallet reference libraries are used; 27 | - helps in adoption and development of open standards (EUDI, mDL, SD-JWT, OID4VC, etc.); 28 | - helps in adoption and development of EUDI Wallet initiative which is important for advancing decentralized identity in EU. 29 | 30 | # Code of Conduct 31 | [OpenWallet Foundation code of conduct](https://tac.openwallet.foundation/governance/code-of-conduct/) 32 | 33 | # TAC Sponsor 34 | To be defined. 35 | 36 | # Project License 37 | Apache 2.0. 38 | 39 | # Source Control 40 | To be defined. Please note: this is a brand-new source code. The DSR team is working on the initial implementation and may append this section to the nearest feature. 41 | 42 | # Issue Tracker 43 | GitHub Issues. 44 | 45 | # External Dependencies 46 | As our project is essentially a React Native library, we're going to use a lot of common React/React Native dependencies that are hard to fully list here. 47 | 48 | The proposed project is built on top of EUDI wallet reference implementation, so the key dependencies are: 49 | - Apache 2.0 license: 50 | - [eudi-lib-android-wallet-core](https://github.com/eu-digital-identity-wallet/eudi-lib-android-wallet-core) 51 | - [eudi-lib-android-wallet-document-manager](https://github.com/eu-digital-identity-wallet/eudi-lib-android-wallet-document-manager) 52 | - [eudi-lib-android-iso18013-data-transfer](https://github.com/eu-digital-identity-wallet/eudi-lib-android-iso18013-data-transfer) 53 | - [eudi-lib-jvm-openid4vci-kt](https://github.com/eu-digital-identity-wallet/eudi-lib-jvm-openid4vci-kt) 54 | - [eudi-lib-jvm-siop-openid4vp-kt](https://github.com/eu-digital-identity-wallet/eudi-lib-jvm-siop-openid4vp-kt) 55 | - [nimbus.oauth2.oidc.sdk](https://bitbucket.org/connect2id/oauth-2.0-sdk-with-openid-connect-extensions/src/master/) 56 | - [eudi-lib-ios-wallet-kit](https://github.com/eu-digital-identity-wallet/eudi-lib-ios-wallet-kit) 57 | - [eudi-lib-ios-wallet-storage](https://github.com/eu-digital-identity-wallet/eudi-lib-ios-wallet-storage) 58 | - [eudi-lib-ios-iso18013-data-transfer](https://github.com/eu-digital-identity-wallet/eudi-lib-ios-iso18013-data-transfer) 59 | - [eudi-lib-ios-siop-openid4vp-swift](https://github.com/eu-digital-identity-wallet/eudi-lib-ios-siop-openid4vp-swift) 60 | - [eudi-lib-ios-openid4vci-swift](https://github.com/eu-digital-identity-wallet/eudi-lib-ios-openid4vci-swift) 61 | - [OWF identity-credential](https://github.com/openwallet-foundation-labs/identity-credential) 62 | 63 | Note: the list of dependencies may be changed in the future. 64 | 65 | # Release Methodology 66 | Since this is a brand-new codebase, we plan to begin with a simple initial approach for releases and gradually enhance it over time. 67 | 68 | **Initial approach** 69 | - GitHub package registry: Dev builds and first releases will be published in GitHub repo package registry . 70 | - Manual publish: Packages will be published manually. 71 | 72 | **Target approach** 73 | - NPM Packages: Packages will be published in NPM under OWF org scope. 74 | - CI/CD Pipelines: Automated pipelines to handle integration, testing and publishing. 75 | - Automated Checks: Automated tools to perform code quality and security scans. 76 | 77 | # Initial Maintainers 78 | - DSR Corporation Decentralized Systems Team ([Github](https://github.com/orgs/DSRCorporation/teams/decentralized-systems)) 79 | - Alexander Shenshin ([GitHub](https://github.com/AlexanderShenshin)) 80 | 81 | # Proposed Project Governance 82 | 83 | -- 84 | 85 | # Links to Documented Governance Practices 86 | 87 | -- 88 | 89 | # Financial Sponsorship 90 | DSR Corporation, LLC. Denver, Colorado. 91 | DSR Decentralized Systems Team has extensive experience in the development of decentralized systems, digital identity solutions and wallets. DSR team has contributed to more than 50 open source projects. In particular, we are one of the core contributors and maintainers of such open source projects as Hyperledger Indy, Hyperledger Indy Besu, Hyperledger AnonCreds, Hyperledger Aries, [OWF SD-JWT Rust](https://github.com/openwallet-foundation-labs/sd-jwt-rust), etc. DSR team has extensive experience with React Native and participated in development of a number of decentralized identity mobile wallets based on React Native. 92 | 93 | # Infrastructure 94 | GitHub Actions for CI/CD 95 | -------------------------------------------------------------------------------- /projects/farmworker-wallet-os.md: -------------------------------------------------------------------------------- 1 | # Project Name 2 | Farmworker Wallet OS 3 | 4 | ![Watermelon workers](https://github.com/Entidad/farmworkerwallet/blob/main/WatermelonWorkers.png) 5 | 6 | # Project Description 7 | The **Farmworker Wallet OS** project is a community of contribution led by [Entidad](https://www.entidad.io/) and the [United Farm Workers Foundation](https://www.ufwfoundation.org/) (UFWF) with the goal of furthering the adoption of an open, secure, interoperable digital wallet engine that makes it easier for farmworker communities to access an ecosystem of life-altering social and human services. 8 | 9 | Farmworkers are the backbone of global food supply chains, yet they remain one of the most underserved segments of our population. Governments around the world deemed them ‘Essential’ during the recent pandemic. While services and programs exist to help, it’s challenging and costly for organizations that provide them to securely collect and verify the information needed to prove applicant eligibility claims. As a result, most farmworkers forego services and resources they need, even though they’re eligible for them. 10 | 11 | 12 | Over the last three years, Entidad and the UFW Foundation have been exploring digital trust technologies to solve this problem. We’ve developed PrepareseTM, a digital infrastructure solution that lets farmworker organizations securely reuse verified farmworker information, eliminating the need for repetitive collection. The solution layers didcomm, wallet, decentralized identifiers, and verifiable credential technologies with a low-code application development platform, [Mendix](https://www.mendix.com/). 13 | 14 | 15 | Mendix has been a key component in making the PrepareseTM solution possible. Low-code software development has been growing in popularity and bringing new audiences to the practice. Mendix, one of the more popular platforms with over 300K active developers and 50M users, has enabled Entidad and the UFW Foundation to develop, launch, and maintain enterprise-grade digital trust enabled solutions that solve real world problems. 16 | 17 | 18 | We’ve built two products, using this technology. For organizations we’ve built Preparese PlatformTM, it allows them to quickly develop and launch digital trust enabled services and programs. For farmworkers, we’ve developed Preparese MobileTM which combines a verifiable digital profile with a suite of tools that simplify interactions with organizations on the platform. 19 | 20 | 21 | The Preparese PlatformTM is being used by 9 organizations and has 5 digital services in production. The most recent service launched is being used to process and distribute [$80 million](https://www.usda.gov/media/press-releases/2021/09/07/usda-invests-700-million-grants-provide-relief-farm-and-food) in one-time relief payments to over 125,000 workers, under the United States Department of Agriculture’s [Farm and Food Workers Relief Program](https://www.ams.usda.gov/services/grants/ffwr) (FFWR). 22 | 23 | The second product, Preparese MobileTM, is designed around the unique needs of farmworkers. We’ve developed a react native mobile app that lets farmworkers store, manage, and exchange their verified information. Engagement with organizations is made easier with [DIDComm](https://didcomm.org/book/v2/)-based communication capabilities such as text and video chat. 24 | 25 | 26 | One of the cornerstone technologies of the solution is an interoperable Mendix enabled digital wallet. The wallet components need to be able to engage with various non-profit, government, and philanthropic sources, each with their own technology stacks. For this reason, interoperability and working with open standard frameworks has been a priority. The project team members have participated in [TrustOverIP Foundation](https://trustoverip.org/), [Hyperledger Aries JS Working Group](https://wiki.hyperledger.org/display/ARIES/Aries+Framework+JavaScript), and various other communities, including [DID Communication Working Group](https://identity.foundation/working-groups/did-comm.html) and [OpenWallet Foundation](https://openwallet.foundation/) of late, to ensure we adhere to best practices and standards. 27 | 28 | 29 | While currently focused on farmworkers, the Mendix digital wallet engine can be used to help others. There are many other underserved communities that could benefit greatly from the privacy, accessibility, and security digital wallets can provide. With this social impact purpose in mind and spirit of further collaboration, Entidad and the UFW Foundation propose to open source the digital wallet engine used in their PrepareseTM solution. By making these resources available, we hope to facilitate a wide variety of social impact. 30 | 31 | 32 | Additionally, the project allows us to bridge and advance the interest of both the OpenWallet Foundation and Mendix communities. By collaborating with the Mendix community, we not only have the ability to grow the number of digital trust technology practitioners, we also tap into a community with an established customer base. By making digital wallets components that can be easily integrated into their existing solutions, the project can drive further adoption and usage of interoperable, secure and privacy preserving digital wallets. 33 | 34 | 35 | 36 | ## Origin & History 37 | 38 | The origins of the **Farmworker Wallet OS** project align with those of Entidad. What began as a volunteering effort by three college friends, was formalized in 2018 with the founding of Entidad as a public benefit corporation. We have primarily been working with leading farm worker-serving organizations to develop technology that leverages growing digital literacy in their communities to scale their impact. 39 | 40 | 41 | The first digital service launched supported the UFW Foundation’s emergency relief efforts during the height of the COVID-19 pandemic. The solution was used to plan, manage and operate over 500 in-person community events where over $15 million in resources were distributed to over 40K families. Additionally, it has allowed us to better understand the unique challenges of building for underserved communities and why interoperable, secure, and privacy preserving technologies are key to addressing these challenges.  42 | 43 |   44 | You can read more about our journey on [our blog](https://www.entidad.io/blog). 45 | 46 | # Alignment with the OpenWallet Foundation Mission 47 | The **Farmworker Wallet OS** project is a community of contribution led by Entidad and the United Farm Workers Foundation (UFWF) with the goal of furthering the adoption of an open, secure, interoperable [digital wallet solution](https://youtu.be/Uo7CTtGrOw8) that makes it easier for farm worker communities to access life-changing social and human services. The open-source software components maintained by this community will enable non-profit and social good organizations to build wallet-driven solutions on top of the Mendix low-code platform. Collaboration with app makers from the broader Mendix developer community will help inform and guide the Farmworker Wallet OS project with industry proven best practices, leading to the implementation of reusable functionality that is aligned with the goals of the Open Wallet Foundation (to preserve user choice, security and privacy). The community will also inspire the next generation of low-code app builders to learn and expand their skill sets with decentralized (web3) technologies. 48 | 49 | # Current Code of Conduct 50 | [OpenWallet Foundation Code of Conduct](https://tac.openwallet.foundation/governance/code-of-conduct/) 51 | 52 | # TAC Sponsor 53 | _Include the name of a sponsor from the TAC, if identified (a sponsor helps mentor projects)_ 54 | 55 | # Project License 56 | [Apache License, Version 2.0](https://www.apache.org/licenses/LICENSE-2.0) 57 | 58 | # Source Control 59 | Github 60 | 61 | # Issue Tracker 62 | Github 63 | 64 | # External Dependencies 65 | Mendix is a low-code application platform provider so its terms of service cover usage of Mendix services and resources by Mendix developers (organizations and/or individual contributors). The **Application model** for a standards compliant wallet engine will be the primary focus for the contributors of this project. The Mendix terms of service do protect the IP rights to these App models in Section 3 with reference to "Customer Data" definition in section 17. 66 | 67 | There are [design-time](https://www.mendix.com/evaluation-guide/developing-in-mendix/) and [runtime](https://www.mendix.com/evaluation-guide/app-lifecycle/deployment/) aspects of app development but one of the great things about this tooling is that there is clean separation between the two. 68 | 69 | The following captures the developer's "design-time" perspective. We hope that the diagram helps to clarify the software components that would fall under the scope of this OWF project and distinguishes PrepareseTM as an example of a closed (proprietary) application that embeds core Farmworker WalletOS components. We plan on documenting a similar diagram to aid in understanding the "runtime" perspective soon. 70 | 71 | ![Designtime perspective](https://github.com/Entidad/farmworkerwallet/blob/main/Farmworker_WalletOS_OSS_Project.png) 72 | 73 | 1. [Mendix Studio Pro v9.24.4](https://marketplace.mendix.com/link/studiopro/) (integrated developer environment) 74 | 2. [Eclipse Temurin JDK 11 (x64)](https://adoptium.net/temurin/releases/?version=11) 75 | 3. [Mendix Native Template v7.0.1](https://docs.mendix.com/refguide9/mobile/distributing-mobile-apps/building-native-apps/native-template/) 76 | 4. [React Native v0.70.7](https://reactnative.dev/versions) 77 | 5. [Hyperledger / Aries-Framework-Javascript v0.4.0](https://github.com/hyperledger/aries-framework-javascript/releases/tag/v0.4.0) 78 | 6. Development instance of an [Aries Mediator Service](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0046-mediators-and-relays) 79 | 7. Development instance of an [Aries Cloud Agent](https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0004-agents) 80 | 81 | # Release Methodology 82 | _If the project already exists, please provide details on the release methodology and mechanics._ 83 | 84 | # Initial Maintainers 85 | * [Ockert van Schalkwyk](https://github.com/skullquake) 86 | * [Jorge Flores](https://github.com/jorgefl0) 87 | 88 | # Proposed Project Governance 89 | The leadership team is composed of the individuals responsible for the development of the Mendix digital wallet used in the Preparese solution. The team has a demonstrated track record of delivering enterprise level digital trust solutions to the market. The proposed members are from Entidad and the Mendix developer community. By drawing from these two groups, we hope to introduce a balanced and diverse perspective that is representative of the three core communities this project hopes to serve.   90 | 91 | 92 | All are committed to the Farmworker Wallet OS project and each leader plays a different role in its success: 93 | 94 | * As the principal, Jorge Flores is responsible for maintaining the vision of the project, sourcing outside advisors, participants, and new ideas for collaboration and industries to serve. His extensive background as a CTO and his passion for digital trust technologies, communication platforms, and mobile application frameworks makes him a prime candidate to be the technical advisor for this project.  95 | 96 | * As the Developer Lead, Ockert van Schalkwyk is responsible for maintaining an Enterprise level standard for the project’s software code.  He will review and approve changes, forks, and merges.  His background as senior Mendix developer with a focus on systems integrations, makes him the ideal candidate for the role.    97 | 98 | * As a Mendix Solution architect, Stephan Bruijnis is responsible for guiding architectural integrity of the project.  He will ensure the project upholds and maintains targeted privacy, security, and interoperability standards. His extensive experience as a Senior Mendix architect makes him ideal for this project.    99 | 100 | * As the Methodology and Mechanics Lead, Ned Gosaynie is responsible for maintaining documentation and versioning for the project.  He will review and approve the technical documentation needed to support the project needs. Additionally, he will manage versioning of the software. His experience as the of Head of Platform Services makes him the ideal candidate for this position.   101 | 102 | 103 | The team’s philosophy for the Farmworker Wallet OS project will be a continuation of the social good principles that have driven the project since its origin. Having worked together for years, the team has a well-established working relationship. Decisions will be evaluated through the lens of farmworker benefit, security, privacy, and impact.   104 | 105 | # Links to Documented Governance Practices 106 | _Include links to any documented governance practices._ 107 | 108 | # Preferred Maturity Level 109 | Labs 110 | 111 | # Communication Channels 112 | Discord 113 | 114 | # Project Website 115 | We don't have a project website as our work has not officially been open-sourced yet. 116 | 117 | # Social Media 118 | We don't have social media presence as our project has not officially been open-sourced yet. 119 | 120 | # Financial Sponsorship 121 | UFW Foundation 122 | 123 | # Infrastructure 124 | The **Farmworker Wallet OS** will be organized and published as a suite of software modules that can be imported into any existing Mendix app code repository. The Mendix software modules effectively serve as a digital wallet SDK that can be embedded into any Mendix application to enhance the user experience. The code repository for this project is itself a Mendix app repository and as such can be executed locally on any [supported](https://docs.mendix.com/refguide9/system-requirements/) developer workstation. 125 | 126 | 127 | The initial version of the digital wallet SDK is being built on top of [Aries Framework Javascript](https://github.com/hyperledger/aries-framework-javascript), an open-source framework maintained by the [Hyperledger Aries developer community](https://www.hyperledger.org/use/aries) helping to foster participation with the [Aries digital trust ecosystem](https://github.com/hyperledger/aries-rfcs). Over time, the digital wallet SDK will be extended to support other digital trust open standards such as [OpenID for Verifiable Credentials (OID4VC)](https://openid.net/sg/openid4vc/specifications/). 128 | -------------------------------------------------------------------------------- /projects/learner-credential-wallet.md: -------------------------------------------------------------------------------- 1 | 2 | # Project Name 3 | Learner Credential Wallet 4 | 5 | # Preferred Maturity Level 6 | Labs stage 7 | 8 | # Project Description 9 | The Learner Credential Wallet is a cross-platform iOS and Android mobile application for storing and sharing digital credentials, starting with higher learning. 10 | 11 | The wallet is based on the learner credential wallet specification developed by the Digital Credentials Consortium. 12 | 13 | The app works with iOS and Android and allows users to add and share credentials, as well as manage the wallet. 14 | 15 | Whenver possible, we use existing open standards from W3C, IETF, and other open standards groups. 16 | 17 | 18 | # Alignment with the OpenWallet Foundation Mission 19 | This project aligns with the OWF mission, because it's an open source example implementation of wallet-related open standards. 20 | 21 | # Code of Conduct 22 | https://linuxfoundation.eu/en/policies 23 | 24 | # TAC Sponsor 25 | 26 | 27 | # Project License 28 | MIT License but can change to Apache 2.0 and will leave open to discussion. 29 | 30 | # Source Control 31 | https://github.com/digitalcredentials/learner-credential-wallet 32 | 33 | # Issue Tracker 34 | https://github.com/digitalcredentials/learner-credential-wallet/issues 35 | 36 | # External Dependencies 37 | See package.json (https://github.com/digitalcredentials/learner-credential-wallet/blob/main/package.json) - Have ensured that all dependencies are all open source. 38 | 39 | # Release Methodology 40 | Follows standard iOS and Android release store methodologies. 41 | 42 | # Initial Maintainers 43 | * [Dmitri Zagidulin](https://github.com/dzagidulin) 44 | * [James Chartrand](https://github.com/jchartrand) 45 | * [Alex Higuera](https://github.com/alexfigtree) 46 | * [Kerri Lemoie](https://github.com/kayaelle) 47 | 48 | The Digital Credentials Consortium (DCC) is a group of international postsecondary institutions leading the development of software and services that promote the adoption of W3C Verifiable Credentials in higher education. With the support of the US Department of Education, the DCC developed the open source Learner Credential Wallet (LCW), a mobile application that provides a secure, portable location for receiving, storing and sharing Verifiable Credentials. 49 | 50 | # Proposed Project Governance 51 | So far, this has been a small team process led by the DCC but are open to recommendations. All decisions are made by consensus. 52 | 53 | # Links to Documented Governance Practices 54 | Include a link to the project charter. The project charter can be obtained by completing the [project intake form](https://docs.google.com/forms/d/e/1FAIpQLSeO1bDGHUP-ZpCo1uynm94YOxZlek6RhCH7o3FnX1lZSXXfSQ/viewform?fbzx=4351560609072672295). 55 | 56 | # Financial Sponsorship 57 | None 58 | 59 | # Infrastructure 60 | We will require GitHub Repos with Issues/Bug Tracking, GitHub CI Actions, and mailing list. 61 | -------------------------------------------------------------------------------- /projects/mdl-js.md: -------------------------------------------------------------------------------- 1 | # Project Name 2 | 3 | mdl-js 4 | 5 | # Preferred Maturity Level 6 | 7 | Labs 8 | 9 | # Project Description 10 | 11 | This is a Typescript(Javascript) implementation of the [ISO 18013-5:2021](https://www.iso.org/standard/69084.html) (MDL) specification. 12 | 13 | There is only one mdl implementation from Auth0 labs, but they don't support React Native which is most crucial for mobile wallets. This project aims to provide a platform agnostic implementation of the MDL specification. 14 | 15 | I guess the main reason for not providing a React Native is that core dependencies like CBOR, COSE and X509 libraries are not available for React Native. So I decided to make them all platform agnostic. 16 | 17 | To provide mdl features to Biggest Wallet SDKs like credo or veramo, direction of the project will be: 18 | 19 | - Provide a platform agnostic implementation of the MDL specification 20 | - Bring your own crypto 21 | - Modular approach 22 | - Provide platform specific helper implementations for developers to use easily 23 | 24 | # Alignment with the OpenWallet Foundation Mission 25 | 26 | ISO 18013-5 (MDL) is one of the most important standards for digital wallets. The architecture reference framework of the EU also includes MDL. 27 | 28 | # Code of Conduct 29 | 30 | [OpenWallet Foundation code of conduct](https://tac.openwallet.foundation/governance/code-of-conduct/) 31 | 32 | # TAC Sponsor 33 | 34 | @aceshim Ace Shim 35 | 36 | # Project License 37 | 38 | Apache 2.0 39 | 40 | # Source Control 41 | 42 | https://github.com/lukasjhan/mdoc 43 | 44 | # Issue Tracker 45 | 46 | https://github.com/lukasjhan/mdoc/issues 47 | 48 | # External Dependencies 49 | 50 | - js-base64: pure js base64 encoder/decoder 51 | 52 | # Release Methodology 53 | 54 | Project will be released on NPM. I have `@m-doc` organization on NPM for this project. Package name will be like `@m-doc/mdl`. 55 | 56 | # Initial Maintainers 57 | 58 | Lukas Han ([Github](https://github.com/lukasjhan)) 59 | 60 | # Proposed Project Governance 61 | 62 | Everyone should be able to contribute to the project. Contributors will be able to open issues via Github to discuss their ideas. 63 | 64 | # Links to Documented Governance Practices 65 | 66 | # Financial Sponsorship 67 | 68 | None 69 | 70 | # Infrastructure 71 | 72 | None 73 | -------------------------------------------------------------------------------- /projects/multiformat-vc-ios.md: -------------------------------------------------------------------------------- 1 | # Project Name 2 | 3 | Multiformat Verifiable Credentials for iOS 4 | 5 | # Preferred Maturity Level 6 | 7 | Labs 8 | 9 | # Project Description 10 | 11 | Pure Swift package for creating Verifiable Credentials (VCs) in multiple formats 12 | 13 | - SD-JWT VC: Selective Disclosure JWT based Verifiable Credentials - using the specification defined at https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/ 14 | - VC JWT: Verifiable Credentials as JWT - using the format defined at JWT VC Presentation Profile https://identity.foundation/jwt-vc-presentation-profile/ 15 | 16 | Support for multiple data types for disclosed values including 17 | 18 | - String 19 | - Int 20 | - Boolean 21 | - Array of Strings - [String] 22 | - Dictionary of String keys and String values - [String:String] 23 | 24 | This project is a contribution of the work done at Ping Identity to test and establish interoperability of the various formats representing the Verifiable Credentials Data Model https://www.w3.org/TR/vc-data-model/. Along with the SD-JWT VC and JWT VC formats described above, Ping Identity has also participated in the interoperability event for OpenID4VP to present a VC JWT. That code will also be released as a part of this project. 25 | 26 | # Alignment with the OpenWallet Foundation Mission 27 | 28 | This Swift package implements three popular formats for Verifiable Credentials. SD-JWT, JWT, and ISO mDoc (coming soon). The library helps with the adoption of these formats for iOS apps written in Swift. This library promotes best practices for the adoption of these standards in user wallets for iOS devices. 29 | 30 | # Code of Conduct 31 | 32 | [OpenWallet Foundation code of conduct](https://tac.openwallet.foundation/governance/code-of-conduct/) 33 | 34 | # TAC Sponsor 35 | 36 | Jeremie Miller (https://github.com/quartzjer) 37 | 38 | # Project License 39 | 40 | [Apache License, Version 2.0](https://opensource.org/license/apache-2-0/) 41 | 42 | # Source Control 43 | 44 | [https://github.com/pingidentity/MultiformatVC-iOS](https://github.com/pingidentity/MultiformatVC-iOS) 45 | 46 | # Issue Tracker 47 | 48 | - Github Issues 49 | 50 | # External Dependencies 51 | 52 | - None 53 | 54 | # Release Methodology 55 | 56 | _N/A (not applicable)_ 57 | 58 | # Initial Maintainers 59 | 60 | Gaurav Khot([Github](https://github.com/gauravping)) 61 | 62 | # Proposed Project Governance 63 | 64 | _None_ 65 | 66 | # Links to Documented Governance Practices 67 | 68 | https://docs.google.com/forms/d/e/1FAIpQLSeO1bDGHUP-ZpCo1uynm94YOxZlek6RhCH7o3FnX1lZSXXfSQ/viewform?fbzx=4351560609072672295 69 | 70 | # Financial Sponsorship 71 | 72 | [Ping Identity, Denver, CO](https://pingidentity.com) 73 | 74 | # Infrastructure 75 | 76 | - None 77 | -------------------------------------------------------------------------------- /projects/oid4vc-ts.md: -------------------------------------------------------------------------------- 1 | # Project Name 2 | 3 | OID4VC TypeScript 4 | 5 | # Preferred Maturity Level 6 | 7 | Labs 8 | 9 | # Project Description 10 | 11 | The OpenID for Verifiable Credentials set of standards provide integration of existing OpenID and OAuth2 standards with verifiable credentials. 12 | 13 | OID4VC TypeScript is a generic, and low-level implementation of specifications. Currently it provides APIs for Issuers, Wallets, Clients, Authorization Servers and Resource Providers, covering OpenID for Verifiable Credential Issuance, and OAuth2. In addition, it supports a wide range of other OAuth2 related specifications for interoperability and security (such as Pushed Authorization Requests, Demonstrating Proof of Possesion, and PKCE). 14 | 15 | Having experience with integration of these standards into another OWF project, Credo, we were able to create a lower-level reusable library that handles the complex parts of the specification, while still allowing full control over the full flow. 16 | 17 | In the coming months this project will be extended with support for OpenID for Verifiable Presentations and related specifications. 18 | 19 | The goal of this library is to stay as agnostic as possible to the credential formats being used. This keeps the dependencies minimal, while also making it less opinionated. Dependent libraries or frameworks (such as Credo) can provide the needed credential formats, crypto suites, and persistence. 20 | 21 | The library was created by Animo as part of the SPRIN-D Funke wallet competition. 22 | 23 | # Alignment with the OpenWallet Foundation Mission 24 | 25 | The OID4VC TypeScript library provides a reusable library that is crucial to wallet interoperability. It is implementing the standards that are being adopted as part of the EU Digital Identity Wallet, as well as other regions in the world (such as California's drivers license project which also supports OID4VC). 26 | 27 | The library is already being used by Credo, which is part of the reason why we think it's important this library is also contributed to OWF rather than managed by Animo. 28 | 29 | # Code of Conduct 30 | 31 | Will adopt OWF code of conduct. 32 | 33 | # TAC Sponsor 34 | 35 | Stephen Curran 36 | 37 | # Project License 38 | 39 | Apache 2.0 40 | 41 | # Source Control 42 | 43 | Project already exists on Github: https://github.com/animo/oid4vc-ts. Slug should become oid4vc-ts once transferred. 44 | 45 | # Issue Tracker 46 | 47 | https://github.com/animo/oid4vc-ts/issues?q=sort%3Aupdated-desc+is%3Aissue+is%3Aopen 48 | 49 | # External Dependencies 50 | 51 | - [Valibot](https://github.com/fabian-hiller/valibot) - MIT 52 | - [Buffer](https://github.com/feross/buffer) - MIT 53 | 54 | # Release Methodology 55 | 56 | Packages are relased on NPM, OWF will be added as owner on NPM: 57 | 58 | - https://www.npmjs.com/package/@animo-id/oid4vci 59 | - https://www.npmjs.com/package/@animo-id/oauth2 60 | - https://www.npmjs.com/package/@animo-id/oauth2-utils 61 | 62 | The scope (`@animo-id/`) should be changed. As `@oid4vc` is taken we have reserved the `@openid4vc` scope on NPM. 63 | 64 | We use changesets to write changelog entries, and a bot will create a pull request for new releases. Once the PR is merged a new release will be created automatically. We have used this method extensively and it automates 99% of the process, and works well with keeping restrictions of bots pushing to main (you can use the normal PR approval and merge process to trigger releases). Example: https://github.com/animo/oid4vc-ts/pull/8 65 | 66 | # Initial Maintainers 67 | 68 | - Timo Glastra - [@TimoGlastra](https://github.com/TimoGlastra) - Creator of the library, maintainer of Credo (that leverages this project) 69 | - Martin Auer - [@auer-martin](https://github.com/auer-martin) - maintainer of Credo, experienced with OpenID4VC standards 70 | - Berend Sliedrecht - [@berendsliedrecht](https://github.com/berendsliedrecht) - maintainer of Credo 71 | - Alexis Delamare Deboutteville [@marsouin](https://github.com/marsouin) - verifiables.com 72 | 73 | # Proposed Project Governance 74 | 75 | The projects will mostly be managed by the existing Credo maintainers. Large decisions will be initially discussed as part of the Credo working group calls, but we would still like a dedicated discord channel. Later if desired by the community, the project can be more separated from the Credo project. 76 | 77 | The design of the project is mostly led by Timo Glastra, who created this library for Animo as part of the SPRIN-D Funke wallet competition. Timo Glastra will also mostly take on general maintenance and releases of the library. Alexis Delamare Deboutteville has indicated he and his company are also interested in contributing and taking on a maintainer role for the project. Although Martin and Timo are both associated with Animo, Martin should be seen as independent maintainer of this library, not associated with Animo. 78 | 79 | # Financial Sponsorship 80 | 81 | The development of this library was funded by Animo, which in turn received funding through the SPRIN-D Funke wallet competition. 82 | 83 | # Infrastructure 84 | 85 | - Github repo 86 | - Discord channel 87 | - Github actions 88 | - NPM 89 | -------------------------------------------------------------------------------- /projects/openid-federation-ts.md: -------------------------------------------------------------------------------- 1 | # Project Name 2 | 3 | OpenID Federation TypeScript 4 | 5 | # Preferred Maturity Level 6 | 7 | Labs 8 | 9 | # Project Description 10 | 11 | Trust is still a complex and relatively unsolved topic in the decentralized identity, EU Identity Wallet and digital credential ecosystems. 12 | 13 | OpenID Federation defines basic components used to build multilateral federations for building trust infrastructure. 14 | 15 | OpenID Federation TypeScript is a generic, and low-level implementation of the OpenID Federation specification, with a focus on [OpenID Federation Wallet Architecture](https://openid.net/specs/openid-federation-wallet-1_0.html). Currently it provides APIs for creating and resolving of entity configuration and statements. In the coming months support will be added for metadata policies and trust marks. 16 | 17 | The goal of this library is to provide minimal and reusable primitives for building a federation client or server. This keeps the dependencies minimal, while also making it less opinionated. Dependent libraries or frameworks (such as Credo) can provide the needed hosting of endpoints, signing callbacks, and persistence. 18 | 19 | The library was created by Animo as part of the SPRIN-D Funke wallet competition. 20 | 21 | # Alignment with the OpenWallet Foundation Mission 22 | 23 | The OpenID Federation library provides a reusable library that is crucial building trust ecosystems for wallets. 24 | 25 | The library is already being integrated into Credo, which is part of the reason why we think it's important this library is also contributed to OWF rather than managed by Animo. 26 | 27 | # Code of Conduct 28 | 29 | Will adopt OWF code of conduct. 30 | 31 | # TAC Sponsor 32 | 33 | Stephen Curran 34 | 35 | # Project License 36 | 37 | Apache 2.0 38 | 39 | # Source Control 40 | 41 | Project already exists on Github: https://github.com/animo/openid-federation-ts. Slug should become openid-federation-ts once transferred. 42 | 43 | # Issue Tracker 44 | 45 | https://github.com/animo/openid-federation-ts/issues?q=sort%3Aupdated-desc+is%3Aissue+is%3Aopen 46 | 47 | # External Dependencies 48 | 49 | - [Zod](https://github.com/colinhacks/zod) - MIT 50 | - [Buffer](https://github.com/feross/buffer) - MIT 51 | 52 | # Release Methodology 53 | 54 | Packages are relased on NPM, OWF will be added as owner on NPM: 55 | 56 | - http://npmjs.com/package/@openid-federation/core 57 | 58 | The library will be updated to changesets to write changelog entries, and a bot will create a pull request for new releases. Once the PR is merged a new release will be created automatically. We have used this method extensively and it automates 99% of the process, and works well with keeping restrictions of bots pushing to main (you can use the normal PR approval and merge process to trigger releases). Example: https://github.com/animo/oid4vc-ts/pull/8 59 | 60 | # Initial Maintainers 61 | 62 | - Berend Sliedrecht - [@berendsliedrecht](https://github.com/berendsliedrecht) - initial creator and current maintainer of the library, maintainer of Credo 63 | - Tom Lanser - [@tommylans](https://github.com/tommylans) - current maintainer of the library 64 | - Timo Glastra - [@TimoGlastra](https://github.com/TimoGlastra) - maintainer of Credo (that leverages this project) 65 | 66 | # Proposed Project Governance 67 | 68 | The projects will mostly be managed by the existing Credo maintainers. Large decisions will be initially discussed as part of the Credo working group calls, but we would still like a dedicated discord channel. Later if desired by the community, the project can be more separated from the Credo project. 69 | 70 | The design of the project is mostly led by Berend Sliedrecht and Tom Lanser, who created this library for Animo as part of the SPRIN-D Funke wallet competition. Timo Glastra and Berend Sliedrecht will mostly take on general maintenance and releases of the library. 71 | 72 | # Financial Sponsorship 73 | 74 | The development of this library was funded by Animo, which in turn received funding through the SPRIN-D Funke wallet competition. 75 | 76 | # Infrastructure 77 | 78 | - Github repo 79 | - Discord channel 80 | - Github actions 81 | - NPM 82 | -------------------------------------------------------------------------------- /projects/rust-tsp.md: -------------------------------------------------------------------------------- 1 | # Project Name 2 | The project is currently known as "rust-tsp". 3 | 4 | We may or may not change this name to something that does not directly reference "Rust" because although the core is implemented in Rust, we expect additional language bindings in the project. 5 | 6 | # Preferred Maturity Level 7 | Lab 8 | 9 | # Project Description 10 | This project is an early implementation of the draft Trust Spanning Protocol (TSP): https://github.com/trustoverip/tswg-tsp-specification. 11 | 12 | According to the above referenced specification, "The Trust Spanning Protocol (TSP) facilitates secure communication between endpoints with potentially different identifier types, using message-based exchanges. As long as these endpoints use identifiers based on public key cryptography (PKC) with a verifiable trust root, TSP ensures their messages are authentic and, if optionally chosen, confidential. Moreover, it presents various privacy protection measures against metadata-based correlation exploitations. These attributes of TSP together allow endpoints to form authentic relationships rooted in their respective verifiable identifiers (VIDs), viewing TSP messages as virtual channels for trustworthy communication." 13 | 14 | A shorter introduction of TSP can be found in this blog post: https://www.trustoverip.org/blog/2023/08/31/mid-year-progress-report-on-the-toip-trust-spanning-protocol/ 15 | 16 | This project's current code includes a Rust implementation of all TSP features. We also plan to incorporate/develop related features such as additional Verifiable Identifier types, additional transport layer mechanisms, different language bindings as needed and integration modules needed to be compatible with other OpenWallet projects. 17 | In addition, we may add and welcome trust task or application specific extensions. 18 | 19 | # Alignment with the OpenWallet Foundation Mission 20 | TSP's core features provide a foundation for interoperability of different trust basis mechanisms and ensuring a very strong sense of authenticity, confidentiality and optionally meta-privacy. 21 | These features are critical to open, secure, and safe wallets, decentralization of various system components, interoperability between domains (e.g. different technical approaches, different countries or regulatory or industry ecosystems) and communication or sharing of data between endpoints empowered by modern open wallets. The TSP specification is being developed by the Trust over IP Foundation, a sister organization also under the Linux Foundation. This project will be a collaboration with the standard spec work in ToIP. 22 | 23 | # Code of Conduct 24 | We will adopt the [OpenWallet Foundation code of conduct](https://tac.openwallet.foundation/governance/code-of-conduct/). 25 | 26 | # TAC Sponsor 27 | - Wenjing Chu (myself), and 28 | - Tracy Kuhrt 29 | - Mike Varley 30 | 31 | # Project License 32 | Current code is Apache 2.0. 33 | 34 | # Source Control 35 | It's in a GitHub repo that can be moved to OpenWallet: https://github.com/wenjing/rust-tsp. 36 | 37 | # Issue Tracker 38 | We use GitHub issue tracker open to all:https://github.com/wenjing/rust-tsp/issues. 39 | 40 | # External Dependencies 41 | The only required dependencies for now are the following Rust crates: hpke, rand, sha2, ed25519-dalek, url, base64ct and thiserror. 42 | 43 | See the complete list here: https://github.com/wenjing/rust-tsp/blob/main/tsp/Cargo.toml#L42 44 | 45 | Also most "async" and "resolve" are from the tokio project https://tokio.rs/ or listed on https://blessed.rs/crates. And if libsodium is used, then also the "crypto_box" crate. 46 | 47 | The source code for to core deps: 48 | - https://github.com/rozbb/rust-hpke 49 | - https://github.com/rust-random/rand 50 | - https://github.com/RustCrypto/hashes 51 | - https://github.com/dalek-cryptography/curve25519-dalek 52 | - https://github.com/servo/rust-url 53 | - https://github.com/RustCrypto/formats 54 | - https://github.com/dtolnay/thiserror 55 | 56 | # Release Methodology 57 | This is an early implementation in progress. There is not currently a release methodology, so we will answer with "N/A (not applicable)". 58 | 59 | # Initial Maintainers 60 | - Marlon Baeten: @marlonbaeten 61 | - Marc Schoolderman: @squell 62 | - Wenjing Chu: @wenjing 63 | - Additional maintainers are expected in the near future 64 | 65 | # Proposed Project Governance 66 | We have yet to adopt any process but can work with contributors and OpenWallet community to adopt one. 67 | 68 | # Links to Documented Governance Practices 69 | The LF Intake form completed/submitted. 70 | 71 | # Financial Sponsorship 72 | The project is currently sponsored by Futurewei Technologies Inc. but we do not expect financial sponsorship in the future as an OpenWallet Foundation project. 73 | 74 | # Infrastructure 75 | Within the [services for projects and labs](https://tac.openwallet.foundation/governance/project-and-lab-services/), we request 76 | - GitHub repo (move to OWF repo) 77 | - OWF Discord chat 78 | - OWF mailing list (for people who have difficulties in accessing Discord readily) 79 | - Paid tooling: e.g. GitHub based build tools/actions 80 | 81 | To properly test TSP in various modes, we wish to request if OWF can support testing infrastructure (to be discussed). 82 | -------------------------------------------------------------------------------- /projects/sd-jwt-dotnet.md: -------------------------------------------------------------------------------- 1 | # Project Name 2 | 3 | SD-JWT-DotNet 4 | 5 | # Preferred Maturity Level 6 | 7 | Labs 8 | 9 | # Project Description 10 | 11 | A Dot Net implementation of the [Selective Disclosure for JWTs](https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-04.html) (SD-JWT) specification. 12 | 13 | # Alignment with the OpenWallet Foundation Mission 14 | 15 | This library implements the Selective Disclosure for JWTs specification, which is an important building block for future digital identity wallets. 16 | 17 | # Code of Conduct 18 | 19 | None 20 | 21 | # TAC Sponsor 22 | 23 | None 24 | 25 | # Project License 26 | 27 | Apache 2.0. 28 | 29 | # Source Control 30 | 31 | [https://github.com/thomas-tran/sd-jwt-dotnet](https://github.com/thomas-tran/sd-jwt-dotnet) 32 | 33 | # Issue Tracker 34 | 35 | [https://github.com/thomas-tran/sd-jwt-dotnet/issues](https://github.com/thomas-tran/sd-jwt-dotnet/issues) 36 | 37 | # External Dependencies 38 | 39 | ```nuget 40 | // https://www.nuget.org/packages/gfoidl.Base64 41 | // License: MIT 42 | gfoidl.Base64 43 | 44 | ``` 45 | 46 | # Release Methodology 47 | 48 | N/A 49 | 50 | # Initial Maintainers 51 | 52 | Thomas Tran([Github](https://github.com/thomas-tran)) 53 | 54 | # Proposed Project Governance 55 | 56 | None 57 | 58 | # Links to Documented Governance Practices 59 | 60 | https://docs.google.com/forms/u/2/d/e/1FAIpQLSeO1bDGHUP-ZpCo1uynm94YOxZlek6RhCH7o3FnX1lZSXXfSQ/formResponse?pli=1 61 | 62 | # Financial Sponsorship 63 | 64 | None 65 | 66 | # Infrastructure 67 | 68 | None 69 | -------------------------------------------------------------------------------- /projects/sd-jwt-js.md: -------------------------------------------------------------------------------- 1 | # Project Name 2 | 3 | SD-JWT Javascript/Typescript Reference Implementation 4 | 5 | # Preferred Maturity Level 6 | 7 | Growth 8 | 9 | ## Growth 10 | 11 | - 2 TAC sponsors to champion the project and provide mentorship as needed. 12 | - Development of a growth plan, to be done in conjunction with their project mentor(s) at the TAC. 13 | - Development of a project roadmap that provides differentiated features and capabilities and the timeframe for completion. 14 | - Defined Roadmap Activities: 15 | - Continuously updated until standards are finalized. 16 | - SD-JWT 17 | - SD-JWT VC 18 | - Token Status List 19 | - Integration and updates with various Wallets and SDKs. 20 | - [Credo-ts](https://github.com/openwallet-foundation/credo-ts) 21 | - [Credhub](https://github.com/openwallet-foundation-labs/credhub) 22 | - [pex](https://github.com/Sphereon-Opensource/PEX) 23 | - [ssi-kit](https://github.com/Sphereon-Opensource/SSI-SDK) 24 | - [Veramo](https://github.com/decentralized-identity/veramo/pull/1358) 25 | - Provide a robust testing environment for the community. 26 | - Including this [test API server](https://github.com/lukasjhan/sd-jwt-test-api) into the project. 27 | - Participate LSPs and EWC Consortium with SD-JWT VC library. 28 | - 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. 29 | - [ewc-wallet-conformance-backend](https://github.com/EWC-consortium/ewc-wallet-conformance-backend) 30 | - [Credo-ts](https://github.com/openwallet-foundation/credo-ts) 31 | - [Credhub](https://github.com/openwallet-foundation-labs/credhub) 32 | - [pex](https://github.com/Sphereon-Opensource/PEX) 33 | - [ssi-kit](https://github.com/Sphereon-Opensource/SSI-SDK) 34 | - Demonstrate a substantial ongoing flow of commits and merged contributions. (2023-11-01 to 2024-10-16) 35 | - 12 [Contributors](https://github.com/openwallet-foundation-labs/sd-jwt-js/graphs/contributors) since project inception 36 | - [178 PRs merged](https://github.com/openwallet-foundation-labs/sd-jwt-js/pulls?q=is%3Apr+is%3Aclosed) 37 | - [Total 1.2M+ NPM Downloads](https://npm-stats-ecru.vercel.app/) 38 | - Demonstrate that the current level of community participation is sufficient to meet the goals outlined in the growth plan and roadmap. 39 | - Since these metrics can vary significantly depending on the type, scope and size of a project, the TAC has final judgment over the level of activity that is adequate to meet these criteria. 40 | - Demonstrates how this project differs from existing projects in the Growth and Impact stages. 41 | 42 | # Project Description 43 | 44 | This is the reference implementation of [IETF SD-JWT specification](https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/), [IETF SD-JWT VC specification](https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/) and [Token Status List](https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/) in Javascript/Typescript. 45 | 46 | Hopae, a founding member of OpenWallet Foundation, is building wallet module in Javascript/Typescript and need this project as a core component. 47 | 48 | # Alignment with the OpenWallet Foundation Mission 49 | 50 | This library is for the Selective Disclosure capability which is one of the important building blocks of digital identity wallets. 51 | 52 | # Code of Conduct 53 | 54 | [OpenWallet Foundation code of conduct](https://tac.openwallet.foundation/governance/code-of-conduct/) 55 | 56 | # TAC Sponsor 57 | 58 | - @aceshim Ace Shim 59 | - @skounis Stavros Kounis 60 | 61 | # Project License 62 | 63 | Apache 2.0 64 | 65 | # Source Control 66 | 67 | https://github.com/openwallet-foundation-labs/sd-jwt-js 68 | 69 | # Issue Tracker 70 | 71 | https://github.com/openwallet-foundation-labs/sd-jwt-js/issues 72 | 73 | # External Dependencies 74 | 75 | - js-base64 76 | 77 | # Release Methodology 78 | 79 | Project will be released on NPM. I have `@sd-jwt` organization on NPM for this project. Package name will be like `@sd-jwt/core`. 80 | 81 | # Initial Maintainers 82 | 83 | - Ace Shim ([Github](https://github.com/pensivej)) 84 | - Lukas Han ([Github](https://github.com/lukasjhan)) 85 | - Mirko Mollik ([Github](https://github.com/cre8)) 86 | - Brend ([Github](https://github.com/berendsliedrecht)) 87 | 88 | # Proposed Project Governance 89 | 90 | This will be maintained by Hopae, a founding member of OpenWallet Foundation. 91 | Ace, co-founder and CEO of Hopae, is leading the team. 92 | 93 | # Financial Sponsorship 94 | 95 | Not yet, but Hopae is willing to sponsor the project. 96 | 97 | # Infrastructure 98 | 99 | None 100 | -------------------------------------------------------------------------------- /projects/sd-jwt-kotlin.md: -------------------------------------------------------------------------------- 1 | # Project Name 2 | 3 | SD-JWT-Kotlin 4 | 5 | # Project Description 6 | 7 | A Kotlin implementation of the [Selective Disclosure for JWTs](https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-04.html) (SD-JWT) specification. 8 | 9 | # Alignment with the OpenWallet Foundation Mission 10 | 11 | This library implements the Selective Disclosure for JWTs specification, which is an important building block for future digital identity wallets. Since it is written in Kotlin, it can be used widely, e.g. in web backends or on Android. 12 | 13 | # Current Code of Conduct 14 | 15 | -- 16 | 17 | # TAC Sponsor 18 | 19 | - [Tracy Kuhrt](https://github.com/tkuhrt) 20 | 21 | # Project License 22 | 23 | Apache 2.0 24 | 25 | # Source Control 26 | 27 | [https://github.com/IDunion/SD-JWT-Kotlin](https://github.com/IDunion/SD-JWT-Kotlin) 28 | 29 | # Issue Tracker 30 | 31 | [https://github.com/IDunion/SD-JWT-Kotlin/issues](https://github.com/IDunion/SD-JWT-Kotlin/issues) 32 | 33 | # External Dependencies 34 | 35 | ```gradle 36 | // https://mvnrepository.com/artifact/com.nimbusds/nimbus-jose-jwt 37 | // License: Apache 2.0 38 | implementation("com.nimbusds:nimbus-jose-jwt:9.31") 39 | 40 | // https://mvnrepository.com/artifact/com.google.crypto.tink/tink 41 | // License: Apache 2.0 42 | implementation("com.google.crypto.tink:tink:1.9.0") 43 | 44 | // https://mvnrepository.com/artifact/org.jetbrains.kotlinx/kotlinx-serialization-json 45 | // License: Apache 2.0 46 | implementation("org.jetbrains.kotlinx:kotlinx-serialization-json:1.5.0") 47 | 48 | // https://mvnrepository.com/artifact/org.json/json 49 | // License: Public 50 | implementation("org.json:json:20230227") 51 | ``` 52 | 53 | # Release Methodology 54 | 55 | The project is released on Maven Central and snapshots can be found [here](https://s01.oss.sonatype.org/content/repositories/snapshots/org/sd-jwt/sd-jwt-kotlin/). 56 | 57 | # Initial Maintainers 58 | 59 | Fabian Hauck ([Github](https://github.com/fabian-hk)) 60 | 61 | # Proposed Project Governance 62 | 63 | -- 64 | 65 | # Links to Documented Governance Practices 66 | 67 | -- 68 | 69 | # Preferred Maturity Level 70 | 71 | Labs 72 | 73 | # Communication Channels 74 | 75 | - Github Issues 76 | 77 | # Project Website 78 | 79 | [SD-JWT-Kotlin](https://github.com/IDunion/SD-JWT-Kotlin) 80 | 81 | # Social Media 82 | 83 | -- 84 | 85 | # Financial Sponsorship 86 | 87 | -- 88 | 89 | # Infrastructure 90 | 91 | -- 92 | -------------------------------------------------------------------------------- /projects/sd-jwt-python.md: -------------------------------------------------------------------------------- 1 | # Project Name 2 | 3 | SD-JWT Python Reference Implementation 4 | 5 | # Project Description 6 | 7 | This is the reference implementation of the [IETF SD-JWT specification](https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/) maintained by the editors of the specification together with other contributors. It is written in Python. 8 | 9 | So far, this implementation was maintained in the IETF SD-JWT draft repository and did not have an official status or license attached. The maintainers have taken initial steps to move this project to a separate repository with proper licensing. 10 | 11 | # Alignment with the OpenWallet Foundation Mission 12 | 13 | This library implements the Selective Disclosure for JWTs specification, which is an important building block for future digital identity wallets. 14 | 15 | # Current Code of Conduct 16 | 17 | none 18 | 19 | # TAC Sponsor 20 | 21 | -- 22 | 23 | # Project License 24 | 25 | Apache 2.0 26 | 27 | # Source Control 28 | 29 | [https://github.com/danielfett/sd-jwt](https://github.com/danielfett/sd-jwt) 30 | 31 | # Issue Tracker 32 | 33 | [https://github.com/danielfett/sd-jwt/issues](https://github.com/danielfett/sd-jwt/issues) 34 | 35 | # External Dependencies 36 | 37 | ``` 38 | Python dependencies: 39 | 40 | python = "^3.8" 41 | jwcrypto = ">=1.3.1" 42 | pyyaml = ">=5.4" 43 | ``` 44 | 45 | # Release Methodology 46 | 47 | To be defined. 48 | 49 | # Initial Maintainers 50 | 51 | Daniel Fett ([Github](https://github.com/danielfett)) 52 | 53 | # Proposed Project Governance 54 | 55 | -- 56 | 57 | # Links to Documented Governance Practices 58 | 59 | -- 60 | 61 | # Preferred Maturity Level 62 | 63 | Labs 64 | 65 | # Communication Channels 66 | 67 | - Github Issues 68 | 69 | # Project Website 70 | 71 | [https://github.com/danielfett/sd-jwt](https://github.com/danielfett/sd-jwt) 72 | 73 | # Social Media 74 | 75 | -- 76 | 77 | # Financial Sponsorship 78 | 79 | -- 80 | 81 | # Infrastructure 82 | 83 | -- 84 | -------------------------------------------------------------------------------- /projects/sd-jwt-rs.md: -------------------------------------------------------------------------------- 1 | # Project Name 2 | 3 | SD-JWT Rust Reference Implementation 4 | 5 | # Project Description 6 | 7 | This is the reference implementation of the [IETF SD-JWT specification](https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/) written in Rust. 8 | 9 | Note: while the project is started as a reference implementation, it is intended to be evolved to a prodaction-ready, high-performance implementations in the long-run. 10 | 11 | # Alignment with the OpenWallet Foundation Mission 12 | 13 | This library implements the Selective Disclosure for JWTs specification, which is an important building block for future digital identity wallets. 14 | Rust basis may be used as a source for high-performance wallets as well as a universal starting point for native platform-specific implementation for both mobile and desktop. 15 | 16 | # Code of Conduct 17 | 18 | [OpenWallet Foundation code of conduct](https://tac.openwallet.foundation/governance/code-of-conduct/) 19 | 20 | # TAC Sponsor 21 | 22 | To be defined. 23 | 24 | # Project License 25 | 26 | Apache 2.0 27 | 28 | # Source Control 29 | 30 | To be defined. 31 | Please note: this is a brand-new source code. The DSR team is working on the initial implementation and may append this section to the nearest feature. 32 | 33 | # Issue Tracker 34 | 35 | GitHub Issues. 36 | 37 | # External Dependencies 38 | 39 | Dual license (MIT/Apache 2.0) dependencies: 40 | - [base64](https://crates.io/crates/base64) 41 | - [log](https://crates.io/crates/log) 42 | - [serde_json](https://crates.io/crates/serde_json) 43 | - [sha2](https://crates.io/crates/sha2) 44 | - [rand](https://crates.io/crates/rand) 45 | - [hmac](https://crates.io/crates/hmac) 46 | 47 | MIT license dependencies: 48 | - [jsonwebtoken](https://crates.io/crates/jsonwebtoken) 49 | 50 | Note: the list of dependencies may be changed in the future. 51 | 52 | # Release Methodology 53 | 54 | To be defined. 55 | 56 | # Initial Maintainers 57 | 58 | - Sergey Minaev ([Github](https://github.com/jovfer)) 59 | - DSR Corporation Decentralized Systems Team ([Github](https://github.com/orgs/DSRCorporation/teams/decentralized-systems) 60 | 61 | # Proposed Project Governance 62 | 63 | -- 64 | 65 | # Links to Documented Governance Practices 66 | 67 | -- 68 | 69 | # Preferred Maturity Level 70 | 71 | Labs 72 | 73 | # Communication Channels 74 | 75 | - Github Issues 76 | - Discord channel (https://discord.gg/openwalletfoundation - `#sd-jwt-rust` channel) 77 | 78 | # Project Website 79 | 80 | To be defined. 81 | 82 | # Social Media 83 | 84 | -- 85 | 86 | # Financial Sponsorship 87 | 88 | DSR Corporation, LLC. Denver, Colorado. 89 | DSR Decentralized Systems Team has extensive experience in the development of decentralized systems and digital identity solutions, and we are fun of Rust. 90 | In our previous experience, we developed a Rust-based multiplatform SDK for the Hyperledger Indy project, which later evolved into the Aries initiative. 91 | The DSR team is also one of the initial authors of Rust-based CL Anoncreds implementation as part of Hyperledger Ursa and Indy. CL Anoncreds is one of the alternative approaches for verifiable credentials with selective disclosure support. 92 | 93 | # Infrastructure 94 | 95 | GitHub Actions for CI/CD. 96 | -------------------------------------------------------------------------------- /projects/sd-jwt-vcdm.md: -------------------------------------------------------------------------------- 1 | # Project Name 2 | 3 | sd-jwt-vc-dm 4 | 5 | # Preferred Maturity Level 6 | 7 | Labs 8 | 9 | # Project Description 10 | 11 | This project aims to provide a reference implementation of the [SD-JWT VC DM](https://github.com/danielfett/sd-jwt-vc-dm) (Selective Disclosure JWT Verifiable Credentials Data Model) specification in TypeScript/JavaScript. SD-JWT VC DM combines the best features of SD-JWT VC and W3C VCDM, offering: 12 | 13 | - Selective disclosure capabilities with compact payloads 14 | - Support for schemas and vocabularies 15 | - Compatibility with JSON-LD payloads 16 | - Alignment with JAdES signature standards 17 | - Support for various credential types (Simple credentials, PID, ELM, etc.) 18 | 19 | Key features of this implementation: 20 | 21 | - Platform-agnostic implementation (works in Node.js, browsers, React Native) 22 | - Modular architecture separating core functionality from platform-specific features 23 | - Pluggable cryptographic interface ("bring your own crypto") 24 | - Support for both compact and JSON serialization formats 25 | - Implementation of all SD-JWT VC DM features including type metadata, schemas, and JAdES signatures 26 | - Comprehensive test suite covering all specification requirements 27 | 28 | # Alignment with the OpenWallet Foundation Mission 29 | 30 | SD-JWT VC DM is positioned as a crucial credential format that bridges existing standards (SD-JWT VC and W3C VCDM) while adding essential features for real-world deployments. This implementation will help accelerate the adoption of interoperable digital credentials by providing: 31 | 32 | - A reference implementation that other projects can learn from 33 | - A production-ready library that wallet developers can directly use 34 | - A test suite that helps ensure specification compliance 35 | 36 | # Code of Conduct 37 | 38 | [OpenWallet Foundation code of conduct](https://tac.openwallet.foundation/governance/code-of-conduct/) 39 | 40 | # TAC Sponsor 41 | 42 | @aceshim Ace Shim 43 | 44 | # Project License 45 | 46 | Apache 2.0 47 | 48 | # Source Control 49 | 50 | https://github.com/openwallet-foundation/sd-jwt-vc-dm 51 | 52 | # Issue Tracker 53 | 54 | https://github.com/openwallet-foundation/sd-jwt-vc-dm/issues 55 | 56 | # External Dependencies 57 | 58 | TBD 59 | 60 | # Release Methodology 61 | 62 | TBD. hopefully will be released on NPM under OWF NPM organization 63 | 64 | # Initial Maintainers 65 | 66 | - Lukas Han (Hopae) - [Github](https://github.com/lukasjhan) 67 | - Kai Ootsuki(NTT Digital) - [Github](https://github.com/Dtitkaio) 68 | - Takashi YAMAMOTO (NTT Digital) - [Github](https://github.com/Takashiyamam) 69 | 70 | # Proposed Project Governance 71 | 72 | The project will follow a shared governance model between Hopae and NTT. All significant changes will require review from both organizations. The project welcomes contributions from the community through GitHub pull requests and issues. 73 | 74 | # Links to Documented Governance Practices 75 | 76 | # Financial Sponsorship 77 | 78 | - Hopae 79 | - NTT 80 | 81 | # Infrastructure 82 | 83 | - GitHub repository 84 | - NPM organization 85 | - CI/CD pipeline (GitHub Actions) 86 | -------------------------------------------------------------------------------- /projects/solid-data-wallet.md: -------------------------------------------------------------------------------- 1 | # Project Name 2 | 3 | Solid Data Wallet 4 | 5 | Proposed repository name `solid-data-wallet`. 6 | 7 | [Solid is an open standard for structuring data, digital identities, and applications on the Web](https://solidproject.org/about). The Solid standards are developed at W3C by the [Solid Community Group](https://www.w3.org/community/solid/). The Solid Project is a community of volunteers formed by Tim Berners-Lee to complement the standardization efforts at W3C, such as publishing [technical reports](https://solidproject.org/TR/), manage [github repositories](https://github.com/solid), a forum, events calendar, and so forth. It is however not an incorporated legal entity. As such the Solid term is not trademarked by the solid project, nor are we aware of any attempts of any entity to register the Solid trademark (in this context). 8 | 9 | The `solid-` prefix for the project is intended to be descriptive of the intention behind and the functionality of the wallet project; it reflects the project roots, it is not a brand. 10 | 11 | The project is currently open source and hosted on [github](https://github.com/inrupt/inrupt-data-wallet) by Inrupt. 12 | 13 | 14 | # Preferred Maturity Level 15 | 16 | The project is based on production ready technologies with significant adoption. Due to the wallet project being in early stage though, we would suggest it being adopted by [Labs](https://tac.openwallet.foundation/governance/project-lifecycle/#labs). 17 | 18 | # Project Description 19 | 20 | The proposed project is a [React Native](https://reactnative.dev/) and [Expo](https://expo.dev/) based mobile data wallet implementation. 21 | 22 | The project was initially developed by [Inrupt](https://www.inrupt.com/solutions/data-wallet), part of an effort to build a [Solid](https://solidproject.org/) backed wallet infrastructure so that *"organizations deliver innovative apps, products, and experiences \[...] powered by flexible, secure, and user-centric data sharing"*. 23 | 24 | The timing is also important, as Solid moved to the final stage of standardization at W3C, with the creation of the [Linked Web Storage](https://www.w3.org/groups/wg/lws/) workgroup. In addition to that, Inrupt decided to open source the wallet technology and make it available to a larger audience. 25 | 26 | # Alignment with the OpenWallet Foundation Mission 27 | [OpenWallet Foundation mission](https://tac.openwallet.foundation/governance/charter/) emphasizes three core elements: 28 | * *"develop and maintain open source code for wallets to enable and ensure wallet interoperability,"* - The project is very well aligned with this principle and, arguably, goes a step further in that it promotes a larger scoped data interoperability, via the Solid set of specifications. The wallet code proposed is, as expected, open sourced under the permissive ALv2 license. 29 | * *"advocate for the adoption of the interoperable digital wallet technology, \[...]"* - Inrupt, the company that originally developed the wallet is already strongly advocating for data interoperability. The Solid specs where initially imagined by Inrupt's CTO, Sir Tim Berners-Lee with the intent of extending *"the web to include identity management, access control and universal standards for data. These capabilities decouple data from applications so that data is organized around individuals."* 30 | * *"collaborate with Standards Development Organizations (SDOs) in the development and proliferation of open standards related to digital wallets"* - Inrupt will continue to be active in the definition of standards at W3C, as well as development and promotion of the wallet technologies backed by Solid and related specs, such as DID, verifiable credentials, and others. 31 | 32 | # Code of Conduct 33 | 34 | [OpenWallet Foundation code of conduct](https://tac.openwallet.foundation/governance/code-of-conduct/). 35 | 36 | # TAC Sponsor 37 | TBD 38 | 39 | # Project License 40 | [ALv2](https://www.apache.org/licenses/LICENSE-2.0) - SPDX:Apache-2.0 41 | 42 | # Source Control 43 | 44 | The project is currently open source and hosted on [github](https://github.com/inrupt/inrupt-data-wallet) by Inrupt. 45 | 46 | # Issue Tracker 47 | 48 | [OpenWallet Foundation Labs](https://github.com/openwallet-foundation-labs) 49 | 50 | # External Dependencies 51 | 52 | React Native Typescript project. Code dependencies explicitly defined in the project. 53 | 54 | There is a dependency on Solid based storage for data. There are a few open source and commercial [implementations of Solid](https://solidproject.org/for-developers#hosted-pod-services) servers available. Inrupt also provides a [Solid hosting service](https://start.ap.inrupt.com/profile) free for non-commercial purposes. 55 | 56 | # Release Methodology 57 | 58 | The project builds cross-platform mobile application wallets for both iOS and Android. Maintainers will issue official releases at regular times, but there is no intent (both from Inrupt and the project) to release the apps on the Play or App Store(s). The project is white-labeled so that adopters could add their branding and enhancements as desired before publishing to app stores. 59 | 60 | # Initial Maintainers 61 | 62 | * [Kyra Assaad](https://github.com/KyraAssaad) 63 | * [Pete Edwards](https://github.com/edwardsph) 64 | * [Seila Gonzales-Estrecha](https://github.com/seilagonzalez) 65 | * [Nicolas Seydoux](https://github.com/NSeydoux) 66 | * [Hadrian Zbarcea](https://github.com/hzbarcea) 67 | 68 | # Proposed Project Governance 69 | 70 | Everyone is encouraged to contribute to the project. Contributors will be able to open issues via Github, submit patches and discuss their ideas. We encourage everyone interested in adopting the technology to share use-cases and requirements. 71 | 72 | # Financial Sponsorship 73 | 74 | * [Inrupt](https://www.inrupt.com/about) 75 | 76 | # Infrastructure 77 | 78 | Inrupt already provides the required project infrastructure. That said, we aim to align with processes used by other OWF projects and use available 79 | [services for labs](https://tac.openwallet.foundation/governance/project-and-lab-services/) as much as possible without adding a significant burden to the OWF staff. 80 | 81 | -------------------------------------------------------------------------------- /projects/trs.md: -------------------------------------------------------------------------------- 1 | # Project Name 2 | 3 | TRS (Trust Resolver System) 4 | 5 | # Preferred Maturity Level 6 | 7 | Labs 8 | 9 | # Project Description 10 | 11 | Currently, there are many trust protocols such as "OpenID federation", "X.509 certificate", "EBSI Trust Chains" and so on. Due to the complexity of these protocols, it is not easy to implement a trust resolver system in client side. That's why Trust Registry Query Protocol(TRQP): https://trustoverip.github.io/tswg-trust-registry-protocol is created. 12 | 13 | In this project, we aim to implement a Typescript reference implementation of the TRQP. and extends it so that people can obtain trust information even without detailed knowledge of the standards. My goal is to build an infrastructure like the one described below. 14 | 15 | ``` 16 | +-------------+ 17 | | | 18 | | root server | 19 | | | 20 | | | 21 | +-------------+ 22 | ↑ | 23 | (not standardized) | | 24 | who can process my | | 25 | query? | | 26 | | ↓ 27 | +-------------+ Query +---------------+ Query +--------------+ 28 | | | (TRQP) | | (TRQP) | | 29 | | client |------------------>| trust resolver|--------------->|trust registry| 30 | | | | | | | 31 | +-------------+ +---------------+ +--------------+ 32 | ``` 33 | 34 | # Alignment with the OpenWallet Foundation Mission 35 | 36 | The Trust System is also a crucial component with the Issuer, Holder and Verifier. Trust System makes sure not only the credential is valid but also the issuers, wallet instances and relying parties are trusted. 37 | 38 | # Code of Conduct 39 | 40 | [OpenWallet Foundation code of conduct](https://tac.openwallet.foundation/governance/code-of-conduct/) 41 | 42 | # TAC Sponsor 43 | 44 | @aceshim Ace Shim 45 | 46 | # Project License 47 | 48 | Apache 2.0 49 | 50 | # Source Control 51 | 52 | github 53 | 54 | # Issue Tracker 55 | 56 | github 57 | 58 | # External Dependencies 59 | 60 | TBD 61 | 62 | # Release Methodology 63 | 64 | TBD 65 | 66 | # Initial Maintainers 67 | 68 | - Lukas Han ([Github](https://github.com/lukasjhan)) - Hopae Inc. 69 | - Seohee Park ([Github](https://github.com/dvlprsh)) - Hopae Inc. 70 | 71 | # Proposed Project Governance 72 | 73 | Everyone should be able to contribute to the project. Contributors will be able to open issues via Github to discuss their ideas. 74 | 75 | # Financial Sponsorship 76 | 77 | None 78 | 79 | # Infrastructure 80 | 81 | Planning to deploy 2 servers for this project. 1 main, 1 backup, just like DNS resolver server. 82 | 83 | Clients can access via ip address. 84 | -------------------------------------------------------------------------------- /projects/tuvali.md: -------------------------------------------------------------------------------- 1 | # Project Name 2 | Tuvali - Means a tunnel in [Tamil](https://en.wikipedia.org/wiki/Tamil_language) 3 | 4 | # Preferred Maturity Level 5 | Lab 6 | 7 | # Project Description 8 | This library contains the implementation for Android & IOS for the Openid4BLE specification. It's written in Kotlin & Swift. 9 | 10 | # Alignment with the OpenWallet Foundation Mission 11 | This library implements the BLE-based local transfer of Verifiable Presentation (VP). An offline-based mode provides us with the ability to present a VP in many crises and crowded situations, from stadium entries to social benefits in remote areas. This is an important building block for future digital identity wallets to be inclusive. Since it is written in Kotlin & Swift, it can be used widely. 12 | 13 | # Code of Conduct 14 | [Code of Conduct](https://docs.mosip.io/1.2.0/community/code-of-conduct) 15 | 16 | We will also follow the LF Code of Conduct 17 | 18 | # TAC Sponsor 19 | No one Now 20 | 21 | # Project License 22 | Currently, the project is hosted with MIT license. We will move to Apache license 2.0 upon approval of the project. 23 | 24 | # Source Control 25 | [Repository](https://github.com/mosip/tuvali) 26 | 27 | # Issue Tracker 28 | [Jira](https://mosip.atlassian.net/issues/?jql=labels%20%3D%20%22BLE%22) 29 | 30 | # External Dependencies 31 | 32 | ## Gradle dependencies 33 | 34 | | Dependency | Version | License | 35 | |:---------------------------------------------:|:--------------------:|:----------------------------------------------------------:| 36 | | com.facebook.react:react-native | not specific version | MIT | 37 | | org.jetbrains.kotlin:kotlin-stdlib | 1.7.0 | Apache-2.0 | 38 | | org.jetbrains.kotlinx:kotlinx-coroutines-core | 1.3.2 | Apache-2.0 | 39 | | org.bouncycastle:bcpkix-jdk15to18 | 1.68 | [MIT](https://www.bouncycastle.org/about/license/) | 40 | | org.bouncycastle:bcprov-jdk15to18 | 1.68 | [MIT](https://www.bouncycastle.org/about/license/) | 41 | | com.github.snksoft:crc | 1.1.0 | [BSD License](https://opensource.org/license/BSD-3-Clause) | 42 | | org.jetbrains.kotlin:kotlin-reflect | 1.7.0 | Apache-2.0 | 43 | 44 | 45 | ## npm dependencies 46 | 47 | | Dependency | Version | License | 48 | |:-------------------------------------:|:--------:|:----------:| 49 | | @arkweid/lefthook | ^0.7.7 | MIT | 50 | | @commitlint/config-conventional | ^17.0.2 | MIT | 51 | | @react-native-community/eslint-config | ^3.0.2 | MIT | 52 | | @release-it/conventional-changelog | ^5.0.0 | MIT | 53 | | @types/jest | ^28.1.2 | MIT | 54 | | @types/react | ~17.0.21 | MIT | 55 | | @types/react-native | 0.70.0 | MIT | 56 | | commitlint | ^17.0.2 | MIT | 57 | | del-cli | ^5.0.0 | MIT | 58 | | eslint | ^8.4.1 | MIT | 59 | | eslint-config-prettier | ^8.5.0 | MIT | 60 | | eslint-plugin-prettier | ^4.0.0 | MIT | 61 | | jest | ^28.1.1 | MIT | 62 | | pod-install | ^0.1.0 | MIT | 63 | | prettier | ^2.0.5 | MIT | 64 | | react | 18.1.0 | MIT | 65 | | react-native | 0.70.6 | MIT | 66 | | react-native-builder-bob | ^0.20.0 | MIT | 67 | | release-it | ^15.0.0 | MIT | 68 | | typescript | ^4.5.2" | Apache-2.0 | 69 | 70 | 71 | # Release Methodology 72 | [Release Process](https://docs.mosip.io/1.2.0/community/release-process) 73 | 74 | # Initial Maintainers 75 | [Maintainers](https://github.com/mosip/tuvali/blob/master/MAINTAINERS.md) 76 | 77 | # Proposed Project Governance 78 | [Governance Under MOSIP](https://docs.mosip.io/inji/inji-mobile-wallet/project-governance) 79 | 80 | # Links to Documented Governance Practices 81 | https://docs.mosip.io/inji/inji-mobile-wallet/project-governance 82 | 83 | # Financial Sponsorship 84 | [MOSIP](https://www.mosip.io/) 85 | 86 | # Infrastructure 87 | Infrastructure applicable for Lab maturity level -------------------------------------------------------------------------------- /projects/vc-api-implementation.md: -------------------------------------------------------------------------------- 1 | # Project Name 2 | 3 | VC API Implementation 4 | 5 | # Project Description 6 | 7 | The VC API is specification for a set of APIs for VC lifecycle management (https://w3c-ccg.github.io/vc-api/). This includes operations such as credential issuance, verification and exchange. It is a W3C CCG work item and, as of the submission of this proposal, it is in “draft community report” status. 8 | 9 | The VC API’s design is informed by use cases across a range of domains. Several of these use cases are collected in a working group note (https://w3c-ccg.github.io/vc-api-use-cases/). 10 | 11 | This project is an implementation of the VC API. The implementation aims to enable organizations and individuals to effortlessly conduct SSI operations over HTTP without requiring technical expertise, making it seamless to integrate into existing projects. 12 | 13 | This implementation does not yet implement all of the methods of VC API. 14 | The list of API methods which are implemented is in a table in the [application README](https://github.com/energywebfoundation/ssi/tree/develop/apps/vc-api#implemented-endpoints). 15 | 16 | Easy to adapt new feature requirements and changes since the implementation is generic (can be used for different use-cases, energy use case is one of them). 17 | 18 | The VC API specification was presented to the [OpenWallet Foundation Architecture Special Interest Group during the 2023-04-24 meeting](https://github.com/openwallet-foundation/architecture-sig/wiki/2023-04-24-Meeting-Minutes). This project was used during the demonstration portion of the presentation. 19 | 20 | ## Project Motivation and History 21 | 22 | This project was initiated in late 2021 and has been developed by the Energy Web Foundation (EWF) and the Elia Group. 23 | 24 | The Energy Web Foundation is a non-profit whose mission is to accelerate the energy transition by developing and deploying open-source Web3 technologies that help companies unlock business value from clean and distributed energy resources. 25 | 26 | The Elia Group (https://www.eliagroup.eu/) is an electricity grid transmission system operator operating in Belgium and the north and east of Germany. An important piece of Elia’s mission is to make the energy transition happen to decarbonise Europe by delivering the needed power infrastructure and shaping the European markets. The Elia Group believes that digital transformation is a reality of the changing energy landscape. 27 | 28 | The project was initiated because Energy Web and Elia see a requirement for an API that can be used in the energy sector to issue and verify credentials. Energy Web and Elia believe that an HTTP API lowers the technical barrier to entry for use of SSI, which is important given that organizations which can benefit from SSI often do not have large technical teams dedicated to digital identity. 29 | 30 | Energy Web and Elia chose to implement the VC API specification for the following reasons: 31 | 32 | - An API specification reduces vendor lock-in for consumers choosing to consume the API 33 | - The VC API specification is developed in an open process 34 | - The VC API specification prioritizes the relevant design goals of modularity, simplicity, composability and extensibility (https://w3c-ccg.github.io/vc-api/#design-goals-and-rationale) 35 | 36 | The API has been used by Energy Web and Elia for demonstration projects such as the Rebeam project, in which verifiable credentials were exchanged to authorize electric vehicle charging. Elia’s summary page for Rebeam is available here: https://innovation.eliagroup.eu/en/projects/rebeam. 37 | 38 | Though the project was initiated and is currently being driven by organizations in the energy domain, the implementation is generic and usable across a range of domains. 39 | 40 | ## Technical information 41 | 42 | The following section describes technical details of the project. *Please note that Elia and Energy Web have some development resources available to make technical changes to the project in order to enable its adoption by the OWF.* 43 | 44 | ### Technology selections 45 | 46 | | Technology | Selection | Selection Rationale | 47 | |----------------------|------------|----------------| 48 | | Programming language | Typescript | - Energy Web’s primary development language
- Among the most popular programming languages, according to Stack Overflow surveys (https://survey.stackoverflow.co/2023/#most-popular-technologies-language-prof)
- Widely used in SSI ecosystem | 49 | | API framework | Nest.js (https://nestjs.com/) | - Energy Web’s primary web API development framework | 50 | | Persistence layer | In-memory SQLite | - Ease of setup and development
- [A pull request](https://github.com/energywebfoundation/ssi/pull/158) is available which could add support for PostgreSQL | 51 | | Library: credential signatures | DIDKit (https://www.spruceid.dev/didkit) | - Support for many DID methods
- Support for both Data Integrity and JOSE VCs (allowing for future JOSE support for this project)
- Packaged as libraries for several programming languages, providing future technical agility | 52 | 53 | ### Implementation details 54 | 55 | #### Key Management 56 | 57 | A VC API implementation which provides the Verifiable Credential issuance (https://w3c-ccg.github.io/vc-api/#issue-credential) or Verifiable Presentation proving (https://w3c-ccg.github.io/vc-api/#prove-presentation) endpoints must have access to private keys (or key services which utilize private keys) in order to create the proofs. However, the API between VC API and a key service is currently out of scope of the VC API specification. 58 | 59 | The project has integrated key material by having a dedicated key module which has HTTP endpoints for the creation, import and export of key material. A tutorial covering key export and import is available here: https://github.com/energywebfoundation/ssi/blob/develop/apps/vc-api/docs/tutorials/key-export-import-tutorial.md. 60 | 61 | #### Exchange configuration 62 | 63 | A feature of the VC API specification is support for credential exchanges. This refers to the movement of Verifiable Credentials between actors defined in the Verifiable Credentials Data Model (Issuers, Holders & Verifiers). 64 | 65 | The project has defined a concept of Exchange Definitions in order to specify the configuration of an exchange. Exchange Definitions are documented here: https://github.com/energywebfoundation/ssi/blob/develop/apps/vc-api/docs/exchanges.md#exchange-definitions. The Exchange Definition data model and API endpoints are currently not included in the VC API specification, as noted in this table: https://github.com/energywebfoundation/ssi/tree/develop/apps/vc-api#standard-vs-custom-endpoints. 66 | 67 | However, recent discussions in the VC API working group suggest that APIs for the configuration of exchanges may be included in the specification. An example of these discussions is recorded in this GitHub Issues comment from the 2023-08-08 teleconference: https://github.com/w3c-ccg/vc-api/issues/285#issuecomment-1670228974 68 | 69 | #### Automated Testing 70 | 71 | The project is tested by the two automated test suites which have been developed by the W3C CCG for testing credential issuance (https://github.com/w3c-ccg/vc-api-issuer-test-suite) and credential verification (https://github.com/w3c-ccg/vc-api-verifier-test-suite). The project will strive to pass additional test suites as they become available. 72 | 73 | These test suites help demonstrate the potential of clients of the API to interoperate with other VC API implementations. 74 | Further interoperability testing may be performed in the future as well as relevant opportunities arise. 75 | 76 | The project is also tested by unit tests and end-to-end tests. 77 | 78 | Integration tests are implemented based on Energy and Mobility use cases, which have historically come from Elia and BloXmove energy and mobility as use-case requirements respectively. 79 | 80 | #### Key, DID & Proof Types Supported 81 | 82 | The key curves, DID methods and proof types supported are summarized in the table below: 83 | 84 | | Key Curve | DID Method | Proof Type 85 | | --- | --- | --- 86 | | Ed25519 | did:key | Ed25519Signature2018 87 | | Secp256k1 | did:ethr | EcdsaSecp256k1Signature2019 88 | 89 | Further details on this can be found here in the project repository: 90 | 1. [Keys](https://github.com/energywebfoundation/ssi/tree/develop/apps/vc-api#supported-key-types) 91 | 2. [DID Methods](https://github.com/energywebfoundation/ssi/tree/develop/apps/vc-api#supported-did-methods) 92 | 3. [Proof Types](https://github.com/energywebfoundation/ssi/tree/develop/apps/vc-api#supported-proof-types-for-proof-generation) 93 | 94 | Currently, an important constraint on the supported keys, DID methods and proof types is the use of DIDKit as the core library for credential operations. 95 | DIDKit's full list of supported did:methods and proof types is documented [here](https://www.spruceid.dev/didkit/didkit/did-methods). 96 | 97 | ### Documentation 98 | 99 | The project contains technical documentation and tutorials to facilitate understanding of the API and experiment with the implementation: https://github.com/energywebfoundation/ssi/tree/develop/apps/vc-api/docs/tutorials. 100 | All documentation and tutorials within the repository would be donated alongside the source code, as a part of this proposal. 101 | 102 | Furthermore, Energy Web has documentation on VC-API and general documentation on SSI available the Energy Web gitbook: 103 | 104 | - https://energy-web-foundation.gitbook.io/energy-web/foundational-concepts/self-sovereign-identity-introduction 105 | - https://energy-web-foundation.gitbook.io/energy-web/ew-dos-technology-components-2023/identity-and-access-management-iam/iam-guides/verifiable-credential-api 106 | 107 | This proposal does not include the migration of the gitbook documentation to the OWF, though this could be re-assessed if desired. 108 | If the OWF has a suitable documentation site, the gitbook content could be migrated there. 109 | 110 | # Alignment with the OpenWallet Foundation Mission 111 | 112 | The project team believes that the project is well aligned with the OpenWallet Foundation mission. 113 | 114 | An implementation of VC API developed and hosted by the OWF would advance the adoption of interoperable and privacy enhancing digital wallets. This is because VC API is an open specification of an interface for Verifiable Credential operations, which are relevant functions for digital wallets. 115 | Furthermore, as an HTTP API, the project is a technology well understood by many organizations and will plausibly accelerate their efforts to develop or integrate digital wallets. 116 | 117 | In addition, development of a VC API implementation would promote the development and proliferation of the VC API specification itself, which is an open standard related to digital wallets. 118 | 119 | The project has been open source since its inception and aims to be inclusive, in so far as it should be usable across a wide range of domains and infrastructure requirements. 120 | 121 | # Current Code of Conduct 122 | 123 | The current Code of Conduct of the project is [stored in the project repository](https://github.com/energywebfoundation/ssi/blob/develop/apps/vc-api/CODE_OF_CONDUCT.md) 124 | 125 | However, if the project is accepted by the OWF, the project would adopt the Linux Foundation Europe Code of Conduct. 126 | 127 | # TAC Sponsor 128 | 129 | The project has not yet identified a TAC sponsor. 130 | 131 | # Project License 132 | 133 | The project is current licensed under GNU General Public License 3.0 https://github.com/energywebfoundation/ssi/blob/develop/apps/vc-api/LICENSE 134 | 135 | However, if the proposal is accepted, the project will be re-licensed to Apache 2.0. 136 | 137 | # Source Control 138 | 139 | The project source code is at the following location: https://github.com/energywebfoundation/ssi/tree/develop/apps/vc-api 140 | 141 | The git repository containing the code is a monorepo which contains the applications and libraries in the tables below, in addition to the VC API implementation. *To enable the donation of the project to OWF, Energy Web and Elia are willing to refactor the project as required and have the development resources for doing so.* For example, the monorepo could be converted to a simple npm project, with the libraries subsumed in the VC API implementation and the “input-descriptor-to-credential" application separated into a new project and repository. 142 | 143 | ### Monorepo Libraries 144 | 145 | | Name | Location within the repo | Relevance to the project | 146 | |--------------------|------------|----------------| 147 | | @energyweb/ssi-did | [Repo link](https://github.com/energywebfoundation/ssi/tree/develop/libraries/did) | Imported as a dependency by VC API. Provides generation of DIDs from key pairs | 148 | | @energyweb/w3c-ccg-webkms | [Repo link](https://github.com/energywebfoundation/ssi/tree/develop/libraries/webkms) | Imported as a dependency by VC API. Provides interfaces conforming to the Web KMS specification (https://w3c-ccg.github.io/webkms) 149 | 150 | ### Monorepo Applications other than VC API 151 | 152 | | Name | Location within the repo | Relevance to the project | 153 | |--------------------|------------|----------------| 154 | | @energyweb/input-descriptor-to-credential | [Repo link](https://github.com/energywebfoundation/ssi/tree/develop/apps/input-descriptor-to-credential) | Independent from VC API. The app is an HTTP service to convert a Presentation Exchange input descriptor to a credential to be signed. 155 | 156 | # Issue Tracker 157 | 158 | https://github.com/energywebfoundation/ssi/issues 159 | 160 | # External Dependencies 161 | 162 | Key external dependencies are listed below. Not all dependencies are listed. 163 | 164 | | Dependency Repository | Importance to the project | License | 165 | |--------------------|------------|----------------| 166 | | https://github.com/spruceid/didkit | Provides credential signing and verification | Apache License 2.0 167 | | https://github.com/decentralized-identity/did-resolver | Resolves DID documents | Apache License 2.0 168 | | https://github.com/Sphereon-Opensource/PEX | Provides presentation exchange functionality | Apache License 2.0 169 | 170 | # Release Methodology 171 | 172 | The project contains a Dockerfile (https://github.com/energywebfoundation/ssi/blob/develop/apps/vc-api/Dockerfile) to build a container image for portable deployment. 173 | 174 | The project repository contains GitHub workflows for: 175 | 176 | Building and testing the repository’s libraries and applications 177 | 178 | Deploying the applications to Energy Web’s infrastructure via a “continuous deployment” workflow 179 | 180 | The project does not yet have a release methodology whereby the application is versioned and built into release artifacts. 181 | 182 | If the project were to be accepted and hosted by the OpenWallet Foundation, Energy Web’s deployment workflow would be removed from the repository hosted by the OpenWallet Foundation. 183 | 184 | # Initial Maintainers 185 | 186 | [John Henderson](https://github.com/jrhender) will be responsible for the initial maintainance of the repository. 187 | 188 | ## Planned contributors 189 | [Ashish Tripathi](https://github.com/nichonien) will contribute to the project but will not be responsible for maintenance. 190 | 191 | # Proposed Project Governance 192 | 193 | The project is currently governed by Energy Web and Elia. The project is not yet a community initiative, and no external feature requests or issues have been received. 194 | 195 | As the core of the project is a specification implementation, some of the project’s design choices will be directed by the specification. The project team has collaborated with the specification’s writer group to receive clarification and guide the specification’s development. The following GitHub issues are examples of this collaboration: 196 | 197 | - https://github.com/w3c-ccg/vc-api/issues/305 198 | - https://github.com/w3c-ccg/vc-api/issues/330 199 | - https://github.com/w3c-ccg/vc-api/issues/295 200 | 201 | In general, design and implementation decisions will be drafted and discussed using GitHub Issues prior to implementation. 202 | 203 | Regarding development prioritization, the following categorization is proposed: 204 | - High priority: If a feature or issue is essential for a specific use case and acts as a blocker. 205 | - Lower priority: If a feature or issue enhances the current user experience. 206 | For future requirements, the team recommends considering the use cases defined by the business group or TAC to prioritize development needs. 207 | 208 | *Elia and Energy Web are open to adopting governance practices as suggested by OWF.* 209 | 210 | # Links to Documented Governance Practices 211 | 212 | Contribution guidelines: https://github.com/energywebfoundation/ssi/blob/develop/contributing.md 213 | 214 | # Preferred Maturity Level 215 | 216 | The requested maturity level is “Labs”. 217 | 218 | Though the project team believes that the “Labs” stage is appropriate, the following points highlight early signs of project usefulness and maturity: 219 | 220 | - This implementation is being utilized by BloxMove proof of concepts to accomplish the next real-world Mobility use-cases. 221 | - Elia has integrated its wallet with the project, enabling users to leverage it for various energy use cases. 222 | - The project is accompanied by comprehensive technical documentation and tutorials, aimed at facilitating adoption. 223 | 224 | # Communication Channels 225 | 226 | GitHub Issues in the project's repository are enabled and publicly available. The project does not currently have any additional communication channels. 227 | 228 | # Project Website 229 | 230 | # Social Media 231 | 232 | Elia made a short video to introduce the concept of SSI to newcomers: https://eliagroup.sharepoint.com/:v:/s/InnovationTeam/EUfrphynLWlLsMhJ8mMkjboBxIHTyyoy3RqGalcdFGqn-g?e=JcYOLU 233 | 234 | # Financial Sponsorship 235 | 236 | Elia has funded the development of the project and is currently funding maintenance and minor feature development, in the context of initiatives which are ongoing through 2023. Furthermore, Elia has made funding available for any changes required for the project to be donated to the OWF. 237 | 238 | Beyond the context of the ongoing initiatives and donation of the project to OWF, Elia may provide future funding. Questions which Elia plans use to evaluate provision of future funding include: 239 | - Would the funding enable changes which better align the implementation to the VC API specification? 240 | - Would the funding enable changes which improve support of the implement for Elia’s use cases? 241 | 242 | # Infrastructure 243 | 244 | The following is requested as repository infrastructure: 245 | 246 | | Infrastructure Technology | Purpose | 247 | |---------------------------|----------| 248 | | GitHub Actions | Continuous integration and release workflows | 249 | 250 | The following is requested as release artifact infrastructure: 251 | 252 | | Infrastructure Technology | Purpose | 253 | |---------------------------|----------| 254 | | *no technology preference* | Public container image repository, such as ghcr.io | 255 | 256 | -------------------------------------------------------------------------------- /projects/vcx.md: -------------------------------------------------------------------------------- 1 | # Project Name 2 | 3 | VCX 4 | 5 | # Preferred Maturity Level 6 | 7 | Growth 8 | 9 | # Project Description 10 | 11 | VCX is an open-source codebase that provides a wide suite of Rust modules for building DID & Aries-related applications (client/mobile and server). VCX is designed with a heavily modularized structure (20+ crates in the workspace) such that consumers can pick-and-choose which components they wish to build their DI application with. Currently, some of the significant modules provided by VCX include: 12 | * `did_doc`, `did_parser`, `did_resolver` - a set of lightweight libraries which provide well-typed structures and interfaces for DID building, parsing, and resolving. We envision these components becoming defacto libraries for Rust projects involving DIDs. 13 | * DID Method Crates - several DID method-specific crates for resolving and managing DIDs (peer, cheqd, web, key, jwk, sov/unqualified). 14 | * `aries_vcx_ledger`, `aries_vcx_wallet`, `aries_vcx_anoncreds` - a set of libraries with interfaces for performing ledger, wallet, and anoncred operations involved in Aries protocols. Includes implementations for Indy & Cheqd ledgers (i.e. resolving anoncreds objects), Askar wallets, and anoncreds-rs. 15 | * `messages` - well-typed library for building and parsing Aries (DIDComm V1) messages 16 | * `aries_vcx` - Implementation of Aries protocol state machines, which provide APIs to step through Aries protocols, utilizing lots of the above-mentioned modules. Currently mostly for AIP1 protocols, but some AIP2 protocols such as DIDExchange/OOB. 17 | 18 | VCX has a long history, it has been around since 2017 and is one of the first implementations of an Aries protocol-compliant library, and was originally embedded in the Indy SDK. In 2020, the project was moved into a dedicated Hyperledger project by Absa Group, beginning a new era of development beyond the Indy SDK. Anonyome Labs joined the Hyperledger project in 2022 and the project has been maintained since. VCX has been actively involved in the Aries community, including fortnightly community meetings, and previous participation in Linux Foundation Mentorship programs. 19 | 20 | VCX has been used in industry projects, including mediator & cloud applications previously at Absa, and is a core component behind [Anonyome Lab's DI Edge Agent Mobile SDK](https://anonyome.com/resources/blog/aries-vcx-anonyomes-commitment-to-decentralized-identity/). Instnt is also building using VCX as a key component for their Multipass product. 21 | 22 | Coming from the Aries ecosystem, VCX has strived to implement protocols that are interoperable with the other Aries frameworks (Credo, ACA-Py). As part of this mission, VCX is apart of the [OWL test harness](https://github.com/openwallet-foundation/owl-agent-test-harness), where it is tested against other OWF Aries implementations. 23 | 24 | Given it's long history, VCX had previously grown in legacy code, however recent efforts have pushed VCX inline with modern DI. These efforts include complete replacement of Indy SDK components with indy-vdr, askar & anoncreds-rs, and moving away from unqualified DIDs/resources with alternatives such as Cheqd Anoncred methods. 25 | 26 | VCX aims to continue this trajectory. Some current future plans include: 27 | * VCX Framework (in development) - A credo-like framework solution for Rust-based Aries/DI consumers. 28 | * Mobile bindings - Provide Android/iOS mobile bindings to the library, allowing *native* (Kotlin/Swift) mobile applications to utilize VCX functionality. 29 | * More DID methods - continue growing the suite of DID method options, with modern methods such as did:webvh 30 | * DIDComm v2 support 31 | 32 | # Alignment with the OpenWallet Foundation Mission 33 | 34 | VCX supports the OWF's goals by providing an extensive suite of tools to assist in the creation of secure & interopable DI applications. 35 | * Secure Data Management: Whenever VCX manages data for the consumer, security is always the first consideration. VCX achieves secure data management via utilization of OWF's Askar project for cryptography and encrypted data storage. 36 | * Interoperability: As mentioned, VCX comes from an Aries ecosystem, where interoperability is at the forefront. VCX holds itself accountable to this by participating in efforts such as the OWF OWL test harness. 37 | * Open Source Development: VCX has always been community driven, and encourages participation with efforts such as fortnightly community calls and previous participation in the Linux Foundation Mentorship programs. 38 | * Support for Decentralized Identity: VCX's purpose is to provide tools that make it easier for consumers to develop DI applications. VCX has been proven to succeed in this, with testimonies in the industry (such as from [Anonyome Labs](https://anonyome.com/resources/blog/aries-vcx-anonyomes-commitment-to-decentralized-identity/)). 39 | 40 | # Code of Conduct 41 | 42 | VCX currently follows the [Hyperledger Code of Conduct](https://github.com/hyperledger/aries-vcx/blob/main/CODE_OF_CONDUCT.md), which is what the OWF code of conduct is based on. 43 | We are happy to directly adopt the [OpenWallet Foundation Code of Conduct](https://tac.openwallet.foundation/governance/code-of-conduct/) if desired. 44 | 45 | # TAC Sponsor 46 | 47 | * @swcurran Stephen Curran 48 | * @aceshim Jaehoon (Ace) Shim 49 | 50 | # Project License 51 | 52 | Apache 2.0 53 | 54 | # Source Control 55 | 56 | Project already exists on Github: https://github.com/hyperledger/aries-vcx . 57 | 58 | Ideally the new slug would be `vcx`. Dropping the Aries to reflect the capabilities beyond Aries protocols. 59 | 60 | # Issue Tracker 61 | 62 | https://github.com/hyperledger/aries-vcx/issues 63 | 64 | # External Dependencies 65 | 66 | The VCX dependency list is maintained in the [source repository](https://github.com/hyperledger/aries-vcx/blob/main/Cargo.toml). All are open source and we believe (but to be verified) that the majority use the Apache 2 License. 67 | 68 | # Release Methodology 69 | 70 | All proposed repositories have continuous deployment/delivery pipelines built using GitHub Actions. The individual packages follow the semantic versioning method, ensuring consistency and safety. 71 | 72 | VCX publishes release on on an as-needed basis, but releases tend to be made every 4-12 weeks (6 releases were published in 2024). 73 | 74 | TBD - VCX does not currently publish any crate releases to crates.io, but would like to in the future. VCX crates are currently "released" via github tags, which Rust consumers consume via github dependencies. 75 | 76 | # Initial Maintainers 77 | 78 | - George Mulhearn [@gmulhearn](https://github.com/gmulhearn) - Anonyome Labs 79 | - James Ebert - [@JamesKEbert](https://github.com/JamesKEbert) - Instnt 80 | - Luke Li - [@lukewli-anonyome](https://github.com/lukewli-anonyome) - Anonyome Labs 81 | 82 | # Proposed Project Governance 83 | 84 | The current governance model under Hyperledger is consensus-based. This means that decisions are made through discussions, with the aim of community consensus, as outlined in the Aries Project Charter. In cases where no clear consensus is established, a project Technical Steering Committee, or the maintainers (those with escalated GitHub privileges) are granted a louder voice. This approach has proven effective. 85 | 86 | # Financial Sponsorship 87 | 88 | Hyperledger has covered infrastructure related costs. 89 | 90 | # Infrastructure 91 | 92 | - Github repo 93 | - Discord channel 94 | - Github actions 95 | - Video conference (Zoom) 96 | - Published Artifacts — Cargo, Docker Images, Crates.io (future) 97 | -------------------------------------------------------------------------------- /projects/wallet-framework-dotnet.md: -------------------------------------------------------------------------------- 1 | # Project Name 2 | Wallet Framework .NET (wallet-framework-dotnet) 3 | 4 | # Project Description 5 | The wallet-framework-dotnet is a framework designed for .NET, focusing on providing a multi-platform wallet framework. Initially a part of the Hyperledger Aries project (Aries Framework .NET), this initiative has now branched out to cater to a broader audience. The primary aim is to create a multiprotocol wallet framework enabling implementations of OpenID4VC and SD-JWT VC, in accordance to the European Identity Wallet initiative's objectives. 6 | 7 | Currently, the framework supports DidComm v1 and AnonCreds. There is an active intention to extend support for other promising protocols, notably DidComm v2, to ensure the framework remains at the forefront of digital identity solutions. 8 | 9 | Furthermore, the team is considering the development of SD-JWT credentials as a standalone library. This might transition into a separate project proposal in the future, underscoring the commitment to modular and reusable components in the digital identity space. 10 | 11 | # Alignment with the OpenWallet Foundation Mission 12 | The wallet-framework-dotnet directly aligns with the OpenWallet Foundation mission by offering an open-source solution that will advance the state of digital identity wallets. The project's focus on implementing OpenID4VC in conjunction with the European Identity Wallet initiative underscores our commitment to global, interoperable standards, and enhances trust and security in digital identity systems. 13 | 14 | # Current Code of Conduct 15 | tbd 16 | 17 | # TAC Sponsor 18 | To be identified. 19 | 20 | # Project License 21 | Apache 2.0 22 | 23 | # Source Control 24 | To be established (Expected: https://github.com/openwallet-foundation/wallet-framework-dotnet) 25 | 26 | Suceeds Hyperledger Aries project: [aries-framework-dotnet](https://github.com/hyperledger/aries-framework-dotnet) 27 | 28 | # Issue Tracker 29 | GitHub Issues 30 | 31 | # External Dependencies 32 | - AnonCreds-RS 33 | - Indy-VDR 34 | - Aries-Askar 35 | 36 | # Release Methodology 37 | The project will be distributed as nuget package. 38 | 39 | # Initial Maintainers 40 | - Sebastian Bickerle [ntsbs](https://github.com/ntsbs) 41 | - Kevin Dinh [Dindexx](https://github.com/Dindexx) 42 | - Christopher Hempel [CHempel-esatus](https://github.com/CHempel-esatus) 43 | 44 | # Proposed Project Governance 45 | tbd 46 | 47 | # Links to Documented Governance Practices 48 | tbd 49 | 50 | # Preferred Maturity Level 51 | Labs 52 | 53 | # Communication Channels 54 | To be established. (Discord Channel in OWF) 55 | 56 | # Project Website 57 | GitHub project 58 | 59 | # Social Media 60 | 61 | 62 | # Financial Sponsorship 63 | 64 | 65 | # Infrastructure 66 | - Requires build and release pipeline for the Nuget package 67 | -------------------------------------------------------------------------------- /proposal-template.md: -------------------------------------------------------------------------------- 1 | # Project Name 2 | _Include the name of project being proposed._ 3 | 4 | # Preferred Maturity Level 5 | _Specify the stage that you want this project to enter. See [project lifecycle](https://tac.openwallet.foundation/governance/project-lifecycle/#stages) for information on the different stages._ 6 | 7 | # Project Description 8 | _Include a description of the project, including what it does, why it is valuable, the origin and history, and other information that will allow others to understand what the project will include. Architecture diagrams should be included if available._ 9 | 10 | # Alignment with the OpenWallet Foundation Mission 11 | _Include a statement on alignment with the [OpenWallet Foundation mission](https://tac.openwallet.foundation/governance/charter/)._ 12 | 13 | # Code of Conduct 14 | _Has this project adopted a Code of Conduct? If so, please include a link to it. If a current code of conduct is not adopted, will you adopt the [OpenWallet Foundation code of conduct](https://tac.openwallet.foundation/governance/code-of-conduct/)?_ 15 | 16 | # TAC Sponsor 17 | _Include the name of a sponsor from the TAC, if identified (a sponsor helps mentor projects)._ 18 | 19 | # Project License 20 | _Include the proposed project license. The OpenWallet Foundation will consider [OSI-approved](https://opensource.org/licenses/) permissive open source licenses and prefers Apache 2.0._ 21 | 22 | # Source Control 23 | _If the project already exists, please provide a link to the repositories. If no source exists, this is okay. Please state that this will be a completely new project with code beginning in the OpenWallet Foundation._ 24 | 25 | # Issue Tracker 26 | _OpenWallet Foundation expects that an issue tracker is open to anyone who would like to view, add, or fix issues. This information allows the TAC to better judge the state of the project maturity. If the project already exists, please provide a link to the issue tracker. If there is no issue tracker or you do not currently track issues, please answer with "N/A (not applicable)"._ 27 | 28 | # External Dependencies 29 | _If there are any external dependencies, please list those here including licenses._ 30 | 31 | # Release Methodology 32 | _If the project already exists, please provide details on the release methodology and mechanics. If there is not currently a release methodology, please answer with "N/A (not applicable)"._ 33 | 34 | # Initial Maintainers 35 | _Include the names of initial maintainers and their GitHub IDs._ 36 | 37 | # Proposed Project Governance 38 | _Briefly describe the project's leadership team and decision-making process._ 39 | 40 | # Financial Sponsorship 41 | _Include any existing financial sponsorship. If none, please state "None"._ 42 | 43 | # Infrastructure 44 | _Include any infrastructure needs or requests. OpenWallet Foundation provides a set of [services for projects and labs](https://tac.openwallet.foundation/governance/project-and-lab-services/). Please note which of these you will utilize and what else is required._ 45 | --------------------------------------------------------------------------------