This SIG is an open group. Anyone in the OpenWallet Foundation community can join and participate. There is no formal sign up process. Just show up and participate.
Credential Format Comparison Special Interest Group (SIG)¶
+
This SIG is dedicated to maintaining information about available credential formats for the benefit of OWF projects and the wider community. The topic is more complex than one might assume on first sight, since there are more than 14 formats for representing digital credentials and most of those formats can be combined with different signature algorithms, ways to represent cryptographic keys (with alone more than a hundred DID methods), status management methods, trust management methods and so on.
+
There is pre-existing work started at Internet Identity Workshop (IIW 34, Spring 2022) and extended and augmented during Rebooting the Web of Trust (RWOT-XI, The Hague, Sept 2022).
+
It consists of a “credential format comparison matrix”, containing information about the technical options in the different dimensions (formats, signature algorithms, …) as well as known credential profiles, i.e. concrete combinations used in implementations and an article explaining the “matrix”.
This SIG is an open group. Anyone in the OpenWallet Foundation community can join and participate. There is no formal sign up process. Just show up and participate.
Digital Wallet and Agent Overviews Special Interest Group (SIG)¶
+
The objectives of this SIG is to further develop and maintain the Digital Wallet Overview and making a similar overview for digital identity agents/SDKs. These overviews should provide transparency of the characteristics of wallets and agents in order to allow for comparison and effective decision making on which wallet is applicable for your use case. By creating awareness of these overviews, this work can lead to less fragmentation of the SSI playing field and increase adoption.
This SIG is an open group. Anyone in the OpenWallet Foundation community can join and participate. There is no formal sign up process. Just show up and participate.
A special interest group (SIG) under the Technical Advisory Council (TAC) is a group with a shared interest in advancing a specific area of knowledge, learning, or technology related to the mission of the OpenWallet Foundation where members cooperate to affect or to produce solutions within their particular field. Unlike a task force, SIGs are typically long running and may or may not produce any deliverables. A SIG can be created by anyone in the OpenWallet Foundation community and must be proposed to and approved by the TAC.
+
+
Tip
+
If you would like to propose a Special Interest Group, please see the SIG proposal process.
This SIG will create, distribute and promote a set of material that will become the de-facto way to determine how "safe" the new breed of digital wallets is, and be able to compare them effectively. This will increase the visibility of the solutions to correlation and profiling issues that could be introduced with digital wallet deployments.
This SIG is an open group. Anyone in the OpenWallet Foundation community can join and participate. There is no formal sign up process. Just show up and participate.
The Special Interest Groups (SIGs) must provide a quarterly update to the TAC to ensure that the SIG is still active and that there is still value in hosting the special interest group. The following calendar provides the timing for when these updates are required to be presented to the TAC:
A TAC voting member may designate an alternate for a specific meeting, and must notify the chair in advance of the meeting. The TAC voting member is responsible for ensuring that the named alternate has enough information to represent the TAC voting member in all matters that will be covered in the meeting. The named alternate will participate in any votes that occur during the meeting for which they were named an alternate, and their vote will count as if it were cast by the TAC voting member.
+
+
Warning
+
If a TAC voting member regularly names an alternate and
+
+
is a TAC Premier Sponsor Representative, then that TAC voting member should consider whether they should replace themselves with the alternate, or
+
is a TAC "At Large" Representative, then that TAC voting member should consider whether they should resign.
OpenWallet Foundation very much appreciates the contributions of the community; however, it is important to archive source repositories that have become inactive in order to ensure that others in the community are not using code or reporting issues on a repository that is not being maintained.
+
Any repository that has not had a release for 12 months or that has had no commits for 6 months may be archived.
+
Projects will be notified via a PR in the appropriate repository, as well as a notice in the project appropriate Discord channel and mailing list, if they exist.
+
Generally speaking if the project's maintainers request to keep the repository active, the request will be honored. However if the repository has a lot of out of date dependencies, particulaly ones relating to security vulnerabilites, this request may not be honored.
+
A request by the project's maintainers to un-archive a repository for the purposes of active contribution will be honored, unless the project is in an emeritus stage. In those cases the project lifecycle issues will need to be resolved first.
The purpose of the OpenWallet Foundation (the “OWF”) is to support various open source, open data and/or other open projects relating to or supporting development of digital wallets, including infrastructure and support initiatives related thereto (each such project, a “Technical Project”) , in accordance with the provisions of this Charter. The governance of each Technical Project is as set forth in the charter for that Technical Project.
+
The OWF aims to enable entities to transact securely, and in a privacy enhancing fashion, in- person and on-line where attributes stored in, and managed by, the wallet. The OWF will:
+
+
develop and maintain open source code for wallets to enable and ensure wallet interoperability,
+
advocate for the adoption of the interoperable digital wallet technology, and
+
collaborate with Standards Development Organizations (SDOs) in the development and proliferation of open standards related to digital wallets
+
+
The OWF will not publish a publicly available wallet (including into any application stores).
+
The OWF supports the Technical Projects. The OWF operates under the guidance of the Governing Board of the OWF (the “Governing Board”) and Linux Foundation Europe (the “LFEU”) as may be consistent with Linux Foundation Europe’s tax-exempt status.
+
The Governing Board manages the OWF. The Governing Board may establish other committees and other working groups (collectively, and including the Technical Advisory Council, “Committees”) which will report to the Governing Board.
+
+
+
Sponsorship.
+
+
The OWF will be composed of Premier, General and Associate Sponsors (each, a “Sponsor” and, collectively, the “Sponsors”) in Good Standing. All Sponsors must be current Sponsors of LFEU (at any level) to participate in the OWF as a Sponsor. All sponsors in the OWF, enjoy the privileges and undertake the obligations described in this Charter, as from time-to-time amended by the Governing Board, with the approval of LFEU. During the term of their sponsorship, all Participants will comply with all such policies as the LFEU Board of Directors and/or the OWF may adopt with notice to Sponsors.
+
Premier Sponsors will be entitled to appoint a representative to the Governing Board and any Committee.
+
General Sponsors, acting as a class, will be entitled to annually elect one representative to the Governing Board for every ten General Sponsors, up to a maximum of three total representatives, provided that there will always be at least one General Sponsor representative, even if there are less than ten General Sponsors. The Governing Board determines the General Sponsor representative election process.
+
The Associate Sponsor category of sponsorship is limited to Associate Sponsors of LFEU. The Governing Board may set additional criteria for sponsoring the OWF as an Associate Sponsor. If the Associate Sponsor is itself a membership or participation organization, Associate Sponsorship in the OWF does not confer any privileges or rights to the members or participants of the Associate Sponsor.
+
Sponsors will be entitled to:
+
participate in OWF general meetings, initiatives, events and any other activities; and
+
identify themselves as sponsors of the OWF supporting the OWF community.
+
+
+
+
+
+
Governing Board
+
+
+
The Governing Board voting members will consist of:
+
+
one representative appointed by each Premier Sponsor;
+
the TAC Representative (as defined below), or, in the absence of a chair and with the approval of the Governing Board, any active contributor to a Technical Project so designated by the TAC (such chair or designee the “TAC Representative”); and
+
the elected General Sponsor representative or representatives.
+
+
+
+
The Governing Board will also include nonvoting members consisting of the GAC Representative (defined in Section 4) and Associate Representative.
+
+
The Associate Representative will be chosen based on their efforts and potential to advance the OWF mission. The Associate Representative will be selected by the Governing Board voting representatives through a process determined by the Governing Board.
+
+
+
+
Only one Sponsor that is part of a group of Related Companies (as defined in Section 7) may appoint, or nominate for a sponsorship class election, a representative on the Governing Board. No single Sponsor, company or set of Related Companies will be entitled to: (i) appoint or nominate for sponsorship class election more than one representative for the Governing Board, or (ii) have more than two representatives on the Governing Board.
+
+
The only path to two representatives from the same group of Related Companies that will be acceptable will be for one Sponsor to appoint or nominate a representative to the Governing Board and have another of its employees, or an employee of one of its Related Companies, serve as the TAC Representative on the Governing Board.
+
+
+
+
Conduct of Meetings
+
+
Governing Board meetings will be limited to the Governing Board
+representatives, the Outreach Committee Chair, invited guests and OWF staff.
+
Governing Board meetings follow the requirements for quorum and voting outlined in this Charter. The Governing Board may decide whether to allow named representatives (one per Sponsor per Governing Board and per Committee) to attend as an alternate.
+
The Governing Board meetings will be private unless decided otherwise by the Governing Board. The Governing Board may invite guests to participate in consideration of specific Governing Board topics (but such guests may not participate in any vote on any matter before the Governing Board).
+
+
+
+
Officers
+
+
The officers (“Officers”) of the OWF as of the first meeting of the Governing Board will be a Chairperson (“Chair”) and a Treasurer. Additional Officer positions may be created by the Governing Board.
+
The Chair will preside over meetings of the Governing Board, manage any day-to-day operational decisions, and will submit minutes for Governing Board approval.
+
The Treasurer will assist in the preparation of budgets for Governing Board approval, monitor expenses against the budget and authorize expenditures approved in the budget.
+
+
+
+
The Governing Board will be responsible for overall oversight of the OWF, including:
+
+
approve a budget directing the use of funds raised by the OWF from all sources of sponsorship or other revenue, including to pay for the hiring of OWF leadership and staff;
+
vet and select a qualified leadership team to run the day-to-day management activities of the organization and evaluate the performance of the team;
+
provide feedback and input to the OWF leadership team responsible for planning and managing the day-to-day operation of the OWF;
+
maintain, if desired, a guiding principles document;
+
nominate and elect Officers of the OWF;
+
supervise and support the leadership team on OWF business and community outreach matters;
+
work with the LFEU on any legal matters that arise;
+
adopt and maintain policies or rules and procedures for the OWF (subject to LFEU’s approval);
+
establish advisory bodies, committees, programs or councils to resolve any particular matter or in support of the mission of the OWF and/or its Technical Projects including in support of end-users and ambassadors for the project any Technical Project;
+
establish any OWF conformance programs for its trademarks and solicit input (including testing tools) if deemed necessary from the applicable oversight body of any Technical Project for defining and administering any programs related to conformance with such Technical Project (each, a “Conformance Program”);
+
publish use cases, user stories, websites and priorities to help inform the ecosystem and technical community;
+
approve procedures for the nomination and election of any representative of the General Sponsors to the Governing Board and any Officer or other positions created by the Governing Board; and
+
vote on all decisions or matters coming before the Governing Board.
+
+
+
+
+
+
Government Advisory Council
+
+
The Government Advisory Council (the “GAC”) will provide the OWF advice from government entities approved to participate by the Governing Board. Members of the GAC must be national governments, multinational governmental organizations and treaty organizations, or public authorities. Each may appoint one representative and one alternate representative to the GAC. There are no fees to participate in the GAC.
+
The GAC will provide advice to OWF on issues of public policy, and especially where there may be an interaction between OWF's activities and national policies, laws or international agreements.
+
The Governing Board may appoint a chairperson of the GAC or delegate responsibility for selecting a chairperson to the GAC. The GAC chairperson or another person chosen by the GAC chairperson will serve as the “GAC Representative” responsible for reporting progress back to the Governing Board and interfacing with the TAC. The GAC Representative may attend meetings of the Governing Board and TAC as a non-voting member.
+
+
+
+
Technical Advisory Council
+
+
+
The role of the TAC is to facilitate communication and collaboration among the Technical Projects. The TAC will be responsible for:
+
+
maintaining an overall strategic vision for technical collaboration and coordinating collaboration among Technical Projects, including development of an overall technical vision for the community;
+
making recommendations to the Budget Committee of resource priorities for Technical Projects;
+
electing annually a chairperson to preside over meetings, set the agenda for meetings, ensure meeting minutes are taken and who will also serve on the Governing Board as the TAC’s representative (the “TAC Representative”);
+
creating, maintaining and amending project lifecycle procedures and processes, deciding where Technical Projects fall within that lifecycle;
+
determining when a technical project should be admitted as a Technical Project or any Technical Project should be considered a TAC Project; and
+
such other matters related to the technical role of the TAC as may be communicated to the TAC by the Governing Board.
+
+
+
+
The voting members of the TAC consist of:
+
+
one representative appointed by each Premier Sponsor;
+
up to two “at large” representatives appointed by vote of the TAC; and
+
one representative appointed by the technical oversight body (e.g., a technical steering committee) of each TAC Project (as defined herein).
+
+
+
+
TAC meetings are intended to be open to observe by Sponsors, contributors to any TAC Project and others in the general public interested in the OpenWallet Foundation. The TAC may decide whether to allow named representatives (one per voting member) to attend as an alternate.
+
+
At the start of the OWF, “TAC Projects” are those Technical Projects listed as having voting representatives on the TAC on the Directed Fund’s web site. Thereafter, any Technical Project can become a TAC Project through the approval of the Technical Project’s technical oversight body and the TAC (by a two-third’s vote). The TAC may approve and modify a project lifecycle policy that will address the incubation, archival and other stages of TAC Projects.
+
The TAC representatives will elect a chair to preside over meetings, ensure minutes are taken and drive the TAC agenda with input from the TAC representatives.
+
+
+
+
Voting
+
+
Quorum for Governing Board and Committee meetings will require at least fifty percent of the voting representatives. If advance notice of the meeting has been given per normal means and timing, the Governing Board may continue to meet even if quorum is not met, but will be prevented from making any decisions at the meeting.
+
Ideally decisions will be made based on consensus. If, however, any decision requires a vote to move forward, the representatives of the Governing Board or Committee, as applicable, will vote on a one vote per voting representative basis.
+
Except as provided in Section 14.a. or elsewhere in this Charter, decisions by vote at a meeting will require a simple majority vote, provided quorum is met. Except as provided in Section 14.a. or elsewhere in this Charter, decisions by electronic vote without a meeting will require a majority of all voting representatives.
+
In the event of a tied vote with respect to an action that cannot be resolved by the Governing Board, the Chair may refer the matter to the LFEU for assistance in reaching a decision. If there is a tied vote in any Committee that cannot be resolved, the matter may be referred to the Governing Board.
+
+
+
+
Subsidiaries and Related Companies
+
+
+
Definitions:
+
+
“Subsidiaries” means any entity in which a Sponsor owns, directly or indirectly, more than fifty percent of the voting securities or participation interests of the entity in question;
+
“Related Company” means any entity which controls or is controlled by a Sponsor or which, together with a Sponsor, is under the common control of a third party, in each case where such control results from ownership, either directly or indirectly, of more than fifty percent of the voting securities or participation interests of the entity in question; and
+
“Related Companies” are entities that are each a Related Company of a Sponsor.
+
+
+
+
Only the legal entity which has executed a Project Sponsorship Agreement and its Subsidiaries will be entitled to enjoy the rights and privileges of such sponsorship; provided, however, that such Sponsor and its Subsidiaries will be treated together as a single Sponsor.
+
+
If a Sponsor is itself a foundation, association, consortium, open source project, membership organization, participation organization, user group or other entity that has members or sponsors, then the rights and privileges granted to such Sponsor will extend only to the employee-representatives of such Sponsor, and not to its members or sponsors, unless otherwise approved by the Governing Board in a specific case.
+
OWF sponsorship is non-transferable, non-salable and non-assignable, except a Sponsor may transfer its current sponsorship privileges and obligations to a successor of substantially all of its business or assets, whether by merger, sale or otherwise; provided that the transferee agrees to be bound by this Charter and the Bylaws and policies required by LFEU sponsorship.
+
+
+
+
Good Standing
+
+
Linux Foundation Europe’s Good Standing Policy is available at https://linuxfoundation.eu/policies and will apply to all Sponsors of this OWF.
+
+
+
+
Trademarks
+
+
Any trademarks relating to the OWF or any Technical Project, including without limitation any mark relating to any conformance program, must be transferred to and held by LFEU or an entity in LFEU’s control and available for use pursuant to LFEU’s trademark usage policy, available at https://linuxfoundation.eu/policies.
All Sponsors must encourage open participation from any organization able to meet the sponsorship requirements, regardless of competitive interests. Put another way, the Governing Board will not seek to exclude any Sponsor based on any criteria, requirements or reasons other than those that are reasonable and applied on a non- discriminatory basis to all Sponsors.
+
+
+
+
Budget
+
+
The Governing Board will approve an annual budget and never commit to spend in excess of funds raised. The budget and the purposes to which it is applied must be consistent with both (a) the non-profit and tax-exempt mission of LFEU and (b) the goals of any Technical Project.
+
LFEU will provide the Governing Board with regular reports of spend levels against the budget. Under no circumstances will LFEU have any expectation or obligation to undertake an action on behalf of the OWF or otherwise related to the OWF that is not covered in full by funds raised by the OWF.
+
In the event an unbudgeted or otherwise unfunded obligation arises related to the OWF, LFEU will coordinate with the Governing Board to address gap funding requirements.
+
+
+
+
General & Administrative Expenses
+
+
LFEU will have custody of and final authority over the usage of any fees, funds, and other cash receipts.
+
A General & Administrative (G&A) fee will be applied by LFEU to funds raised to cover sponsorship records, finance, accounting, and human resources operations. The G&A fee will be 9% of the OWF’s first EUR 1,000,000 of gross receipts each year and 6% of the OWF’s gross receipts each year over EUR 1,000,000.
+
+
+
+
General Rules and Operations.
+
The OWF activities must:
+
+
engage in the work of the project in a professional manner consistent with maintaining a cohesive community, while also maintaining the goodwill and esteem of LFEU in the open source community;
+
respect the rights of all trademark owners, including any branding and usage guidelines;
+
engage or coordinate with LFEU on all outreach, website and marketing activities regarding the OWF or on behalf of any Technical Project that invoke or associate the name of any Technical Project or LFEU; and
+
operate under such rules and procedures as may be approved by the Governing Board and confirmed by LFEU.
+
+
+
+
Amendments
+
+
This Charter may be amended by a two-thirds vote of the entire Governing Board, subject to approval by LFEU.
The TAC may adopt a code of conduct (“CoC”) for the Project, which is subject to approval by LF Europe. In the event that a Project-specific CoC has not been approved, the LF Europe Code of Conduct listed at http://lfeurope.be/policies will apply for all Collaborators in the Project.
OpenWallet Foundation projects are required to maintain a standard set of files in each repository. This document describes the required and recommended files.
Repositories MUST have these files with the specific content in the linked files, or a file with a link to the specified content with minimal exposition. These files MUST be at the root of the repository.
Repositories MUST have these files. Named files MUST be at the root of the repository, and may have format suffixes such as .md, .rst, or .txt.
+
+
README - A description of the project that contains information or links to information such as:
+
A reference to the Apache license (required).
+
The current and important past releases
+
Documentation for developers and users
+
+
+
MAINTAINERS - A list of all current maintainers with contact info. A separate document covers the specifics.
+
CONTRIBUTING - Directions on how to contribute code to the project, or a link to a page with that information.
+
CHANGELOG - A human readable list of recent changes. Changes should at least include the current release. This file may be maintainer curated or mechanically produced.
+
Continuous Integration / Continuous Delivery (CICD) configurations - Configurations needed to run CICD on OpenWallet Foundation provided systems (e.g., .github/workflows).
Apache License Header information in each source code file. For new files added to OpenWallet Foundation repositories they SHOULD include the snippet SPDX-License-Identifier: Apache-2.0 as part of the header.
+
Build files consistent with the implementation language, such as:
+
For JavaScript/Node.js a package.json file
+
For Ruby a Gemfile file
+
For Java one of a Maven pom.xml, an Apache Ant build.xml, or a Gralde build.gradle
+
file
+
For Python setup.py and requirements.txt files
+
For Go go.mod and optionally go.sum
+
For Rust a cargo.toml file
+
For multi-lingual repositories a Makefile or executable build.sh script
+
For other languages, other standard build files a practitioner of the language would expect.
+
+
+
+
Testing code - Code to test the code in the repository (such as unit tests), in a location appropriate for the language.
+
+
Why not a MUST?
+
Not all repositories can be tested (homebrew, docs), which is the only reason this is a SHOULD.
Executable binaries and shared library files built by code in the repository. This includes .exe, .dll, .so, .a and .dylib files not otherwise part of a third party library.
Real-Time Communication: Chat services facilitate real-time, synchronous communication among users. Messages are sent and received instantly, enabling quick exchanges and conversations.
Interactive Collaboration: Chat services are well-suited for interactive collaboration, allowing users to engage in live discussions, share files, collaborate on documents, and even conduct video calls in some cases.
+
Staff: Administers, creates new channels, and moderates
Asynchronous Communication: Mailing lists are primarily used for asynchronous communication. Users send messages to a central email address, which are then distributed to all subscribers. Subscribers can read and respond to messages at their convenience.
Broadcasting Information: Mailing lists are effective for broadcasting information to a group of subscribers. They are commonly used for announcements, discussions, and sharing updates within a community or organization.
Archiving: Mailing lists typically archive messages, allowing subscribers to access past discussions and reference previous communications. This archival feature can be valuable for maintaining a record of conversations and facilitating knowledge sharing.
+
Staff: Administers, creates new lists, and moderates
Project-Based Source Code and User Documentation: Any source code for projects should utilize GitHub. GitHub pages should be used for hosting user documentation.
TAC Governance Documentation and Other Relevant Information: Governance documentation for the TAC must be version controlled. As such, GitHub is the appropriate place to store this information in addition to other relevant TAC materials. Currently https://tac.openwallet.foundation is generated from markdown files in GitHub.
SIG or Task Force Deliverables: A separate repo can be set up for SIGs and Task Forces so that they can have versioned control support for their deliverables.
+
Staff: Administers, creates new repos and teams
Maintainers: Reviews and handles issues and pull requests
Community: Use source,create issues, fork code, and contribute
Project, SIG, and TAC meetings: All project, SIG, and TAC meetings must be held using LFX meetings. This ensures that a recording of the meeting is captured and available for people to catch up on what they may have missed. Send an email to operations@openwallet.foundation to get your meetings scheduled.
+
Staff: Administers and creates new meetings
Community: Attends meetings and listen to recordings
The TAC is responsible for ... electing annually a chairperson to preside over meetings, set the agenda for meetings, ensure meeting minutes are taken and who will also serve on the Governing Board as the TAC’s representative (the “TAC Representative”).
+
+
The TAC voting members (as defined by the charter) will elect a chair on a yearly basis. Only TAC voting members are eligible to run for the TAC chair seat. Electing a chair will be completed through the voting process outlined below. If the TAC chair must leave their position during their term or is otherwise unable to fulfill their duties, they should submit a resignation and allow the TAC to fill the vacancy using the process outlined below.
The TAC voting members (as defined by the charter) will elect a vice chair on a yearly basis. Only TAC voting members are eligible to run for the TAC vice chair seat. Electing a vice chair will be held in conjunction with the chair election using the voting process outlined below. The person with the second highest number of votes will serve as the vice chair. If the TAC vice chair must leave their position during their term or is otherwise unable to fulfill their duties, they should submit a resignation and allow the TAC to fill the vacancy using the process outlined below.
The TAC is responsible for ... appointing up to two "at large" representatives to the TAC.
+
+
The TAC voting members (as defined by the charter) can appoint up to two "at large" representatives to the TAC. The election process for "at large" representatives will occur on a yearly basis. Members of the community can nominate themselves for the position. Alternatively, a TAC voting member can nominate a member of the community; however, the nominee must actively affirm their candidacy. Electing "at large" representatives will be completed through the voting process outlined below. If the "at large" representative must leave their position during their term or is otherwise unable to fulfill their duties, they should submit a resignation. "At large" vacancies will be handled using the process outlined below.
The following is the default timeline for voting. The times can be adjusted to avoid weekends and holidays, but it is essential that the final schedule be published in advance and adhered to.
+
+
Call for nominations: Noon PT, E-16 days
+
End of call for nominations: Noon PT, E-9 days
+
A ballot will be distributed on: E-7 days
+
The election will be completed on: Noon PT, E-day and election results are announced
+
+
+
Nominations
+
Nominees should outline their qualifications and provide a statement explaining why they would be a good choice for the seat.
Should the TAC Vice Chair seat become vacant, the vacancy will be filled by using the voting process outlined above and the replacement will serve the remainder of the original term.
Should a TAC "at large" representative seat become vacant, the vacancy will be filled at the next indicative election, by electing a person for a full new term, not by serving out the vacant term.
+
+
Why?
+
A TAC "at large" vacancy is not filled immediately because the charter does not specify a lower limit for TAC "at large" representatives; it only specifies an upper limit.
Should a TAC Project representative seat become vacant, the technical oversight body (e.g., a technical steering committee) for the TAC project will immediately appoint a new representative.
This policy applies to projects that do not have an explicit maintainer inactivity policy. Where a project has an established and functioning policy, only that project's policy will apply.
+
+
OpenWallet Foundation very much appreciates the contributions of all maintainers but removing write privileges is in the interest of an orderly and secure project.
+
Activity can be code contributions, code reviews, issue reporting, or any other such activity trackable by GitHub attributed to a OpenWallet Foundation repository.
+
When a maintainer has not had any activity in a particular project for three months they will receive a notification informing them of the inactivity policies. The means and manner of notification (email, github mentions, etc.) will be at the discretion of the TAC Chair or who the TAC Chair designates.
+
When a maintainer has not had any activity in a particular project for six months a proposal will be opened up to move the maintainer from active status to emeritus status. A member of the TAC or a OpenWallet Foundation staff member will open this proposal. Any permissions to approve pull requests or commit code and any other such privileges associated with maintainer status will be removed.
+
The proposal will be in the form of a pull request (PR) to the relevant project repositories updating their maintainer lists. The inactive maintainer will be notified of this via an "at" @ mention in the PR. The PR will be open for at least one week to allow time for the project and maintainer to comment.
+
Inactive maintainers who express an intent to continue contributing may request a three-month extension. This request shall be made in the pull request updating their active maintainer status. Typically, only one such extension will be granted.
+
Maintainers who have been moved to emeritus status may return to active status when their activity within the project resumes and the current maintainers of the project approve their reactivation.
+
An OpenWallet Foundation Foundation staff member will provide a report (or maintain an automated means to generate a report) of the most recent GitHub tracked actions for contributors at regular intervals to the TAC. It will be the TAC's responsibility to act on the data.
All OpenWallet Foundation projects MUST have a MAINTAINERS file (MAINTAINERS.md or MAINTAINERS.rst) at the top-level directory of the source code. This document will provide specifics on what to include in the MAINTAINERS file.
The first thing that MUST be included in the MAINTAINERS file is a list of the project's maintainers, both active and emeritus.
+
It is recommended that the lists be sorted alphabetically and contain the maintainers name, GitHub ID, LFID, Chat ID, Email, Company Affiliation, and Scope.
+
+
Important
+
+
The email for a maintainer MUST be specified and be a reliable mechanism to contact the maintainer.
+
Scope is dependent on the project and may not exist for a given project. Scope could be the whole project, a specific repository, specific directories in a repository, or high-level description of responsibility (e.g., Documentation).
+
+
+
The following shows the suggested format for the information:
The MAINTAINERS file SHOULD contain information about the different types of maintainers that exist (whole project, repo, part of repo) and what their duties are (e.g., maintainers calls, quarterly reports, code reviews, issue cleansing).
The MAINTAINERS file SHOULD contain information about how to become a maintainer for the project. This section SHOULD list specific information about what is required. Information that SHOULD be included in this section:
+
+
What is required before someone can be considered to become a maintainer
+
Consider whether there should be different requirements based on the scope (whole project, repo, part of repo) of maintainership
+
Whether sponsorship by an existing maintainer is required
+
How maintainers are proposed to the community. A number of open source projects require that a PR be done against the MAINTAINERS file to make this proposal
+
How many maintainers must approve the proposed maintainer. This should include information about what happens if someone vetoes the proposal
+
How long the existing maintainers have to respond to the proposal
+
+
How Maintainers are Removed or Moved to Emeritus Status¶
+
The MAINTAINERS file SHOULD contain information about how a maintainer is removed from the list of active maintainers. Information that SHOULD be included in this section:
+
+
What are the reasons a maintainer would be removed from the list of active maintainers
+
How this is proposed; similar to the way in which maintainers are added, one way to do this is via a PR against the MAINTAINERS file
OpenWallet Foundation (OWF) provides a number of paid developer tools for projects. Below, we list the ones that our projects currently have access to and are supported by the OWF staff. We emphasize that just because a tool is not on this list does not mean projects cannot use it; it just means that the project maintainers may have to support it themselves and may need to pay for the tooling. The Governing Board has final say over the budget for tooling and its support.
+
OWF recommends the following tools that should be optimal for most projects:
This document provides details about what resources are available for OpenWallet Foundation projects and labs. If there are any questions about anything on the document or if you'd like to leverage any of these resources for your project or lab, feel free to reach out to community-architects at openwallet dot foundation.
The TAC will undertake an annual review of all OpenWallet Foundation projects. This annual review will include an assessment as to whether:
+
+
each Lab is active
+
each Growth Stage project is making adequate progress towards the Impact Stage
+
each Impact Stage project is maintaining progress to remain at the Impact Stage
+
+
Reviews will start on the yearly anniversary of the project being accepted or moving to a new stage. The review will include a set of recommendations for each project to improve and/or recommendation to move a project across stages.
+
Projects can be provided with an extension of time in their current stage (up to the discretion of the TAC).
+
The project lifecycle contains Acceptance Criteria for moving a project to a new stage.
OpenWallet Foundation staff will notify the project maintainers when the project review is due.
+
Project maintainers are responsible for agreeing between them who will complete the annual review. One of the maintainers should create the review in GitHub under openwallet-foundation/tac/docs/projects/reviews.
The PR should include a file called <year>-<project name>-annual.md (e.g., 2024-amazingproj-annual.md) with the contents described below
+
Send an email to the TAC mailing list so that the community knows the PR is there and can comment on it
+
+
If your annual review is not submitted within two months of notification, we will take this as a sign that the project is not under active maintenance and the TAC is likely to decide to archive the project and move it to Emeritus status.
+
+
Success
+
If a project has genuinely stalled we can save everyone’s time and effort by archiving it.
Your annual review should answer the following questions:
+
+
Include information about your project's contributions and activity. We will be looking for signs of consistent or increasing contribution activity. Please feel free to add commentary to add colour to the numbers and graphs we will see on Insights.
+
How many maintainers do you have, and which organisations are they from? (Feel free to link to an existing MAINTAINERS file if appropriate.)
+
What do you know about adoption, and how has this changed since your last review or since being accepted into OWF? If you can list companies that are adopters of your project, please do so. (Feel free to link to an existing ADOPTERS file if appropriate.
+
How has the project performed against its goals since the last review? (We won't penalize you if your goals changed for good reasons.)
+
What are the current goals of the project? For example, are you working on major new features? Or are you concentrating on adoption or documentation?
+
How can the OpenWallet Foundation help you achieve your upcoming goals?
Annual reviews are performed in order to check in with projects, ascertain their progress, and address any outstanding questions.
+
+
A TAC representative volunteers to lead the review once the project files a PR.
+
The assigned TAC member reviews the content of the PR and analyzes the project for community health indicators, their findings are placed within a thread in the private TAC channel for discussion.
+
findings should highlight important facts about the project that could influence the TACs decision around the future of the project, its current stage, and path to other stages, etc.
+
the thread should always include whether the project's view of themselves is accurate and the ask of the TAC is reasonable to assist the project moving forward.
+
+
+
The project's maintainers are invited to the public TAC meeting to engage in TAC led discussion around the project. Project maintainers are not obligated to attend.
+
The assigned TAC member provides a summary of the project and leverages the thread's content as the basis of discussion.
+
discussion typically focuses on what is going well with the project and areas to improve.
+
+
+
The project's maintainers are invited to use this time to voice any concerns and requests for help they may have that are not captured in the PR (or highlight asks within the PR).
+
At the conclusion of the public meeting, the TAC votes to approve the annual review. Should a concern be registered on a project, the vote will be held separately.
+
After the meeting wraps up, the assigned TAC member may summarize the discussion on the PR in the form of a comment to document information for the project and community.
At least two-thirds of the TAC members agree to continue to sponsor the project at its current stage, or
+
+
If enough TAC members do not agree to continue to sponsor the project at its current stage, we will discuss with you what stage might be the appropriate next stage, including Emeritus stage.
+
+
Info
+
If the TAC members recommend moving to a new stage, additional work may be required to provide details on how the project meets the new stage's acceptance criteria.
This governance policy describes how an open source project can formally join the OpenWallet Foundation via the Project Proposal Process and how an existing project within the OpenWallet Foundation can move through the lifecycle via the Project Stage Change Proposal Process. It describes the Stages a project may be admitted under and what the criteria and expectations are for a given stage, as well as the acceptance criteria for a project to move from one stage to another. It also describes the Annual Review Process through which those changes will be evaluated and made.
+
Project progression - movement from one stage to another - allows projects to participate at the level that is most appropriate for them given where they are in their lifecycle. Regardless of stage, all OpenWallet Foundation projects benefit from a deepened alignment with existing projects, and access to mentorship, support, and Foundation resources.
+
+
Info
+
Capitalized terms not otherwise defined in this Project Lifecycle Policy have the meanings ascribed to them in the Charter of the OpenWallet Foundation.
This governance policy sets forth the proposal process for projects to be accepted into the OpenWallet Foundation. The process is the same for both existing projects which seek to move into the OpenWallet Foundation and new projects to be formed within the OpenWallet Foundation.
Projects must be formally proposed via GitHub. Project proposals submitted to the OpenWallet Foundation should provide the following information to the best of their ability:
project description (what it does, why it is valuable, origin and history)
+
statement on alignment with the OpenWallet Foundation mission
+
link to current Code of Conduct (if one is adopted already)
+
sponsor from the TAC, if identified (a sponsor helps mentor projects)
+
project license (OSI-approved permissive open source licenses, Apache 2.0 by default)
+
source control (OpenWallet Foundation GitHub by default)
+
issue tracker (OpenWallet Foundation GitHub by default)
+
external dependencies (including licenses)
+
release methodology and mechanics
+
names of initial maintainers, if different from those submitting proposal
+
link to any documented governance practices (e.g., the project charter) (A project charter can be obtained by completing this form. Here is sample project charter that you can review)
+
existing financial sponsorship (if exists)
+
infrastructure needs or requests (OpenWallet Foundation provides a set of services for projects and labs. Please note which of these you will utilize and what else is required)
Impact stage and Growth stage projects are required to present their proposal at a TAC meeting. Labs will be reviewed and approved directly via the project proposal PR. Labs may present at a TAC meeting if they would like to gain visibility from other community members, and the proposer should note this in the proposal.
+
+
The TAC may ask for changes to bring the project into better alignment with the OpenWallet Foundation (adding a governance document to a repository or adopting a Code of Conduct, for example).
+
+
Warning
+
The project will need to make these changes in order to progress further.
+
+
+
+
Impact stage and Growth stage projects are accepted via a two-thirds supermajority vote of the TAC. Labs are accepted via a simple majority of the TAC.
+
+
Satisfaction of the requirements of the initial stage of the project. The TAC will determine the appropriate initial stage for the project. The project can apply for a different stage via the review process.
This governance policy sets forth the proposal process for projects within the OpenWallet Foundation that are seeking to move to another stage in the project lifecycle.
The project's current proposal located in Project Proposals GitHub Repository must be updated via a PR. The project proposal should be updated to reflect the latest template, as well as any updates to the sections to reflect why the project should be considered for a new stage.
Every OpenWallet Foundation project has an associated maturity level. Proposed projects should state their preferred maturity level.
+
All projects may attend TAC meetings and contribute work regardless of their stage.
+
flowchart
+ p[Proposal]
+ subgraph as[Active Stages]
+ l[Labs]
+ g[Growth]
+ i[Impact]
+ end
+ subgraph is[Inactive Stages]
+ e[Emeritus]
+ end
+ p --> as
+ l <--> g
+ l <--> i
+ g <--> i
+ as --> is
Labs are those which the TAC believes are, or have the potential to be, important to the ecosystem of Technical Projects or the open wallet ecosystem as a whole. They may be early-stage code just getting started, or they may be long-established projects with minimal resource needs. The Labs stage provides a beneficial, neutral home for these projects in order to foster collaborative development and provide a path to deeper alignment with other OpenWallet Foundation projects via the project lifecycle process.
+
Examples
+
+
Experimental code that is designed to extend one or more OpenWallet Foundation projects with functionality or interoperability libraries.
+
Independent code that fits within the Foundation's mission and provides potential to meet an unfulfilled need.
+
Code commissioned or sanctioned by the OpenWallet Foundation.
+
Any code that intends to join the Growth or later stages in the future and wishes to lay the foundation for that transition.
+
+
Expectations
+
End users should evaluate Labs with care, as this stage does not set requirements for community size, governance, or production readiness. Labs will receive minimal support from the Foundation. Labs will be reviewed on an annual basis; they may also request a status review by submitting a report to the TAC.
+
Acceptance Criteria
+
To be considered for the Labs Stage, the project must meet the following requirements:
A project charter (sample) that documents an intellectual property policy that leverages the Apache 2.0 license or a permissive open source license.
+
A collaboration agreement that in the case of existing projects, provides an agreement to transfer the project name, trademarks, and electronic account assets (github repo, social media accounts, domain names, etc.) to Linux Foundation Europe for the benefit of the OpenWallet Foundation.
The Growth Stage is for projects that are interested in reaching the Impact Stage, and have identified a growth plan for doing so. Growth Stage projects will receive mentorship from the TAC and are expected to actively develop their community of contributors, governance, project documentation, roadmap, and other variables identified in the growth plan that factor into broad success and adoption.
+
In order to support their active development, projects in the Growth stage have a higher level of access to Foundation resources, which will be agreed upon and reviewed on a yearly basis. A project's progress toward its growth plan goals will be reviewed on a yearly basis, and the TAC may ask the project to move to the Labs stage if progress on the plan drops off or stalls.
+
Examples
+
+
Projects that are on their way or very likely to become Growth or Impact projects.
+
Projects that have developed new growth targets or other community metrics for success.
+
Projects that are looking to create a lifecycle plan (maintainership succession, contributor programs, version planning, etc.).
+
Projects that need more active support from the Foundation or TAC mentorship in order to reach their goals.
+
+
Expectations
+
Projects in the Growth stage are generally expected to move out of the Growth stage within two years. Depending on their growth plans, projects may cycle through Labs, Growth, or Impact stage as needed.
+
Acceptance Criteria
+
To be considered for Growth Stage, the project must meet the Labs requirements as well as the following:
+
+
A presentation at the meeting of the TAC.
+
2 TAC sponsors to champion the project and provide mentorship as needed.
+
Development of a growth plan, to be done in conjunction with their project mentor(s) at the TAC.
+
Development of a project roadmap that provides differentiated features and capabilities and the timeframe for completion.
+
Document that it is being used successfully in either proof of concepts or pilots by at least two independent end users which, in the TAC’s judgment, are of adequate quality and scope.
+
Demonstrate a substantial ongoing flow of commits and merged contributions.
+
Demonstrate that the current level of community participation is sufficient to meet the goals outlined in the growth plan and roadmap.
+
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.
+
Demonstrates how this project differs from existing projects in the Growth and Impact stages.
+
Receive a two-thirds supermajority vote of the TAC to move to Growth Stage.
+
+
Upon acceptance, Growth projects must list their status prominently on their website/README (e.g., PROJECT, an OpenWallet Foundation Project).
The Impact Stage is for projects that have reached their growth goals and are now on a sustaining cycle of development, maintenance, and long-term support. Impact Stage projects are used commonly in enterprise production environments and have large, well-established project communities.
+
Examples
+
+
Projects that have publicly documented release cycles and plans for Long Term Support ("LTS").
+
Projects that have themselves become platforms for other projects.
+
Projects that are able to attract a healthy number of committers on the basis of its production usefulness (not simply 'developer popularity').
+
Projects that have several, high-profile or well known end-user implementations.
+
+
Expectations
+
Impact Stage projects are expected to participate actively in TAC proceedings, and as such have a binding vote on TAC matters requiring a formal vote, such as the election of a TAC representative. They receive ongoing financial and marketing support from the Foundation, and are expected to cross promote the Foundation along with their activities.
+
Acceptance Criteria
+
To move from Labs or Growth status, or for a new project to join as an Impact project, a project must meet the Growth stage criteria plus:
+
+
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.
+
Have a documented and publicly accessible description of the project's governance, decision-making, and release processes.
+
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.
+
Have a Code of Conduct in a form acceptable to the OpenWallet Foundation.
+
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).
+
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.
+
Have a public list of project adopters for at least the primary repo (e.g., ADOPTERS.md or logos on the project website).
+
Have a good standing with respect to security.
+
Other metrics as defined by the applying Project during the application process in cooperation with the TAC.
+
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.
+
+
Upon acceptance, Impact projects must list their status prominently on their website/README (e.g., PROJECT, an OpenWallet Foundation Project).
Emeritus projects are projects which the maintainers feel have reached or are nearing end-of-life. Emeritus projects have contributed to the ecosystem, but are not necessarily recommended for modern development as there may be more actively maintained choices. The Foundation appreciates the contributions of these projects and their communities, and the role they have played in moving the ecosystem forward.
+
Examples
+
+
Projects that are "complete" by the maintainers' standards.
+
Projects that do not plan to release major versions in the future.
+
+
Expectations
+
Projects in this stage are not in active development. Their maintainers may infrequently monitor their repositories, and may only push updates to address security issues, if at all. Emeritus projects should clearly state their status and what any user or contributor should expect in terms of response or support. If there is an alternative project the maintainers recommend, it should be listed as well. The Foundation will continue to hold the IP and any trademarks and domains, but the project does not draw on Foundation resources.
+
Acceptance Criteria
+
Projects may be granted Emeritus status via a two-thirds vote from the TAC and with approval from project ownership. In cases where there is a lack of project ownership, only a two-thirds vote from the TAC is required.
+
Upon acceptance, Emeritus projects must list their status prominently on their website/README.
+
+
Info
+
If members of the community would like to re-active a project that has been granted Emeritus status, the community must start the lifecycle over again by submitting a new proposal to the TAC.
Releases at OpenWallet Foundation must be done according to the SemVer taxonomy. In addition to the semantic versioning scheme, where we use MAJOR.MINOR.PATCH numbering, following the established guidance given in the semver specification, it is also strongly encouraged that projects should use the following tags, as permitted by semver:
rcN (release candidate N - where N is 1-n incremented for each candidate)
+
+
snapshot-<sha> for interim, possible unstable builds
+
+
Note
+
Further, for interim, possibly unstable builds working towards a tagged release, we will append the first seven (7) characters of the SHA-1 hash of the latest commit for the branch from which the build is produced, so that we can identify the commit level of a given test, etc. e.g. 0.6-snapshot-36e99cd
Not feature complete, but most functionality is implemented. Any missing functionality that is committed to the production release is identified, and there are specific people working on those features. Not heavily performance tuned, but performance testing has started with the first few hotspots identified and perhaps even addressed. No highest priority issues are in an open state. First-level developer documentation provided to help new developers with the learning curve.
Feature complete, for all features committed to the production release. Ready for Proof of Concept-level deployments. Performance can be characterized in a predictable way, so that basic PoC's can be done within the bounds of published expectations. APIs are documented. First attempts at end-user documentation have been made. Developer documentation is further advanced. No highest priority issues are in an open state.
Feature complete for all features committed to the production release, perhaps with optional features when safe to add. Ready for Pilot-level engagements. Performance is very well characterized and active optimizations are being done, with a target set for the Production release. No highest priority or high priority bugs are in an open state. Developer documentation is complete; end-user documentation is mostly done.
For a forthcoming production release, we will prepare multiple candidate releases intended to be heavily tested by the community. As we cycle through resolving uncovered issues, we will issue another when no remaining highest or high priority issues remain, and repeat until we feel confident in releasing a production release, with no qualifier. e.g. 1.0.
maintaining an overall strategic vision for technical collaboration and coordinating collaboration among Technical Projects, including development of an overall technical vision for the community;
+
making recommendations to the Budget Committee of resource priorities for Technical Projects;
+
electing annually a chairperson to preside over meetings, set the agenda for meetings, ensure meeting minutes are taken and who will also serve on the Governing Board as the TAC’s representative (the “TAC Representative”);
+
creating, maintaining and amending project lifecycle procedures and processes, deciding where Technical Projects fall within that lifecycle;
+
determining when a technical project should be admitted as a Technical Project or any Technical Project should be considered a TAC Project; and
+
such other matters related to the technical role of the TAC as may be communicated to the TAC by the Governing Board.
Subscribe to the TAC mailing list and the OpenWallet Github organization to stay aware of the TAC related updates and issues
+
Regularly participate in the TAC meetings
+
Bring up and help resolve any issues related to the needs of the OpenWallet technical community
+
Participate in, and optionally chair, the Task Forces set up by the TAC to address specific issues
+
Act as stewards for OpenWallet Foundation promoting and helping grow the organization and its activities by engaging of their own accord in activities such as posting on social media, responding to questions raised in forums, helping new community members find their way around, and giving talks at conferences on OpenWallet Foundation related topics
+
Participate in the appointment and election of "at large" representatives
The TAC chair has the following additional responsibilities:
+
+
Running the TAC meetings, such as the TAC calls per the agreed upon schedule. This includes: setting up and publishing an agenda, running the meeting, and ensuring any outcome is duly recorded
+
Representing the TAC, and more broadly the OpenWallet Foundation technical community, on the Governing Board, and giving updates to the Governing Board on TAC activities
The following is the best practices template security vulnerability disclosure
+policy for OpenWallet Foundation's projects. Please copy the text below, place it into the SECURITY.md file for the primary repository of your project,
+and adjust it as necessary for your project. Notably:
+
+
Remove this "Instructions" section.
+
Replace PROJECT in the title of this page with the name of your project.
+
Populate the Security Team section with maintainers who have agreed to be on the security team.
+
See the "Alternative" notes in the OpenWallet Foundation's security vulnerability disclosure policy document for how the "best practices" in this document can be changed to meet the needs of your project while still adhering to the OpenWallet Foundation's policies.
+
+
Once your project's security vulnerability disclosure policy document is
+published, place a copy of it into each of your project's repositories
+(or link to the main repository's SECURITY.md).
This document document defines how security vulnerability reporting is handled
+in this project. The approach aligns with the OpenWallet Foundation's security
+vulnerability disclosure policy. Please review that document to understand
+the basis of the security reporting for this project
+
This policy borrows heavily from the recommendations of the OpenSSF
+Vulnerability Disclosure working group. For up-to-date information on the latest
+recommendations related to vulnerability disclosures, please visit the GitHub
+of that working group.
+
If you are already familiar with what a security vulnerability disclosure policy
+is and are ready to report a vulnerability, please jump to Report
+Intakes.
No piece of software is perfect. All software (at least, all software of a
+certain size and complexity) has bugs. In open source development, members of
+the community or the public find bugs and report them to the project. A
+vulnerability disclosure policy explains how this process functions from the
+perspective of the project.
+
This vulnerability disclosure policy explains the rules and guidelines for
+this project. It is intended to act as both a reference for
+outsiders–including both bug reporters and those looking for information on the
+project’s security practices–as well as a set of rules that maintainers and
+contributors have agreed to follow.
This project uses the following mechanism to submit security
+vulnerabilities. While the security team members will do their best to
+respond to bugs disclosed in all possible ways, it is encouraged for bug
+finders to report through the following approved channel:
The security team for this project must include at least three project
+Maintainers that agree to carry out the following duties and responsibilities.
+Members are added and removed from the team via approved Pull Requests to this
+repository. For additional background into the role of the security team, see
+the People Infrastructure section of the OpenWallet Foundation's security vulnerability disclosure policy.
+
Responsibilities:
+
+
+
Acknowledge receipt of the issue (see Report Intakes) to the reporter within 2 business days.
+
+
+
Assess the issue. Engage with the reporter to ask any outstanding questions about the report and how to reproduce it. If the report is not considered a vulnerability, then the reporter should be informed and this process can be halted. If the report is still a regular bug (just not a security vulnerability), the reporter should be informed (if necessary) of the regular process for reporting bugs.
+
+
+
Some issues may require more time and resources to correct. If a
+particular report is more complex, discuss an embargo period with the reporter.
+The embargo period should be negotiated with the reporter and must not be
+longer than 90 days.
Discussions about each reported vulnerability are carried out in the
+private GitHub security advisory about the vulnerability.
+If necessary, a private channel specific to the issue may be created on the
+OpenWallet Foundation's Discord server with invited participants added to the
+discussion.
This project maintains a private embargo list. If you wish to be added to
+the embargo list for a project, please email the [OpenWallet Foundation's
+security list], including the project name and reason for being added to the
+embargo list. Requests will be assessed by the security team in conjunction
+with the appropriate OpenWallet Foundation staff, and a decision will be made
+whether to accommodate the request.
In creating patches and new releases that address security vulnerabilities,
+this project uses the private development features of GitHub for security
+vulnerabilities. GitHub has extensive
+documentation
+about these features.
This document outlines the OpenWallet Foundation's security vulnerability
+disclosure policy
+that all OpenWallet Foundation projects MUST follow. The associated
+security template file is a "best practices" security vulnerability
+disclosure policy that project Maintainers SHOULD use for
+publishing the security policy and procedures for their project by copying the
+file into their project repositories and updating it according to the
+instructions in the document. This document includes the "best practices" text,
+and defines how project Maintainers can use alternatives to the best practices
+for their project. A project's resulting
+alternative policy MUST adhere to the OpenWallet Foundation's security
+vulnerability disclosure policy.
+
All project repositories MUST have a published security vulnerability
+disclosure policy or have link to a common policy document for the project.
+In rare cases, a repository within a project MAY have a policy different
+from the project, as long as the repository policy also adheres to this
+OpenWallet Foundation's security vulnerability disclosure policy.
This policy borrows heavily from the recommendations of the OpenSSF
+Vulnerability Disclosure working group. For up-to-date information on the latest
+recommendations related to vulnerability disclosures, please visit the GitHub
+of that working group.
+
In each of the document's sections, and in the associated
+security template, the current OpenWallet Foundation's "best practices" are
+defined.
+
+
Alternative
+
Alternatives that a project may use exist for some sections and are contained in these "Alternative boxes". When projects vary from the current OpenWallet Foundation's best practices, the documented alternatives MUST adhere to this policy.
No piece of software is perfect. All software (at least, all software of a
+certain size and complexity) has bugs. In open source development, members of
+the community or the public find bugs and report them to the project. A
+vulnerability disclosure policy explains how this process functions from the
+perspective of the project.
+
This vulnerability disclosure policy explains the rules and guidelines for
+OpenWallet Foundation's projects. It is intended to act as both a reference for
+outsiders–including both bug reporters and those looking for information on the
+project’s security practices–as well as a set of rules that maintainers and
+contributors have agreed to follow.
+
Vulnerability Disclosure Process and Associated Rules¶
+
All OpenWallet Foundation's projects, including this project, follow the
+associated process
+and rules for vulnerability disclosures. We note that this outline is derived
+from the OpenSSF maintainers guide.
+
Each project will have a security team. The security team
+will be comprised of maintainers or contributors to the project who are
+knowledgeable about security and is responsible for responding to and
+helping to fix security vulnerabilities.
+
The security team for this project will do the following for each reported vulnerability:
+
+
+
Acknowledge receipt of the issue (see Report Intakes) to the reporter within 2 business days.
+
+
+
Assess the issue. Engage with the reporter to ask any outstanding questions about the report and how to reproduce it. If the report is not considered a vulnerability, then the reporter should be informed and this process can be halted. If the report is still a regular bug (just not a security vulnerability), the reporter should be informed (if necessary) of the regular process for reporting bugs.
+
+
+
Some issues may require more time and resources to correct. If a
+particular report is more complex, discuss an embargo period with the reporter.
+The embargo period should be negotiated with the reporter and must not be
+longer than 90 days.
OpenWallet Foundation's projects use the following mechanism to submit security
+vulnerabilities. While the security team members will do their best to
+respond to bugs disclosed in all possible ways, it is encouraged for bug
+finders to report through the following approved channel:
Projects MAY publish in their security policy that they accept security vulnerability disclosures via other mechanism. The policy MUST document the necessary details in using the alternate reporting mechanism(s). Projects MUST accept reports via the recommended GitHub security vulnerability process.
This section details the required basic vulnerability disclosure infrastructure
+for all OpenWallet Foundation's projects. There are quite a few necessary
+pieces of infrastructure, and we go through them in detail here.
Projects MUST have a security response team of at
+least three maintainers. This response team shall be set up BEFORE incidents
+happen so that people know who to contact and how to contact them when an
+emergency issue arises. It can be difficult to track down someone with unique
+knowledge (e.g. in a particular area of cryptography) who is capable of
+fixing a problem in a short period of time.
+
+
+
Each security team member will be a member of
+any OpenWallet Foundation-wide security infrastructure.
+
+
+
If a project has specialized code related to certain aspects of security
+or cryptography (e.g. consensus algorithms or cryptographic algorithms), then
+a corresponding specialist should be on the response team (e.g. someone
+knowledgeable in consensus or cryptography, respectively). If a specialist
+is not on the team, then the individual who is responsible for contacting or
+engaging the specialists should be designated in their stead. We emphasize
+that projects should have access to specialists in an area for which they
+maintain code while recognizing that it may not be practical for these experts
+to be on the response team.
+
+
+
Each project/repository must have a table in the security document listing the
+team members in the following format.
Discussions about each reported vulnerability SHOULD be carried out in the
+private GitHub security advisory about the vulnerability. If necessary, a private
+channel specific to the issue MAY be created on the OpenWallet Foundation's
+Discord server with invited participants added to the discussion.
+
+Alternative
+
Projects MAY document on their security policy that they use other forums for private discussion forums for approved maintainers and security team participants to discuss vulnerabilities. If other forum(s) are used, details about them MUST be included.
OpenWallet Foundation's projects maintain a list of Common Vulnerabilities and Exposures
+(CVE) and use GitHub as its CVE numbering authority (CNA) for issuing
+CVEs.
+
+Alternative
+
A project MAY document in its security policy that it uses a different CVE numbering authority. For example, the project might add the following text to this section of their security policy document:
+
This project uses the following CNA(s) in the following situations:
+1. `CNA_1`: `situation_1, can just state “default” if only one CNA`
+2. `CNA_2`: `situation_2`
+
An embargo list is a list of known, trusted entities that run
+large deployments of a given OpenWallet Foundation's project. These
+entities are notified ahead of time when important security patches are
+incoming to minimize potential security risks to large deployments of
+projects. Embargo lists are maintained by the security team for a given project/repository.
+
Parties are on an embargo list for (usually) one of two reasons,
+because they can either help fix the problem (perhaps through testing a fix at
+scale) or they need extra time to help prepare their ecosystem to roll out
+fixes quickly. Approval is not given lightly: project leadership
+(maintainers) must be convinced that institutions on the list “need to know"
+about issues in advance.
+
Participation in an embargo list should not be taken lightly. List members
+are expected to respect the materials shared through it and not disclose any
+information to unauthorized parties until the public disclosure date.
+Institutions are on this list because their presence helps the project and its
+users; if their actions do not help the project and its users, they can expect
+to be removed from the list.
+
The list itself is private in order to make it slightly more difficult for
+attackers with vulnerabilities to find systems to attack. Entities may be
+added to the embargo list by a majority vote of the project security response
+team and should request to join the embargo list by contacting one or more of
+the members of the security response team. If there is an issue about embargo
+list membership where an entity feels like they are being dealt with unfairly
+by the security response team, then they are encouraged to bring up the issue
+in front of the OpenWallet Foundation's TAC, who can act as moderators.
+
OpenWallet Foundation's projects maintain private embargo lists. If you wish to be added to
+the embargo list for a project, please email the [OpenWallet Foundation's
+security list], including the
+project name and reason for being added to the embargo list. Requests will be
+assessed by the respective OpenWallet Foundation's security team in conjunction with the
+appropriate OpenWallet Foundation staff, and a decision will be made to accommodate or not
+the request.
+
+Alternative
+
Projects MAY choose to document in their security document that they do not have an embargo list. The reason for not having an embargo list SHOULD be included when a project chooses not to have an embargo list.
OpenWallet Foundation's projects use GitHub
+security advisories and the GitHub security process for
+handling security vulnerabilities. In particular, this best practice is strongly recommended
+for projects that do not have a large number of security experts as the
+features serve as a nice set of guardrails to help make sure that things are
+done correctly.
+
+Alternative
+
Projects MAY document in their security policy document that they use a security advisory mechanism other than GitHub to publish their disclosures. The alternate mechanism MUST be documented sufficiently for users to understand how to monitor the security advisories published by the project.
Patches to fix OpenWallet Foundation's project security vulnerabilities are typically
+developed without public visibility by using the private development features of
+GitHub. Projects with maintainers that are not familiar with these capabilities
+are encouraged to contact the OpenWallet Foundation Community Architects to learn more.
+
+Alternative
+
Projects MAY document in their security policy document that they do use a service other than GitHub for private patch deployment infrastructure, or that they don't use any private patch deployment infrastructure at all. In either case, the document MUST include the details of what is used instead.
A special interest group (SIG) under the Technical Advisory Council (TAC) is a group with a shared interest in advancing a specific area of knowledge, learning, or technology related to the mission of the OpenWallet Foundation where members cooperate to affect or to produce solutions within their particular field. Unlike a task force, SIGs are typically long running and may or may not produce any deliverables. A SIG can be created by anyone in the OpenWallet Foundation community and must be proposed to and approved by the TAC.
To propose a special interest group, create an issue in the TAC GitHub repository using the Special Interest Group template. The issue should be named "Special Interest Group Proposal: \<name of special interest group>". The issue should include the following information:
The TAC will review the special interest group proposal first by providing comments in the issue and secondly by bringing the special interest group proposal to a discussion and vote in a TAC meeting.
+
The decision of the vote will be documented in the issue. If the special interest group is approved, a discussion channel in Discord will be created. In addition, we will work with the OpenWallet Foundation operations team to schedule a meeting on the OpenWallet Foundation calendar. If necessary, a GitHub repository and/or mailing list will also be created at the request of the special interest group leader(s).
The special interest group can decide on the mechanism for running the SIG. Meeting minutes and a log of decisions that have been made should be kept for ensuring continuity of the special interest group. The special interest group should update the issue to reflect where the meeting notes and log of decisions is kept or use the issue directly to capture this information.
Every quarter the special interest group leader should report on the activities of the SIG at a TAC meeting. This will ensure that the SIG is still active and that there is still value in hosting the special interest group. Please see the schedule for when these updates should occur.
A task force is a group that is focused on a task with limited scope and fixed time to complete. Unlike a special interest group, a task force will have a specific set of deliverables or work products that it will create and be limited in time to completion. A task force can be created by anyone in the OpenWallet Foundation community and must be proposed to and approved by the TAC.
To propose a task force, create an issue in the TAC GitHub repository. The issue should be named "Task Force Proposal: \<name of task force>". The issue should include the following information:
The TAC will review the task force proposal first by providing comments in the issue and secondly by bringing the task force proposal to a discussion and vote in a TAC meeting.
+
The decision of the vote will be documented in the issue. If the task force is approved, a discussion channel in Discord will be created. In addition, we will work with the OpenWallet Foundation operations team to schedule a meeting on the OpenWallet Foundation calendar. If necessary, a GitHub repository and/or mailing list will also be created at the request of the task force leader(s).
The task force can decide on the mechanism for creating the deliverables. Meeting minutes and a log of decisions that have been made should be kept for ensuring continuity of the task force. The task force should update the issue to reflect where the meeting notes and log of decisions is kept or use the issue directly to capture this information.
+
Reporting on Task Force Completion of Deliverables¶
+
Upon completion of the task force's deliverables, the task force should arrange a time with the TAC chair to present the deliverables at a TAC meeting. This can be accomplished by sending an email to the TAC mailing list at tac@lists.openwallet.foundation.
If the task force is not able to complete the deliverables by the specified completion date, then the leader of the task force should arrange a time with the TAC chair to discuss the extension at a TAC meeting. This discussion should include information on the current status, the delays, and the expected updates to the schedule. This can be accomplished by sending an email to the TAC mailing list at tac@lists.openwallet.foundation.
The TAC is responsible for maintaining an overall strategic vision for technical collaboration and coordinating collaboration among Technical Projects, including development of an overall technical vision for the community.
The Governing Board met yesterday and appointed Daniel Goldscheider as Interim Executive Director. Daniel introduced himself and provided his thoughts on the future of OWF.
+
A suggestion was made for a landscape review. A comment was made that that work has begun here.
Conduct an email vote for the Governance documents approval and adoption - results 3 TAC members voted in favor; 1 TAC member abstained
+
Conduct an email vote for the TAC "at large" schedule and process - results 3 TAC members voted in favor; 1 TAC member abstained
+
Todd to confirm whether the TAC can create an alternate policy or whether the Governing Board will need to update the charter to reflect - currently no policy for TAC alternates; if we want this, we would need to present this to the GB to get a charter update
+
The TAC would like to recommend that the board create an alternate policy for the TAC.
+
The language will be similar to the following "A TAC member can designate an alternate for a specific meeting, and has to notify the chair in advance."
+
+
+
Tracy to create a pull request to update the project proposal template to include links to the mission and project lifecycle - pull request created and merged
+
Create a GitHub organization (openwallet-foundation-labs) to host incoming labs - not yet completed
A question was brought up about the status of this group and whether it is a task force or a special interest group. The TAC formalized the group as a special interest group under the TAC.
Tracy to rename the architecture-task-force GitHub repo to architecture-sig - completed
+
Jenn to rename the meeting invite for the Outside Architecture Special Interest Group to reflect that the name should be the Architecture SIG - completed
+
Jenn to add Stavros to the TAC meeting invite - completed
+
Jenn to add Jeremie to the TAC meeting invite - completed
“various open source, open data and/or other open projects relating to or supporting development of digital wallets, including infrastructure and support initiatives related”
The Governing Board agreed to modify the Charter to include the following language:
+
+
Updated Language
+
5.c) TAC meetings are intended to be open to observe by Sponsors, contributors to any TAC Project and others in the general public interested in the OpenWallet Foundation. The TAC may decide whether to allow named representatives (one per voting member) to attend as an alternate.
Credential Format Comparison SIG will meet on Wednesdays at 5pm CEST on alternate weeks to the OID4VC Due Diligence Task Force. Kickoff meeting planned for June 28th
A question was asked whether we were tracking a wishlist for potential projects
+
In general, we are looking for projects that fit with the vision of the OpenWallet Foundation. Those that are focused on wallet engine related to identity, money, and objects
+
We previously were capturing potential code projects using this Google sheet
+
+
+
If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up
+
+
+
+
Open discussion and next steps
+
+
Relative to the Credential Format Comparison SIG, the ToIP Foundation has just started a task force on the same thing for credential exchange protocols. See this spreadsheet
+
David Alexander will present on wallets and personal data stores at the next meeting and we will discuss further
If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up
For Associate non-profit members of the OpenWallet Foundation: voting is now open to select the Associate Representative for the Governing Board. Please email operations@openwallet.foundation if you have any questions about your organization's participation in this vote.
If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up
Proposed resolution was not voted on. It was suggested that we develop a proposal that would include other tools that the technical community would need to limit the number of requests to the Governing Board.
Discussion was had to make sure that we are prefixing repo names with the project name to ensure that it is easy for someone to find all repos associated with a single project
If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up
Jorge to update code of conduct on Farmworker Wallet OS proposal -- completed
+
Create repositories for the Farmworker Wallet OS Lab
+
Share document with governance best practices -- completed
+
OWF Project Guidance -- this document assumes a fairly mature project that consists of a technical steering committee and maintainers for the project. Please comment and add your thoughts/suggestions.
If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up
+
Question asked about code proposal that depends on Aries/Bifold and whether that could be submitted to OWF?
+
If the project is only dependent on Aries/Bifold, then it can be submitted to OWF.
+
If, however the project is a wrapper of Aries/Bifold, then that should probably be submitted to Hyperledger.
+
+
+
Question about project governance best practices and whether we could document these best practices for new projects.
+
OWF Project Guidance -- this document assumes a fairly mature project that consists of a technical steering committee and maintainers for the project. Please comment and add your thoughts/suggestions.
The only thing that we have currently that is not supported by GitHub Packages is Python
+
+
+
Playground/Sandbox Hosting
+
We do not yet have a price for this, but following are some of the things that we could see needing a sandbox
+
Accessing server-side APIs
+
Deployment of server-based reference wallet
+
Interop testing
+
Reference implementation of data objects that a wallet contain - example VC issuance and verification
+
+
+
Harm mentioned that he has some information on the infrastructure costs for hosting the European Interoperability Test Bed, which was presented to the architecture SIG on March 27, 2023. Harm will provide information on these costs
+
Harm is also interested in bringing the Interoperability Test Bed as a project to the OWF
+
+
+
DevSecOps
+
The Linux Foundation is recommending that projects use GH Actions
David Alexander recommended that we include information about momentum and duty of care and working across the foundation
+
Stavros asked if a TSC is required for projects
+
No, a TSC is not mandatory. The idea is that if a project gets big enough where all the maintainers cannot get together easily and make decisions, more governance framework is needed, and this is the way to go in that case.
+
As such, we should make sure that this document provides the right level of guidance for projects at different stages in their lifecycle
If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up
How does this codebase relate to the energywebfoundation/ssi?
+
Does this proposal refer to the ssi repository OR only to work under the /vc-api path?
+
The intention is to bring over only the /vc-api path. We could consider whether it makes sense to bring over the other application, but it would require a separate proposal.
+
+
+
Are there dependencies or references to any implementation outside this folder that need attention if it is the latter?
+
Refer to the "Source Control" section of the proposal for information on what the dependencies are for the VC-API
+
+
+
Could we prepare a list of all the single repositories the vc-api needs and will be part of this proposal? I would also suggest supplementing this list with the purpose of these additional repos and their relationship/dependencies to vc-api.
+
This is captured in the "Source Control" section of the proposal.
+
+
+
For licensing purposes, will we leave related repositories in the organization they currently are? Should we expect a licensing conflict in this case?
+
John will follow up on the license with Energy Web Foundation.
+
+
+
What referenced tutorials and documentation will moved from energywebfoundation GitHub organization to the OWF?
+
Yes, we can move the tutorials and documentation into OWF.
+
+
+
+
+
Is this project an implementation of a VC API server or also client/wallet libraries?
+
Server only
+
+
+
Is this project based on the latest version of the CCG VC API? Does it already implement the full community report?
+
It implements the latest published version of the CCG VC API. It may be missing one or two endpoints. I don't think that we have implemented derived presentation.
+
+
+
Which credential formats and signature formats are supported?
+
Those that are supported by SpruceID's DIDKit
+
+
+
How have you tested interop?
+
We have not yet tested interop. The testing that we have done is with the available test suites.
+
+
+
What will be the prefix for this project?
+
We need to determine a way in which projects can be separated if they implement the same specification. Project prefixes are a way to do this and will allow us to trademark them in the future.
+
+
+
License
+
John to follow up with Energy Web Foundation about the possibility or re-licensing
+
Develop recommendation for the OWF governing board on licenses that are compatible with Apache 2.0
If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up
If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up
+
+
+
+
Open discussion and next steps
+
+
Next meeting is October 4, 2023
+
Discussed whether to move to weekly meetings to support influx of project proposals. It was determined that we could be more efficient on these calls if we commented on the PRs when they are submitted to get questions answered that may delay the vote.
Credential Format Comparison SIG meets bi-weekly on Wednesdays at 4pm CEST on alternate weeks to the TAC (next call October 11)
+
OID4VC Due Diligence task force meets bi-weekly on Tuesdays at 5pm CEST (next call October 24)
+
Architecture SIG meets weekly on Mondays at 11am US/Pacific (next call October 16)
+
Please submit any code proposals using the process defined at openwallet-foundation/project-proposals. We will review proposals in the order submitted at a TAC meeting. If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up.
Architecture SIG meets weekly on Mondays at 11am US/Pacific (next call October 30)
+
OID4VC Due Diligence task force meets bi-weekly on Tuesdays at 5pm CEST (next call October 24)
+
Safe Wallet SIG meets weekly on Tuesdays at 8am US/Pacific (next call October 24)
+
Credential Format Comparison SIG meets bi-weekly on Wednesdays at 4pm CEST on alternate weeks to the TAC (next call October 25)
+
Digital Wallets and Agents Overviews SIG meets biweekly on Thursdays at 5:00pm CEST on alternate weeks to the TAC (next meeting October 26)
+
Please submit any code proposals using the process defined at https://github.com/openwallet-foundation/project-proposals. We will review proposals in the order submitted at a TAC meeting. If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up.
Architecture SIG meets weekly on Mondays at 11am US/Pacific (next call November 6)
+
OID4VC Due Diligence task force meets bi-weekly on Tuesdays at 5pm CEST (next call November 7)
+
Safe Wallet SIG meets weekly on Tuesdays at 8am US/Pacific (next call November 7)
+
Credential Format Comparison SIG meets bi-weekly on Wednesdays at 4pm CEST on alternate weeks to the TAC (next call November 8)
+
Digital Wallets and Agents Overviews SIG meets biweekly on Thursdays at 5:00pm CEST on the same weeks as the TAC (next meeting November 2)
+
Please submit any code proposals using the process defined at https://github.com/openwallet-foundation/project-proposals. We will review proposals in the order submitted at a TAC meeting. If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up.
Update project proposal template to make it easier for people to understand what the TAC is expecting for answers related to each question -- Tracy -- completed
Architecture SIG meets weekly on Mondays at 11am US/Pacific (next call November 27; skipping week of US Thanksgiving)
+
OID4VC Due Diligence task force meets bi-weekly on Tuesdays at 5pm CET (next call November 21)
+
Safe Wallet SIG meets weekly on Tuesdays at 8am US/Pacific (next call November 21)
+
Credential Format Comparison SIG meets bi-weekly on Wednesdays at 4pm CET on alternate weeks to the TAC (next call November 22)
+
Digital Wallets and Agents Overviews SIG meets biweekly on Thursdays at 5:00pm CET on the same weeks as the TAC (next meeting November 16)
+
Please submit any code proposals using the process defined at https://github.com/openwallet-foundation/project-proposals. We will review proposals in the order submitted at a TAC meeting. If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up.
Update "permissive license" to "OSI-approved permissive license" in the project lifecycle and template PRs – completed and merged (lifecycle PR 69 and template PR 22)
+
Update Paid Tooling PR to reflect other requests require the Governing Board approval – completed and merged
+
Onboarding SD-JWT JS lab
+
Create sd-jwt-js repo in OpenWallet Foundation Labs GitHub – completed
Architecture SIG meets weekly on Mondays at 11am US/Pacific (next call December 4)
+
OID4VC Due Diligence task force meets bi-weekly on Tuesdays at 5pm CET (next call December 5)
+
Safe Wallet SIG meets weekly on Tuesdays at 7am US/Pacific (next call December 5)
+
Credential Format Comparison SIG meets bi-weekly on Wednesdays at 4pm CET on alternate weeks to the TAC (next call December 6)
+
Digital Wallets and Agents Overviews SIG meets biweekly on Thursdays at 5:00pm CET on the same weeks as the TAC (next meeting November 30)
+
Please submit any code proposals using the process defined at https://github.com/openwallet-foundation/project-proposals. We will review proposals in the order submitted at a TAC meeting. If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up
Architecture SIG meets weekly on Mondays at 11am US/Pacific (next call January 8)
+
OID4VC Due Diligence task force meets bi-weekly on Tuesdays at 5pm CET (next call December 19)
+
Safe Wallet SIG meets weekly on Tuesdays at 7am US/Pacific (next call December 19)
+
Credential Format Comparison SIG meets bi-weekly on Wednesdays at 4pm CET on alternate weeks to the TAC (next call December 20)
+
Digital Wallets and Agents Overviews SIG meets biweekly on Thursdays at 5:00pm CET on the same weeks as the TAC (next meeting December 14)
+
Please submit any code proposals using the process defined at https://github.com/openwallet-foundation/project-proposals. We will review proposals in the order submitted at a TAC meeting. If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up
Also include in the accomplishments the face-to-face and the discussion with LF Legal on project charters
+
+
+
Retrospective
+
Shoutouts?
+
Google for hosting us at our face-to-face in Mountain View
+
Tracy for leading meetings
+
SIG and Task Force leaders
+
+
+
What went well?
+
Good structure on the TAC
+
Opportunity to collaborate
+
Consistency of how TAC meetings are managed and the access to the information needed so that you can do prep
+
Transparency
+
Inclusiveness
+
Team spirit
+
Advocacy
+
Provided confidence to move from being a consumer of open source to actually publishing open source at OWF
+
Learning process of what's involved in open source has been incredibly useful
+
Collaboration
+
Donation
+
Strong community engagement
+
Support OpenWallet has received in terms of projects, sponsors and Governmental Advisory Council members
+
+
+
What could we do differently next year?
+
Include voting members on the agenda and let people know who can vote at these meetings
+
+
+
Recommendations for next year
+
List of events for next year -- include in the #events channel on Discord
+
Creating a resource of slides that others have presented at conferences to present OWF
+
Challenge: helping projects grow within the OWF
+
Challenge: helping projects collaborate and work with one another
+
Engaging with the EUDI and bringing projects into OWF
+
Interoperability is a topic for us to focus on next year. Not just for the same protocols, but also across protocols. SIDI is also something that we should work closely with
+
Publish a white paper documenting our overall architectural considerations for open wallets (started already in the Architecture SIG)
Architecture SIG meets weekly on Mondays at 11am US/Pacific (next call January 15)
+
OID4VC Due Diligence task force meets bi-weekly on Tuesdays at 5pm CET (next call January 17)
+
Safe Wallet SIG meets weekly on Tuesdays at 7am US/Pacific (next call January 16)
+
Credential Format Comparison SIG meets bi-weekly on Wednesdays at 4pm CET on alternate weeks to the TAC (next call January 17)
+
Digital Wallets and Agents Overviews SIG meets biweekly on Thursdays at 5:00pm CET on the same weeks as the TAC (next meeting January 11)
+
Please submit any code proposals using the process defined at https://github.com/openwallet-foundation/project-proposals. We will review proposals in the order submitted at a TAC meeting. If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up
Where can I get information on the Architecture SIG?
+
How do I participate in the Architecture SIG?
+
+
+
Discussion on how the Architecture SIG should work with projects
+
In general, people see the role of the architecture SIG as a group that provides information on the state of the digital wallet architectues that can be used to provide insight into projects that may be missing from the OWF and in the long term a place that will help projects work more closely together.
Architecture SIG meets weekly on Mondays at 11am US/Pacific (next call January 29)
+
OID4VC Due Diligence task force meets bi-weekly on Tuesdays at 5pm CET (next call January 30)
+
Safe Wallet SIG meets weekly on Tuesdays at 7am US/Pacific (next call January 30)
+
Credential Format Comparison SIG meets bi-weekly on Wednesdays at 4pm CET on alternate weeks to the TAC (next call January 31)
+
Digital Wallets and Agents Overviews SIG meets biweekly on Thursdays at 5:00pm CET on the same weeks as the TAC (next meeting January 25)
+
Please submit any code proposals using the process defined at https://github.com/openwallet-foundation/project-proposals. We will review proposals in the order submitted at a TAC meeting. If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up
Architecture SIG meets weekly on Mondays at 11am US/Pacific (next call February 12)
+
OID4VC Due Diligence task force meets bi-weekly on Tuesdays at 5pm CET (next call February 13)
+
Safe Wallet SIG meets weekly on Tuesdays at 7am US/Pacific (next call February 13)
+
Credential Format Comparison SIG meets bi-weekly on Wednesdays at 4pm CET on alternate weeks to the TAC (next call February 14)
+
Digital Wallets and Agents Overviews SIG meets biweekly on Thursdays at 5:00pm CET on the same weeks as the TAC (next meeting February 8)
+
Please submit any code proposals using the process defined at https://github.com/openwallet-foundation/project-proposals. We will review proposals in the order submitted at a TAC meeting. If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up
Architecture SIG meets weekly on Mondays at 11am US/Pacific (next call February 26)
+
OID4VC Due Diligence task force meets bi-weekly on Tuesdays at 5pm CET (next call February 27)
+
Safe Wallet SIG meets weekly on Tuesdays at 7am US/Pacific (next call February 27)
+
Credential Format Comparison SIG meets bi-weekly on Wednesdays at 4pm CET on alternate weeks to the TAC (next call February 28)
+
Digital Wallets and Agents Overviews SIG meets biweekly on Thursdays at 5:00pm CET on the same weeks as the TAC (next meeting February 22)
+
Please submit any code proposals using the process defined at https://github.com/openwallet-foundation/project-proposals. We will review proposals in the order submitted at a TAC meeting. If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up
Our current project lifecycle does not clearly outline the steps necessary for projects to progress in the lifecycle.
+
Suggested changes to the lifecycle to create a PR to update the original project proposal to include the new stage and other information relevant to meet the proposed stage’s criteria.
+
Upside: This process is similar to the original project proposal process.
+
Possible Downside: This will overwrite the original proposal but might not be a concern given the history in GitHub on the file.
+
If we do a PR to the original proposal, we will need to make sure that we can have links to the previous versions that were approved.
+
We can possibly do this via the project pages by adding a new section
+
Action: Tracy to create a PR to provide details on what this will look like.
Architecture SIG meets weekly on Mondays at 11am US/Pacific (next call March 11)
+
OID4VC Due Diligence task force meets bi-weekly on Tuesdays at 5pm CET (next call March 12)
+
Safe Wallet SIG meets weekly on Tuesdays at 7am US/Pacific (next call March 12)
+
Credential Format Comparison SIG meets bi-weekly on Wednesdays at 4pm CET on alternate weeks to the TAC (next call March 13)
+
Digital Wallets and Agents Overviews SIG meets biweekly on Thursdays at 5:00pm CET on the same weeks as the TAC (next meeting March 7)
+
Please submit any code proposals using the process defined at https://github.com/openwallet-foundation/project-proposals. We will review proposals in the order submitted at a TAC meeting. If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up
+
Reminder: Elections are coming up starting March 20, 2024; we will be accepting TAC “at large” nominations
Architecture SIG meets weekly on Mondays at 11am US/Pacific (next call March 25)
+
OID4VC Due Diligence task force meets bi-weekly on Tuesdays at 5pm CET (next call March 26)
+
Safe Wallet SIG meets weekly on Tuesdays at 7am US/Pacific (next call March 26)
+
Credential Format Comparison SIG meets bi-weekly on Wednesdays at 4pm CET on alternate weeks to the TAC (next call March 27)
+
Digital Wallets and Agents Overviews SIG meets biweekly on Thursdays at 5:00pm CET on the same weeks as the TAC (next meeting March 21)
+
Please submit any code proposals using the process defined at https://github.com/openwallet-foundation/project-proposals. We will review proposals in the order submitted at a TAC meeting. If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up
Question asked about how to get sponsors for the SD-JWT JavaScript project to move to Growth - reach out to the TAC members (individually, on the #tac Discord channel, or on the TAC mailing list)
+
Question asked about how to find out what was going on in the community and how to get involved:
Architecture SIG meets weekly on Mondays at 11am US/Pacific (next call April 8)
+
OID4VC Due Diligence task force meets bi-weekly on Tuesdays at 5pm CET (next call April 9)
+
Safe Wallet SIG meets weekly on Tuesdays at 7am US/Pacific (next call April 9)
+
Credential Format Comparison SIG meets bi-weekly on Wednesdays at 4pm CET on alternate weeks to the TAC (next call April 10)
+
Digital Wallets and Agents Overviews SIG meets biweekly on Thursdays at 5:00pm CET on the same weeks as the TAC (next meeting April 4)
+
Please submit any code proposals using the process defined at https://github.com/openwallet-foundation/project-proposals. We will review proposals in the order submitted at a TAC meeting. If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up
+
Jorge Flores (Co-Founder & CTO of Entidad) and Jesus Torres (Co-Founder & CEO of Entidad): How an Aries digital trust ecosystem helped distribute $60M USD (& counting) to essential workers - Presenting at the Hyperledger Identity Special Interest Group on Thursday, April 4 @ 3PM UTC, 8AM PDT, 9AM MDT, 11AM EDT. Join on Zoom: https://zoom.us/j/93003523877?pwd=Q3VvMnJ1N0lSUEZSc283SmFGRk9SQT09
+
IIW Planning discussion taking place on Discord in the #iiw-planning channel
+
EIC Planning discussions taking place on Discord in the #eic-planning channel
Only TAC voting members are eligible to run for the TAC chair and vice chair seats
+
Electing a vice chair will be held in conjunction with the chair election; the person with the second highest number of votes will serve as the vice chair
Architecture SIG meets weekly on Mondays at 11am US/Pacific (next call April 22)
+
OID4VC Due Diligence task force meets bi-weekly on Tuesdays at 5pm CET (next call April 23)
+
Safe Wallet SIG meets weekly on Tuesdays at 7am US/Pacific (next call April 23)
+
Credential Format Comparison SIG meets bi-weekly on Wednesdays at 4pm CET on alternate weeks to the TAC (next call April 24)
+
Digital Wallets and Agents Overviews SIG meets biweekly on Thursdays at 5:00pm CET on the same weeks as the TAC (next meeting April 18)
+
Please submit any code proposals using the process defined at https://github.com/openwallet-foundation/project-proposals. We will review proposals in the order submitted at a TAC meeting. If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up
+
EIC Planning discussions taking place on Discord in the #eic-planning channel
+
The Hyperledger Identity SIG (ID SIG) recently hosted Jorge and Jesus from Entidad for "How The Aries Digital Trust Ecosystem Helped Distribute $60M USD (and counting) to Essential Workers. You can check out the recording on YouTube.
Architecture SIG meets weekly on Mondays at 11am US/Pacific (next call May 6)
+
OID4VC Due Diligence task force meets bi-weekly on Tuesdays at 5pm CET (next call May 7)
+
Safe Wallet SIG meets weekly on Tuesdays at 7am US/Pacific (next call May 7)
+
Credential Format Comparison SIG meets bi-weekly on Wednesdays at 4pm CET on alternate weeks to the TAC (next call May 8)
+
Digital Wallets and Agents Overviews SIG meets biweekly on Thursdays at 5:00pm CET on the same weeks as the TAC (next meeting May 2)
+
Please submit any code proposals using the process defined at https://github.com/openwallet-foundation/project-proposals. We will review proposals in the order submitted at a TAC meeting. If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up
+
EIC Planning discussions taking place on Discord in the #eic-planning channel
Input from community - please provide comments on the PR
+
Add a heatmap that maps our current projects to the technology capabilities
+
+
+
David Z is concerned that the whitepaper may conflict with existing guidance
+
Request that a list of existing guidance be provided in the PR so that we may validate that the reference architecture whitepaper does not conflict with existing guidance
Architecture SIG meets weekly on Mondays at 11am US/Pacific (next call June 3)
+
Safe Wallet SIG meets weekly on Tuesdays at 7am US/Pacific (next call June 4)
+
Credential Format Comparison SIG meets bi-weekly on Wednesdays at 4pm CET on alternate weeks to the TAC (next call June 5)
+
Digital Wallets and Agents Overviews SIG meets biweekly on Thursdays at 5:00pm CET on the same weeks as the TAC (next meeting May 30)
+
Please submit any code proposals using the process defined at https://github.com/openwallet-foundation/project-proposals. We will review proposals in the order submitted at a TAC meeting. If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up
+
EIC Planning discussions taking place on Discord in the #eic-planning channel
+
+
+
+
Welcome new TAC member
+
+
Rolson Quadras will represent Gen Digital moving forward
Unanimously approved by the present TAC voting members.
+
+
+
+
+
+
Project Proposal: Trust Spanning Protocol
+
+
Discussed the need for language bindings that can be used by OWF projects. Recommendation is to implement the language bindings in conjunction with the projects that will use it to ensure correctness.
Please submit any code proposals using the process defined at https://github.com/openwallet-foundation/project-proposals. We will review proposals in the order submitted at a TAC meeting. If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up
+
EIC Planning discussions taking place on Discord in the #eic-planning channel
+
If you are interested in participating in the architecture SIG calls, we have a when2meet survey out there to find a new meeting time
OpenWallet Foundation is hosting two workshops -- one for OpenID Connect for VCI and one for OpenID Connect for VP -- on June 10th and June 12th. Please be on the lookout for registration links coming soon
TAC meetings are intended to be open to observe by Sponsors, contributors to any TAC Project, and others in the general public interested in the OpenWallet Foundation.
+
The meetings will be held bi-weekly starting Wednesday, March 8, 2023 at 7:00am PT.
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.
+
Key Features and Benefits:
+
+
+
Unified Digital Identity Management: Emphasizing security and user-friendliness, 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.
+
+
+
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.
+
+
+
Community-Driven Development: 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.
+
+
+
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.
+
+
+
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.
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:
+- As a user I can use multiple clients where my data is synced, we do not have to care about backups or data recovery.
+- As a developer I can implement the business logic into the cloud and only need the rendering on the client side.
+
Yes, when I am offline, I do not have access to my data anymore. But beside that the user experience is great!
+
The credhub project is a typescript based monorepo, using nx to manage multiple components. Compared to other approaches, it also comes with an issuer and verifier service to issue and verify credentials.
There are two clients that can be used to interact with a cloud wallet
+- a PWA based on Angular
+- a Chrome Browser Extension based on Angular
+
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.
+
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 server for that.
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.
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.
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.
+
Credential Profile:
+
+
Credential Format: SD-JWT-VC
+
Key Management (issuer): VC-ISSUER Meta data, DID, X509
Credo 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.
+
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.
+
The future direction for Credo 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.
+
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) was chosen as a steward due to its commitment to promoting interoperability without directly developing or maintaining standard protocols.
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 engine that makes it easier for farmworker communities to access an ecosystem of life-altering social and human services.
+
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.
+
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.
+
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.
+
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.
+
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 in one-time relief payments to over 125,000 workers, under the United States Department of Agriculture’s Farm and Food Workers Relief Program (FFWR).
+
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-based communication capabilities such as text and video chat.
+
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, Hyperledger Aries JS Working Group, and various other communities, including DID Communication Working Group and OpenWallet Foundation of late, to ensure we adhere to best practices and standards.
+
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.
+
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.
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.
+
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.
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.
+
There are design-time and runtime aspects of app development but one of the great things about this tooling is that there is clean separation between the two.
+
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.
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 developer workstation.
Libraries and reference applications for working with real-world identity.
+
The initial focus for this work was mdoc/mDL according to ISO/IEC 18013-5:2021
+and related standards (mainly ISO 23220 series and ISO 18013-7) on Android. Current focus
+includes other credential formats and operating environments.
The project includes two libraries written in Java and Kotlin. The
+first is identity which provides the core building blocks and which
+can also be used on server-side environments. The other is identity-android
+which provides Android-specific extensions to the former. It is designed to
+run on Android (API 24 or later) and will take advantage of Android-specific
+features including hardware-backed Keystore, NFC, Bluetooth
+Low Energy, and so on.
+
The libraries are intended to be used by Wallet Applications (mobile
+applications on the credential holder's device), Reader Applications (applications
+operated on device controlled by the verifier), and Issuance Systems (applications
+operated by the credential issuer or their agent). They provide the following
+building blocks
+
+
A light-weight Secure Area abstraction for hardware-backed keystore
+
Applications can create hardware-backed Elliptic Curve Cryptography
+ keys which can be used for creating Signatures or performing Key Agreement.
+ Each key will have an attestation which can be used to prove to Relying Parties
+ (such as a credential issuer) that the private part of the key only exists
+ in a Secure Area.
+
The identity-android library includes an implementation based on
+ Android Keystore
+ with support for requiring user authentication (biometric or lock-screen knowledge
+ factor, e.g. system PIN) for unlocking the key and also can use
+ StrongBox
+ if available on the device. This is appropriate to use in Android applications
+ implementing ISO/IEC 18013-5:2021 for storing DeviceKey.
+
The identity library includes an implementation backed by BouncyCastle
+ with support for passphrase-protected keys. This isn't suitable for use
+ in Mobile Applications as its not backed by Secure Hardware.
+
Applications can supply their own Secure Area implementations for e.g.
+ externally attached dongles, cloud based HSMs, or whatever the issuer
+ deems appropriate to protect key material associated with their credential.
+
+
+
A Credential Store for storage of one or more Credentials
+
Each Credential has a Credential Key which can be used by the issuer
+ to bind a credential to a specific device which is useful when
+ issuing updates or refreshing a credential.
+
Additionally, each Credential has one or more Authentication Keys which
+ can be endorsed by the issuer and used at presentation time.
+
Finally, namespaced data and arbitrary key/value pairs can be stored
+ in a Credential which can be used for credential data and claims. This
+ data is stored encrypted at rest.
+
+
+
Data structures and code for provisioning of mdoc/mDLs
+
This code can can be used both on the device and issuer side. No networking
+ protocol is defined, the application has to define its own.
+
+
+
Parsers and generators for all data structures used in ISO/IEC 18013-5:2021
+ presentations, including DeviceResponse, DeviceRequest, MobileSecurityObject
+ and many other CBOR data structures.
+
An implementation of the ISO/IEC 18013-5:2021 presentation flows including
+ QR engagement, NFC engagement (both static and negotiated), device retrieval
+ (BLE, Wifi Aware, and NFC)
This repository also contains two Android applications using this library
+in the appholder and appverifier modules. The Wallet application is a simple
+self-contained application which allows creating a number of mdoc credentials
+using four different mdoc Document Types:
nl.rdw.mekb.1: mdoc for Vehicle Registration (link)
+
eu.europa.ec.eudiw.pid.1: mdoc for Personal Identification
+
+
and their associated mdoc name spaces. The first one is defined in
+ISO/IEC 18013-5:2021 and the other three have been used at mdoc/mDL
+test events organized by participants of the ISO/IEC JTC1 SC17 WG10
+working group.
The wwwverifier module contains the source code for a website acting as an
+mdoc reader according to the latest ISO 18013-7 working draft (as of Sep 2023)
+and it's implementing the so-called REST API. There is currently a test instance
+of this application available at https://mdoc-reader-external.uc.r.appspot.com/.
+The Wallet Android application also has support for the REST API and registers
+on Android for the mdoc:// URI scheme. This can be tested end-to-end by going
+to the reader website (URL above) and clicking on one of the "Request" buttons,
+and then hitting the mdoc:// link presented on the site. This will cause the
+browser to invoke the Wallet app which will then connect to the reader and send
+the credential after user consent.
Projects in the OpenWallet Foundation follow the project lifecycle. This page lists the active projects within the OpenWallet Foundation and their current lifecycle stage.
Support for multiple data types for disclosed values including
+
+
String
+
Int
+
Boolean
+
Array of Strings - [String]
+
Dictionary of String keys and String values - [String:String]
+
+
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.
Copy this template to the subdirectory for the current year and name the file YYYY-project-name-annual.md (e.g., 2024-amazingproj-annual.md). Update the title above to replace YYYY with the year of the annual review and PROJECT NAME with the name of the project. Update the index.md file in the current year to include a link to the markdown file. These blocks are instructions. Please remove when section has been completed.
Include information about your project's contributions and activity. You can find information within GitHub by looking at the Insights tab. We will be looking for signs of consistent or increasing contribution activity. Please feel free to add commentary to add color to this information.
How many maintainers do you have, and which organisations are they from? How has the maintainers and diversity of your maintainers changed in the past year? Has the number of active maintainers increased/decreased? Has the diversity of maintainers increased/decreased? Please include a link to your existing MAINTAINERS file and the MAINTAINERS file from last year (if appropriate). This is a good opportunity to ensure that your MAINTAINERS file is up to date and to retire any maintainers.
What do you know about adoption, and how has this changed since your last review or since being accepted into OpenWallet Foundation? If you can list companies that are adopters of your project, please do so. Feel free to link to an existing ADOPTERS file if appropriate.
Include information about the goals that you previously set for the project in the last review or since the project proposal has been approved. How has the project performed against these goals? If your goals changed from your previous annual report, let us know what changed and why. If you have not achieved the goals that you set out, that is okay. We want to know what you have accomplished and what challenges the project is having in meeting the goals.
What are the goals for the next year of the project? The goals should list what you want to achieve, not just what you know you can achieve. Feel free to include stretch goals and things that you are looking to explore in the next year. For example, are you working on major new features? Or are you concentrating on adoption, community growth, or documentation?
Projects must provide an annual review to the TAC to ensure that the project is still active and in the correct lifecycle stage. The following calendar provides the timing for when these reviews are required to be presented to the TAC:
Projects must provide an annual review to the TAC to ensure that the project is still active and in the correct lifecycle stage. The following calendar provides the timing for when these reviews are required to be presented to the TAC:
This is the reference implementation of the IETF SD-JWT specification maintained by the editors of the specification together with other contributors. It is written in Python.
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."
+
A shorter introduction of TSP can be found in this blog post.
+
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.
+
In addition, we may add and welcome trust task or application specific extensions.
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.
+
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/).
+
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.
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.
+
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.
+
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.
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/search/search_index.json b/search/search_index.json
new file mode 100644
index 00000000..c20fc6ce
--- /dev/null
+++ b/search/search_index.json
@@ -0,0 +1 @@
+{"config":{"lang":["en"],"separator":"[\\s\\-]+","pipeline":["stopWordFilter"],"fields":{"title":{"boost":1000.0},"text":{"boost":1.0},"tags":{"boost":1000000.0}}},"docs":[{"location":"","title":"Home","text":"
Welcome to the OpenWallet Foundation's (OWF) Technical Advisory Council (TAC) website. Here you will find:
What is the TAC
Learn more about the Technical Advisory Council's role, responsibilities, and voting members
Governing Documents
Review the OpenWallet Foundation TAC Governing Documents
TAC Meetings
See meeting invite details and meeting notes from past meetings
Projects
Explore the OpenWallet Foundation Projects
Special Interest Groups
Join an OpenWallet Foundation Special Interest Groups (SIGs)
Task Forces
Work on an OpenWallet Foundation Task Forces
"},{"location":"SIGs/","title":"Special Interest Groups (SIGs)","text":"
A special interest group (SIG) under the Technical Advisory Council (TAC) is a group with a shared interest in advancing a specific area of knowledge, learning, or technology related to the mission of the OpenWallet Foundation where members cooperate to affect or to produce solutions within their particular field. Unlike a task force, SIGs are typically long running and may or may not produce any deliverables. A SIG can be created by anyone in the OpenWallet Foundation community and must be proposed to and approved by the TAC.
Tip
If you would like to propose a Special Interest Group, please see the SIG proposal process.
This SIG is an open group. Anyone in the OpenWallet Foundation community can join and participate. There is no formal sign up process. Just show up and participate.
The architecture SIG meets weekly on Mondays at 11:00 AM US/Pacific time. For details, see architecture SIG meeting details. For past notes and recordings, see the architecture SIG wiki.
Please join the OpenWallet Foundation Discord and participate in the discussion in the #architecture-sig channel.
"},{"location":"SIGs/credential-format-comparison/","title":"Credential Format Comparison Special Interest Group (SIG)","text":"
This SIG is dedicated to maintaining information about available credential formats for the benefit of OWF projects and the wider community. The topic is more complex than one might assume on first sight, since there are more than 14 formats for representing digital credentials and most of those formats can be combined with different signature algorithms, ways to represent cryptographic keys (with alone more than a hundred DID methods), status management methods, trust management methods and so on.
There is pre-existing work started at Internet Identity Workshop (IIW 34, Spring 2022) and extended and augmented during Rebooting the Web of Trust (RWOT-XI, The Hague, Sept 2022).
It consists of a \u201ccredential format comparison matrix\u201d, containing information about the technical options in the different dimensions (formats, signature algorithms, \u2026) as well as known credential profiles, i.e. concrete combinations used in implementations and an article explaining the \u201cmatrix\u201d.
This SIG is an open group. Anyone in the OpenWallet Foundation community can join and participate. There is no formal sign up process. Just show up and participate.
If you are interested in participating, please join the OpenWallet Foundation Discord and participate in the discussion in the #credential-format-comparison-sig channel.
"},{"location":"SIGs/digital-wallet-and-agent-overviews/","title":"Digital Wallet and Agent Overviews Special Interest Group (SIG)","text":"
The objectives of this SIG is to further develop and maintain the Digital Wallet Overview and making a similar overview for digital identity agents/SDKs. These overviews should provide transparency of the characteristics of wallets and agents in order to allow for comparison and effective decision making on which wallet is applicable for your use case. By creating awareness of these overviews, this work can lead to less fragmentation of the SSI playing field and increase adoption.
This SIG was accepted by the TAC on September 20, 2023. See Digital Wallet and Agent Overviews SIG Proposal for more details.
This SIG is an open group. Anyone in the OpenWallet Foundation community can join and participate. There is no formal sign up process. Just show up and participate.
If you are interested in participating, please join the OpenWallet Foundation Discord and participate in the discussion in the #digital-wallet-and-agent-overviews-sig channel.
"},{"location":"SIGs/safe-wallet/","title":"Safe Wallet Special Interest Group (SIG)","text":"
This SIG will create, distribute and promote a set of material that will become the de-facto way to determine how \"safe\" the new breed of digital wallets is, and be able to compare them effectively. This will increase the visibility of the solutions to correlation and profiling issues that could be introduced with digital wallet deployments.
This SIG was accepted by the TAC on September 20, 2023. See Safe Wallet SIG Proposal for more details.
This SIG is an open group. Anyone in the OpenWallet Foundation community can join and participate. There is no formal sign up process. Just show up and participate.
If you are interested in participating, please join the OpenWallet Foundation Discord and participate in the discussion in the #safe-wallet-sig channel.
The Special Interest Groups (SIGs) must provide a quarterly update to the TAC to ensure that the SIG is still active and that there is still value in hosting the special interest group. The following calendar provides the timing for when these updates are required to be presented to the TAC:
Quarter Special Interest Group TAC Meeting Q1 Architecture SIG 2024-01-10 Q1 Credential Format Comparison SIG 2024-02-07 Q1 Digital Wallet and Agent Overviews SIG 2024-02-21 Q1 Safe Wallet SIG 2024-03-06 Q2 Architecture SIG 2024-04-03 Q2 Credential Format Comparison SIG 2024-05-01 Q2 Digital Wallet and Agent Overviews SIG7 2024-05-29 Q2 Safe Wallet SIG 2024-06-12 Q3 Architecture SIG 2024-07-10 Q3 Credential Format Comparison SIG 2024-07-24 Q3 Digital Wallet and Agent Overviews SIG 2024-08-07 Q3 Safe Wallet SIG 2024-08-21 Q4 Architecture SIG 2024-10-02 Q4 Credential Format Comparison SIG 2024-10-16 Q4 Digital Wallet and Agent Overviews SIG 2024-10-30 Q4 Safe Wallet SIG 2024-11-13"},{"location":"governance/","title":"Governing Documents","text":"
The following are the governing documents used by the OpenWallet Foundation's Technical Advisory Council.
A TAC voting member may designate an alternate for a specific meeting, and must notify the chair in advance of the meeting. The TAC voting member is responsible for ensuring that the named alternate has enough information to represent the TAC voting member in all matters that will be covered in the meeting. The named alternate will participate in any votes that occur during the meeting for which they were named an alternate, and their vote will count as if it were cast by the TAC voting member.
Warning
If a TAC voting member regularly names an alternate and
is a TAC Premier Sponsor Representative, then that TAC voting member should consider whether they should replace themselves with the alternate, or
is a TAC \"At Large\" Representative, then that TAC voting member should consider whether they should resign.
OpenWallet Foundation very much appreciates the contributions of the community; however, it is important to archive source repositories that have become inactive in order to ensure that others in the community are not using code or reporting issues on a repository that is not being maintained.
Any repository that has not had a release for 12 months or that has had no commits for 6 months may be archived.
Projects will be notified via a PR in the appropriate repository, as well as a notice in the project appropriate Discord channel and mailing list, if they exist.
Generally speaking if the project's maintainers request to keep the repository active, the request will be honored. However if the repository has a lot of out of date dependencies, particulaly ones relating to security vulnerabilites, this request may not be honored.
A request by the project's maintainers to un-archive a repository for the purposes of active contribution will be honored, unless the project is in an emeritus stage. In those cases the project lifecycle issues will need to be resolved first.
"},{"location":"governance/charter/","title":"OpenWallet Foundation Charter","text":"
Exhibit B
The OpenWallet Foundation Charter
Linux Foundation Europe
Effective May 22, 2023
Mission and Scope of the OpenWallet Foundation.
The purpose of the OpenWallet Foundation (the \u201cOWF\u201d) is to support various open source, open data and/or other open projects relating to or supporting development of digital wallets, including infrastructure and support initiatives related thereto (each such project, a \u201cTechnical Project\u201d) , in accordance with the provisions of this Charter. The governance of each Technical Project is as set forth in the charter for that Technical Project.
The OWF aims to enable entities to transact securely, and in a privacy enhancing fashion, in- person and on-line where attributes stored in, and managed by, the wallet. The OWF will:
develop and maintain open source code for wallets to enable and ensure wallet interoperability,
advocate for the adoption of the interoperable digital wallet technology, and
collaborate with Standards Development Organizations (SDOs) in the development and proliferation of open standards related to digital wallets
The OWF will not publish a publicly available wallet (including into any application stores).
The OWF supports the Technical Projects. The OWF operates under the guidance of the Governing Board of the OWF (the \u201cGoverning Board\u201d) and Linux Foundation Europe (the \u201cLFEU\u201d) as may be consistent with Linux Foundation Europe\u2019s tax-exempt status.
The Governing Board manages the OWF. The Governing Board may establish other committees and other working groups (collectively, and including the Technical Advisory Council, \u201cCommittees\u201d) which will report to the Governing Board.
Sponsorship.
The OWF will be composed of Premier, General and Associate Sponsors (each, a \u201cSponsor\u201d and, collectively, the \u201cSponsors\u201d) in Good Standing. All Sponsors must be current Sponsors of LFEU (at any level) to participate in the OWF as a Sponsor. All sponsors in the OWF, enjoy the privileges and undertake the obligations described in this Charter, as from time-to-time amended by the Governing Board, with the approval of LFEU. During the term of their sponsorship, all Participants will comply with all such policies as the LFEU Board of Directors and/or the OWF may adopt with notice to Sponsors.
Premier Sponsors will be entitled to appoint a representative to the Governing Board and any Committee.
General Sponsors, acting as a class, will be entitled to annually elect one representative to the Governing Board for every ten General Sponsors, up to a maximum of three total representatives, provided that there will always be at least one General Sponsor representative, even if there are less than ten General Sponsors. The Governing Board determines the General Sponsor representative election process.
The Associate Sponsor category of sponsorship is limited to Associate Sponsors of LFEU. The Governing Board may set additional criteria for sponsoring the OWF as an Associate Sponsor. If the Associate Sponsor is itself a membership or participation organization, Associate Sponsorship in the OWF does not confer any privileges or rights to the members or participants of the Associate Sponsor.
Sponsors will be entitled to:
participate in OWF general meetings, initiatives, events and any other activities; and
identify themselves as sponsors of the OWF supporting the OWF community.
Governing Board
The Governing Board voting members will consist of:
one representative appointed by each Premier Sponsor;
the TAC Representative (as defined below), or, in the absence of a chair and with the approval of the Governing Board, any active contributor to a Technical Project so designated by the TAC (such chair or designee the \u201cTAC Representative\u201d); and
the elected General Sponsor representative or representatives.
The Governing Board will also include nonvoting members consisting of the GAC Representative (defined in Section 4) and Associate Representative.
The Associate Representative will be chosen based on their efforts and potential to advance the OWF mission. The Associate Representative will be selected by the Governing Board voting representatives through a process determined by the Governing Board.
Only one Sponsor that is part of a group of Related Companies (as defined in Section 7) may appoint, or nominate for a sponsorship class election, a representative on the Governing Board. No single Sponsor, company or set of Related Companies will be entitled to: (i) appoint or nominate for sponsorship class election more than one representative for the Governing Board, or (ii) have more than two representatives on the Governing Board.
The only path to two representatives from the same group of Related Companies that will be acceptable will be for one Sponsor to appoint or nominate a representative to the Governing Board and have another of its employees, or an employee of one of its Related Companies, serve as the TAC Representative on the Governing Board.
Conduct of Meetings
Governing Board meetings will be limited to the Governing Board representatives, the Outreach Committee Chair, invited guests and OWF staff.
Governing Board meetings follow the requirements for quorum and voting outlined in this Charter. The Governing Board may decide whether to allow named representatives (one per Sponsor per Governing Board and per Committee) to attend as an alternate.
The Governing Board meetings will be private unless decided otherwise by the Governing Board. The Governing Board may invite guests to participate in consideration of specific Governing Board topics (but such guests may not participate in any vote on any matter before the Governing Board).
Officers
The officers (\u201cOfficers\u201d) of the OWF as of the first meeting of the Governing Board will be a Chairperson (\u201cChair\u201d) and a Treasurer. Additional Officer positions may be created by the Governing Board.
The Chair will preside over meetings of the Governing Board, manage any day-to-day operational decisions, and will submit minutes for Governing Board approval.
The Treasurer will assist in the preparation of budgets for Governing Board approval, monitor expenses against the budget and authorize expenditures approved in the budget.
The Governing Board will be responsible for overall oversight of the OWF, including:
approve a budget directing the use of funds raised by the OWF from all sources of sponsorship or other revenue, including to pay for the hiring of OWF leadership and staff;
vet and select a qualified leadership team to run the day-to-day management activities of the organization and evaluate the performance of the team;
provide feedback and input to the OWF leadership team responsible for planning and managing the day-to-day operation of the OWF;
maintain, if desired, a guiding principles document;
nominate and elect Officers of the OWF;
supervise and support the leadership team on OWF business and community outreach matters;
work with the LFEU on any legal matters that arise;
adopt and maintain policies or rules and procedures for the OWF (subject to LFEU\u2019s approval);
establish advisory bodies, committees, programs or councils to resolve any particular matter or in support of the mission of the OWF and/or its Technical Projects including in support of end-users and ambassadors for the project any Technical Project;
establish any OWF conformance programs for its trademarks and solicit input (including testing tools) if deemed necessary from the applicable oversight body of any Technical Project for defining and administering any programs related to conformance with such Technical Project (each, a \u201cConformance Program\u201d);
publish use cases, user stories, websites and priorities to help inform the ecosystem and technical community;
approve procedures for the nomination and election of any representative of the General Sponsors to the Governing Board and any Officer or other positions created by the Governing Board; and
vote on all decisions or matters coming before the Governing Board.
Government Advisory Council
The Government Advisory Council (the \u201cGAC\u201d) will provide the OWF advice from government entities approved to participate by the Governing Board. Members of the GAC must be national governments, multinational governmental organizations and treaty organizations, or public authorities. Each may appoint one representative and one alternate representative to the GAC. There are no fees to participate in the GAC.
The GAC will provide advice to OWF on issues of public policy, and especially where there may be an interaction between OWF's activities and national policies, laws or international agreements.
The Governing Board may appoint a chairperson of the GAC or delegate responsibility for selecting a chairperson to the GAC. The GAC chairperson or another person chosen by the GAC chairperson will serve as the \u201cGAC Representative\u201d responsible for reporting progress back to the Governing Board and interfacing with the TAC. The GAC Representative may attend meetings of the Governing Board and TAC as a non-voting member.
Technical Advisory Council
The role of the TAC is to facilitate communication and collaboration among the Technical Projects. The TAC will be responsible for:
maintaining an overall strategic vision for technical collaboration and coordinating collaboration among Technical Projects, including development of an overall technical vision for the community;
making recommendations to the Budget Committee of resource priorities for Technical Projects;
electing annually a chairperson to preside over meetings, set the agenda for meetings, ensure meeting minutes are taken and who will also serve on the Governing Board as the TAC\u2019s representative (the \u201cTAC Representative\u201d);
creating, maintaining and amending project lifecycle procedures and processes, deciding where Technical Projects fall within that lifecycle;
determining when a technical project should be admitted as a Technical Project or any Technical Project should be considered a TAC Project; and
such other matters related to the technical role of the TAC as may be communicated to the TAC by the Governing Board.
The voting members of the TAC consist of:
one representative appointed by each Premier Sponsor;
up to two \u201cat large\u201d representatives appointed by vote of the TAC; and
one representative appointed by the technical oversight body (e.g., a technical steering committee) of each TAC Project (as defined herein).
TAC meetings are intended to be open to observe by Sponsors, contributors to any TAC Project and others in the general public interested in the OpenWallet Foundation. The TAC may decide whether to allow named representatives (one per voting member) to attend as an alternate.
At the start of the OWF, \u201cTAC Projects\u201d are those Technical Projects listed as having voting representatives on the TAC on the Directed Fund\u2019s web site. Thereafter, any Technical Project can become a TAC Project through the approval of the Technical Project\u2019s technical oversight body and the TAC (by a two-third\u2019s vote). The TAC may approve and modify a project lifecycle policy that will address the incubation, archival and other stages of TAC Projects.
The TAC representatives will elect a chair to preside over meetings, ensure minutes are taken and drive the TAC agenda with input from the TAC representatives.
Voting
Quorum for Governing Board and Committee meetings will require at least fifty percent of the voting representatives. If advance notice of the meeting has been given per normal means and timing, the Governing Board may continue to meet even if quorum is not met, but will be prevented from making any decisions at the meeting.
Ideally decisions will be made based on consensus. If, however, any decision requires a vote to move forward, the representatives of the Governing Board or Committee, as applicable, will vote on a one vote per voting representative basis.
Except as provided in Section 14.a. or elsewhere in this Charter, decisions by vote at a meeting will require a simple majority vote, provided quorum is met. Except as provided in Section 14.a. or elsewhere in this Charter, decisions by electronic vote without a meeting will require a majority of all voting representatives.
In the event of a tied vote with respect to an action that cannot be resolved by the Governing Board, the Chair may refer the matter to the LFEU for assistance in reaching a decision. If there is a tied vote in any Committee that cannot be resolved, the matter may be referred to the Governing Board.
Subsidiaries and Related Companies
Definitions:
\u201cSubsidiaries\u201d means any entity in which a Sponsor owns, directly or indirectly, more than fifty percent of the voting securities or participation interests of the entity in question;
\u201cRelated Company\u201d means any entity which controls or is controlled by a Sponsor or which, together with a Sponsor, is under the common control of a third party, in each case where such control results from ownership, either directly or indirectly, of more than fifty percent of the voting securities or participation interests of the entity in question; and
\u201cRelated Companies\u201d are entities that are each a Related Company of a Sponsor.
Only the legal entity which has executed a Project Sponsorship Agreement and its Subsidiaries will be entitled to enjoy the rights and privileges of such sponsorship; provided, however, that such Sponsor and its Subsidiaries will be treated together as a single Sponsor.
If a Sponsor is itself a foundation, association, consortium, open source project, membership organization, participation organization, user group or other entity that has members or sponsors, then the rights and privileges granted to such Sponsor will extend only to the employee-representatives of such Sponsor, and not to its members or sponsors, unless otherwise approved by the Governing Board in a specific case.
OWF sponsorship is non-transferable, non-salable and non-assignable, except a Sponsor may transfer its current sponsorship privileges and obligations to a successor of substantially all of its business or assets, whether by merger, sale or otherwise; provided that the transferee agrees to be bound by this Charter and the Bylaws and policies required by LFEU sponsorship.
Good Standing
Linux Foundation Europe\u2019s Good Standing Policy is available at https://linuxfoundation.eu/policies and will apply to all Sponsors of this OWF.
Trademarks
Any trademarks relating to the OWF or any Technical Project, including without limitation any mark relating to any conformance program, must be transferred to and held by LFEU or an entity in LFEU\u2019s control and available for use pursuant to LFEU\u2019s trademark usage policy, available at https://linuxfoundation.eu/policies.
Antitrust Guidelines
All Sponsors must abide by Linux Foundation Europe\u2019s Antitrust Policy available at https://linuxfoundation.eu/policies.
All Sponsors must encourage open participation from any organization able to meet the sponsorship requirements, regardless of competitive interests. Put another way, the Governing Board will not seek to exclude any Sponsor based on any criteria, requirements or reasons other than those that are reasonable and applied on a non- discriminatory basis to all Sponsors.
Budget
The Governing Board will approve an annual budget and never commit to spend in excess of funds raised. The budget and the purposes to which it is applied must be consistent with both (a) the non-profit and tax-exempt mission of LFEU and (b) the goals of any Technical Project.
LFEU will provide the Governing Board with regular reports of spend levels against the budget. Under no circumstances will LFEU have any expectation or obligation to undertake an action on behalf of the OWF or otherwise related to the OWF that is not covered in full by funds raised by the OWF.
In the event an unbudgeted or otherwise unfunded obligation arises related to the OWF, LFEU will coordinate with the Governing Board to address gap funding requirements.
General & Administrative Expenses
LFEU will have custody of and final authority over the usage of any fees, funds, and other cash receipts.
A General & Administrative (G&A) fee will be applied by LFEU to funds raised to cover sponsorship records, finance, accounting, and human resources operations. The G&A fee will be 9% of the OWF\u2019s first EUR 1,000,000 of gross receipts each year and 6% of the OWF\u2019s gross receipts each year over EUR 1,000,000.
General Rules and Operations.
The OWF activities must:
engage in the work of the project in a professional manner consistent with maintaining a cohesive community, while also maintaining the goodwill and esteem of LFEU in the open source community;
respect the rights of all trademark owners, including any branding and usage guidelines;
engage or coordinate with LFEU on all outreach, website and marketing activities regarding the OWF or on behalf of any Technical Project that invoke or associate the name of any Technical Project or LFEU; and
operate under such rules and procedures as may be approved by the Governing Board and confirmed by LFEU.
Amendments
This Charter may be amended by a two-thirds vote of the entire Governing Board, subject to approval by LFEU.
"},{"location":"governance/code-of-conduct/","title":"Code of Conduct","text":"
The TAC may adopt a code of conduct (\u201cCoC\u201d) for the Project, which is subject to approval by LF Europe. In the event that a Project-specific CoC has not been approved, the LF Europe Code of Conduct listed at http://lfeurope.be/policies will apply for all Collaborators in the Project.
OpenWallet Foundation projects are required to maintain a standard set of files in each repository. This document describes the required and recommended files.
"},{"location":"governance/common-repository-structure/#required-files-with-specified-content","title":"Required Files with Specified Content","text":"
Repositories MUST have these files with the specific content in the linked files, or a file with a link to the specified content with minimal exposition. These files MUST be at the root of the repository.
LICENSE
Info
All code within the OpenWallet Foundation should be licensed under Apache 2.0. Exceptions can be made by the OpenWallet Foundation Governing Board.
CODE_OF_CONDUCT.md
SECURITY.md
"},{"location":"governance/common-repository-structure/#required-files-with-variable-content","title":"Required Files with Variable Content","text":"
Repositories MUST have these files. Named files MUST be at the root of the repository, and may have format suffixes such as .md, .rst, or .txt.
README - A description of the project that contains information or links to information such as:
A reference to the Apache license (required).
The current and important past releases
Documentation for developers and users
MAINTAINERS - A list of all current maintainers with contact info. A separate document covers the specifics.
CONTRIBUTING - Directions on how to contribute code to the project, or a link to a page with that information.
CHANGELOG - A human readable list of recent changes. Changes should at least include the current release. This file may be maintainer curated or mechanically produced.
Continuous Integration / Continuous Delivery (CICD) configurations - Configurations needed to run CICD on OpenWallet Foundation provided systems (e.g., .github/workflows).
Repositories SHOULD have these files. Named files SHOULD be at the root of the repository
NOTICE - As per section 4 subsection d of the Apache License, Version 2
Apache License Header information in each source code file. For new files added to OpenWallet Foundation repositories they SHOULD include the snippet SPDX-License-Identifier: Apache-2.0 as part of the header.
Build files consistent with the implementation language, such as:
For JavaScript/Node.js a package.json file
For Ruby a Gemfile file
For Java one of a Maven pom.xml, an Apache Ant build.xml, or a Gralde build.gradle
file
For Python setup.py and requirements.txt files
For Go go.mod and optionally go.sum
For Rust a cargo.toml file
For multi-lingual repositories a Makefile or executable build.sh script
For other languages, other standard build files a practitioner of the language would expect.
Testing code - Code to test the code in the repository (such as unit tests), in a location appropriate for the language.
Why not a MUST?
Not all repositories can be tested (homebrew, docs), which is the only reason this is a SHOULD.
Executable binaries and shared library files built by code in the repository. This includes .exe, .dll, .so, .a and .dylib files not otherwise part of a third party library.
This document provides details about the different channels that we have within the OpenWallet Foundation and what we expect each to be used for.
Channel
What
Roles
Discord
Real-Time Communication: Chat services facilitate real-time, synchronous communication among users. Messages are sent and received instantly, enabling quick exchanges and conversations.
Interactive Collaboration: Chat services are well-suited for interactive collaboration, allowing users to engage in live discussions, share files, collaborate on documents, and even conduct video calls in some cases.
Staff: Administers, creates new channels, and moderates
Community: Sends messages and monitors
Mailing Lists
Asynchronous Communication: Mailing lists are primarily used for asynchronous communication. Users send messages to a central email address, which are then distributed to all subscribers. Subscribers can read and respond to messages at their convenience.
Broadcasting Information: Mailing lists are effective for broadcasting information to a group of subscribers. They are commonly used for announcements, discussions, and sharing updates within a community or organization.
Archiving: Mailing lists typically archive messages, allowing subscribers to access past discussions and reference previous communications. This archival feature can be valuable for maintaining a record of conversations and facilitating knowledge sharing.
Staff: Administers, creates new lists, and moderates
Community: Sends messages and monitors
GitHub
Project-Based Source Code and User Documentation: Any source code for projects should utilize GitHub. GitHub pages should be used for hosting user documentation.
TAC Governance Documentation and Other Relevant Information: Governance documentation for the TAC must be version controlled. As such, GitHub is the appropriate place to store this information in addition to other relevant TAC materials. Currently https://tac.openwallet.foundation is generated from markdown files in GitHub.
SIG or Task Force Deliverables: A separate repo can be set up for SIGs and Task Forces so that they can have versioned control support for their deliverables.
Staff: Administers, creates new repos and teams
Maintainers: Reviews and handles issues and pull requests
Community: Use source,create issues, fork code, and contribute
Website
Blogs
Announcements
Native content
Events and Conferences
Staff: Administers and determines contents
Community: Visit and contribute blog posts
Wiki
Project Meeting Minutes
SIG Meeting Minutes
Task Force Meeting Minutes
Collaborative Editing
Staff: Administers and creates new spaces
Community: Creates and edits pages
LFX Meetings (Zoom)
Project, SIG, and TAC meetings: All project, SIG, and TAC meetings must be held using LFX meetings. This ensures that a recording of the meeting is captured and available for people to catch up on what they may have missed. Send an email to operations@openwallet.foundation to get your meetings scheduled.
Staff: Administers and creates new meetings
Community: Attends meetings and listen to recordings
YouTube
Community meeting recordings
Webinar recordings
Event recordings
Staff: Administers and adds videos and playlists
Community: Watch videos
Social Media
Twitter
LinkedIn
Posts about activities and events that the community may be interested in
Posts to announce new projects, SIGs, Task Forces, blog posts
Staff: Administers and posts content
Community: Reads content
"},{"location":"governance/elections/","title":"Elections","text":""},{"location":"governance/elections/#electing-a-chair","title":"Electing a Chair","text":"
From the OWF Charter
The TAC is responsible for ... electing annually a chairperson to preside over meetings, set the agenda for meetings, ensure meeting minutes are taken and who will also serve on the Governing Board as the TAC\u2019s representative (the \u201cTAC Representative\u201d).
The TAC voting members (as defined by the charter) will elect a chair on a yearly basis. Only TAC voting members are eligible to run for the TAC chair seat. Electing a chair will be completed through the voting process outlined below. If the TAC chair must leave their position during their term or is otherwise unable to fulfill their duties, they should submit a resignation and allow the TAC to fill the vacancy using the process outlined below.
"},{"location":"governance/elections/#electing-a-vice-chair","title":"Electing a Vice Chair","text":"
The TAC voting members (as defined by the charter) will elect a vice chair on a yearly basis. Only TAC voting members are eligible to run for the TAC vice chair seat. Electing a vice chair will be held in conjunction with the chair election using the voting process outlined below. The person with the second highest number of votes will serve as the vice chair. If the TAC vice chair must leave their position during their term or is otherwise unable to fulfill their duties, they should submit a resignation and allow the TAC to fill the vacancy using the process outlined below.
The TAC is responsible for ... appointing up to two \"at large\" representatives to the TAC.
The TAC voting members (as defined by the charter) can appoint up to two \"at large\" representatives to the TAC. The election process for \"at large\" representatives will occur on a yearly basis. Members of the community can nominate themselves for the position. Alternatively, a TAC voting member can nominate a member of the community; however, the nominee must actively affirm their candidacy. Electing \"at large\" representatives will be completed through the voting process outlined below. If the \"at large\" representative must leave their position during their term or is otherwise unable to fulfill their duties, they should submit a resignation. \"At large\" vacancies will be handled using the process outlined below.
The following is the default timeline for voting. The times can be adjusted to avoid weekends and holidays, but it is essential that the final schedule be published in advance and adhered to.
Call for nominations: Noon PT, E-16 days
End of call for nominations: Noon PT, E-9 days
A ballot will be distributed on: E-7 days
The election will be completed on: Noon PT, E-day and election results are announced
Nominations
Nominees should outline their qualifications and provide a statement explaining why they would be a good choice for the seat.
Should the TAC Vice Chair seat become vacant, the vacancy will be filled by using the voting process outlined above and the replacement will serve the remainder of the original term.
Should a TAC \"at large\" representative seat become vacant, the vacancy will be filled at the next indicative election, by electing a person for a full new term, not by serving out the vacant term.
Why?
A TAC \"at large\" vacancy is not filled immediately because the charter does not specify a lower limit for TAC \"at large\" representatives; it only specifies an upper limit.
"},{"location":"governance/elections/#tac-premier-sponsor-representative-vacancy","title":"TAC Premier Sponsor Representative Vacancy","text":"
Should a TAC premier sponsor representative seat become vacant, the premier sponsor will immediately appoint a new representative.
Should a TAC Project representative seat become vacant, the technical oversight body (e.g., a technical steering committee) for the TAC project will immediately appoint a new representative.
This policy applies to projects that do not have an explicit maintainer inactivity policy. Where a project has an established and functioning policy, only that project's policy will apply.
OpenWallet Foundation very much appreciates the contributions of all maintainers but removing write privileges is in the interest of an orderly and secure project.
Activity can be code contributions, code reviews, issue reporting, or any other such activity trackable by GitHub attributed to a OpenWallet Foundation repository.
When a maintainer has not had any activity in a particular project for three months they will receive a notification informing them of the inactivity policies. The means and manner of notification (email, github mentions, etc.) will be at the discretion of the TAC Chair or who the TAC Chair designates.
When a maintainer has not had any activity in a particular project for six months a proposal will be opened up to move the maintainer from active status to emeritus status. A member of the TAC or a OpenWallet Foundation staff member will open this proposal. Any permissions to approve pull requests or commit code and any other such privileges associated with maintainer status will be removed.
The proposal will be in the form of a pull request (PR) to the relevant project repositories updating their maintainer lists. The inactive maintainer will be notified of this via an \"at\" @ mention in the PR. The PR will be open for at least one week to allow time for the project and maintainer to comment.
Inactive maintainers who express an intent to continue contributing may request a three-month extension. This request shall be made in the pull request updating their active maintainer status. Typically, only one such extension will be granted.
Maintainers who have been moved to emeritus status may return to active status when their activity within the project resumes and the current maintainers of the project approve their reactivation.
An OpenWallet Foundation Foundation staff member will provide a report (or maintain an automated means to generate a report) of the most recent GitHub tracked actions for contributors at regular intervals to the TAC. It will be the TAC's responsibility to act on the data.
All OpenWallet Foundation projects MUST have a MAINTAINERS file (MAINTAINERS.md or MAINTAINERS.rst) at the top-level directory of the source code. This document will provide specifics on what to include in the MAINTAINERS file.
"},{"location":"governance/maintainers-file-content/#list-of-project-maintainers","title":"List of Project Maintainers","text":"
The first thing that MUST be included in the MAINTAINERS file is a list of the project's maintainers, both active and emeritus.
It is recommended that the lists be sorted alphabetically and contain the maintainers name, GitHub ID, LFID, Chat ID, Email, Company Affiliation, and Scope.
Important
The email for a maintainer MUST be specified and be a reliable mechanism to contact the maintainer.
Scope is dependent on the project and may not exist for a given project. Scope could be the whole project, a specific repository, specific directories in a repository, or high-level description of responsibility (e.g., Documentation).
The following shows the suggested format for the information:
Example
Active Maintainers
Maintainer GitHub ID LFID Email Chat ID Company Affiliation Scope
Emeritus Maintainers
Maintainer GitHub ID LFID Email Chat ID Company Affiliation Scope"},{"location":"governance/maintainers-file-content/#what-does-being-a-maintainer-entail","title":"What Does Being a Maintainer Entail","text":"
The MAINTAINERS file SHOULD contain information about the different types of maintainers that exist (whole project, repo, part of repo) and what their duties are (e.g., maintainers calls, quarterly reports, code reviews, issue cleansing).
"},{"location":"governance/maintainers-file-content/#how-to-become-a-maintainer","title":"How to Become a Maintainer","text":"
The MAINTAINERS file SHOULD contain information about how to become a maintainer for the project. This section SHOULD list specific information about what is required. Information that SHOULD be included in this section:
What is required before someone can be considered to become a maintainer
Consider whether there should be different requirements based on the scope (whole project, repo, part of repo) of maintainership
Whether sponsorship by an existing maintainer is required
How maintainers are proposed to the community. A number of open source projects require that a PR be done against the MAINTAINERS file to make this proposal
How many maintainers must approve the proposed maintainer. This should include information about what happens if someone vetoes the proposal
How long the existing maintainers have to respond to the proposal
"},{"location":"governance/maintainers-file-content/#how-maintainers-are-removed-or-moved-to-emeritus-status","title":"How Maintainers are Removed or Moved to Emeritus Status","text":"
The MAINTAINERS file SHOULD contain information about how a maintainer is removed from the list of active maintainers. Information that SHOULD be included in this section:
What are the reasons a maintainer would be removed from the list of active maintainers
How this is proposed; similar to the way in which maintainers are added, one way to do this is via a PR against the MAINTAINERS file
OpenWallet Foundation (OWF) provides a number of paid developer tools for projects. Below, we list the ones that our projects currently have access to and are supported by the OWF staff. We emphasize that just because a tool is not on this list does not mean projects cannot use it; it just means that the project maintainers may have to support it themselves and may need to pay for the tooling. The Governing Board has final say over the budget for tooling and its support.
OWF recommends the following tools that should be optimal for most projects:
Technical Documentation: markdown, GitHub pages, and Material for MkDocs.
Finally we emphasize that this list does not cover security-related tools or services.
"},{"location":"governance/project-and-lab-services/","title":"Project and Lab Services","text":"
This document provides details about what resources are available for OpenWallet Foundation projects and labs. If there are any questions about anything on the document or if you'd like to leverage any of these resources for your project or lab, feel free to reach out to community-architects at openwallet dot foundation.
Service Lab Growth Project Impact Project Infrastructure Github repos Yes Yes Yes Chat channel Yes Yes Yes Mailing list Optional Yes Yes Paid tooling Yes (with some restrictions at the discretion of OpenWallet Foundation staff) Yes Yes Marketing Access to OpenWallet Foundation's channels (social, newsletters, blogs, meetups, etc) Yes (with some restrictions at the discretion of the Marketing lead) Yes Yes Page on the OpenWallet Foundation site Yes Yes Creation of an official project name and logo Yes Yes Coordinate promotion of major project milestones and releases Yes Yes Option to create a Twitter account Yes Yes Priority placement on site Yes Swag (stickers and potentially other items with the project logo) Yes Onboarding New Users and Contributors Able to take part in OpenWallet Foundation's annual Mentorship program TBD TBD TBD Able to have project/lab featured in a contribution campaign Yes (at the discretion of OpenWallet Foundation staff) TBD TBD Workshops Yes Documentation and Translation support TBD TBD TBD Training/Certification LF created training course Yes (at the discretion of LF Training) Yes (at the discretion of LF Training) LF created certification Yes (at the discretion of LF Training) Other License scanning Yes Yes Security audits Not usually (although this can be done at the discretion of staff) Yes (at the discretion of OpenWallet Foundation staff)"},{"location":"governance/project-annual-review-process/","title":"Project Annual Review Process","text":""},{"location":"governance/project-annual-review-process/#overview","title":"Overview","text":"
The TAC will undertake an annual review of all OpenWallet Foundation projects. This annual review will include an assessment as to whether:
each Lab is active
each Growth Stage project is making adequate progress towards the Impact Stage
each Impact Stage project is maintaining progress to remain at the Impact Stage
Reviews will start on the yearly anniversary of the project being accepted or moving to a new stage. The review will include a set of recommendations for each project to improve and/or recommendation to move a project across stages.
Projects can be provided with an extension of time in their current stage (up to the discretion of the TAC).
The project lifecycle contains Acceptance Criteria for moving a project to a new stage.
"},{"location":"governance/project-annual-review-process/#filing-an-annual-review","title":"Filing an Annual Review","text":"
OpenWallet Foundation staff will notify the project maintainers when the project review is due.
Project maintainers are responsible for agreeing between them who will complete the annual review. One of the maintainers should create the review in GitHub under openwallet-foundation/tac/docs/projects/reviews.
The PR should include a file called <year>-<project name>-annual.md (e.g., 2024-amazingproj-annual.md) with the contents described below
Send an email to the TAC mailing list so that the community knows the PR is there and can comment on it
If your annual review is not submitted within two months of notification, we will take this as a sign that the project is not under active maintenance and the TAC is likely to decide to archive the project and move it to Emeritus status.
Success
If a project has genuinely stalled we can save everyone\u2019s time and effort by archiving it.
Your annual review should answer the following questions:
Include information about your project's contributions and activity. We will be looking for signs of consistent or increasing contribution activity. Please feel free to add commentary to add colour to the numbers and graphs we will see on Insights.
How many maintainers do you have, and which organisations are they from? (Feel free to link to an existing MAINTAINERS file if appropriate.)
What do you know about adoption, and how has this changed since your last review or since being accepted into OWF? If you can list companies that are adopters of your project, please do so. (Feel free to link to an existing ADOPTERS file if appropriate.
How has the project performed against its goals since the last review? (We won't penalize you if your goals changed for good reasons.)
What are the current goals of the project? For example, are you working on major new features? Or are you concentrating on adoption or documentation?
How can the OpenWallet Foundation help you achieve your upcoming goals?
Do you think that your project meets the criteria for another stage (see Project Lifecycle Acceptance Criteria for the different stages)?
A template has been provided for your use.
"},{"location":"governance/project-annual-review-process/#annual-review-by-the-tac","title":"Annual Review by the TAC","text":"
Annual reviews are performed in order to check in with projects, ascertain their progress, and address any outstanding questions.
A TAC representative volunteers to lead the review once the project files a PR.
The assigned TAC member reviews the content of the PR and analyzes the project for community health indicators, their findings are placed within a thread in the private TAC channel for discussion.
findings should highlight important facts about the project that could influence the TACs decision around the future of the project, its current stage, and path to other stages, etc.
the thread should always include whether the project's view of themselves is accurate and the ask of the TAC is reasonable to assist the project moving forward.
The project's maintainers are invited to the public TAC meeting to engage in TAC led discussion around the project. Project maintainers are not obligated to attend.
The assigned TAC member provides a summary of the project and leverages the thread's content as the basis of discussion.
discussion typically focuses on what is going well with the project and areas to improve.
The project's maintainers are invited to use this time to voice any concerns and requests for help they may have that are not captured in the PR (or highlight asks within the PR).
At the conclusion of the public meeting, the TAC votes to approve the annual review. Should a concern be registered on a project, the vote will be held separately.
After the meeting wraps up, the assigned TAC member may summarize the discussion on the PR in the form of a comment to document information for the project and community.
At least two-thirds of the TAC members agree to continue to sponsor the project at its current stage, or
If enough TAC members do not agree to continue to sponsor the project at its current stage, we will discuss with you what stage might be the appropriate next stage, including Emeritus stage.
Info
If the TAC members recommend moving to a new stage, additional work may be required to provide details on how the project meets the new stage's acceptance criteria.
This governance policy describes how an open source project can formally join the OpenWallet Foundation via the Project Proposal Process and how an existing project within the OpenWallet Foundation can move through the lifecycle via the Project Stage Change Proposal Process. It describes the Stages a project may be admitted under and what the criteria and expectations are for a given stage, as well as the acceptance criteria for a project to move from one stage to another. It also describes the Annual Review Process through which those changes will be evaluated and made.
Project progression - movement from one stage to another - allows projects to participate at the level that is most appropriate for them given where they are in their lifecycle. Regardless of stage, all OpenWallet Foundation projects benefit from a deepened alignment with existing projects, and access to mentorship, support, and Foundation resources.
Info
Capitalized terms not otherwise defined in this Project Lifecycle Policy have the meanings ascribed to them in the Charter of the OpenWallet Foundation.
This governance policy sets forth the proposal process for projects to be accepted into the OpenWallet Foundation. The process is the same for both existing projects which seek to move into the OpenWallet Foundation and new projects to be formed within the OpenWallet Foundation.
Projects must be formally proposed via GitHub. Project proposals submitted to the OpenWallet Foundation should provide the following information to the best of their ability:
name of project
preferred maturity level (see stages below)
project description (what it does, why it is valuable, origin and history)
statement on alignment with the OpenWallet Foundation mission
link to current Code of Conduct (if one is adopted already)
sponsor from the TAC, if identified (a sponsor helps mentor projects)
project license (OSI-approved permissive open source licenses, Apache 2.0 by default)
source control (OpenWallet Foundation GitHub by default)
issue tracker (OpenWallet Foundation GitHub by default)
external dependencies (including licenses)
release methodology and mechanics
names of initial maintainers, if different from those submitting proposal
link to any documented governance practices (e.g., the project charter) (A project charter can be obtained by completing this form. Here is sample project charter that you can review)
existing financial sponsorship (if exists)
infrastructure needs or requests (OpenWallet Foundation provides a set of services for projects and labs. Please note which of these you will utilize and what else is required)
Impact stage and Growth stage projects are required to present their proposal at a TAC meeting. Labs will be reviewed and approved directly via the project proposal PR. Labs may present at a TAC meeting if they would like to gain visibility from other community members, and the proposer should note this in the proposal.
The TAC may ask for changes to bring the project into better alignment with the OpenWallet Foundation (adding a governance document to a repository or adopting a Code of Conduct, for example).
Warning
The project will need to make these changes in order to progress further.
Impact stage and Growth stage projects are accepted via a two-thirds supermajority vote of the TAC. Labs are accepted via a simple majority of the TAC.
Satisfaction of the requirements of the initial stage of the project. The TAC will determine the appropriate initial stage for the project. The project can apply for a different stage via the review process.
This governance policy sets forth the proposal process for projects within the OpenWallet Foundation that are seeking to move to another stage in the project lifecycle.
The project's current proposal located in Project Proposals GitHub Repository must be updated via a PR. The project proposal should be updated to reflect the latest template, as well as any updates to the sections to reflect why the project should be considered for a new stage.
Every OpenWallet Foundation project has an associated maturity level. Proposed projects should state their preferred maturity level.
All projects may attend TAC meetings and contribute work regardless of their stage.
flowchart\n p[Proposal]\n subgraph as[Active Stages]\n l[Labs]\n g[Growth]\n i[Impact]\n end\n subgraph is[Inactive Stages]\n e[Emeritus]\n end\n p --> as\n l <--> g\n l <--> i\n g <--> i\n as --> is
Labs are those which the TAC believes are, or have the potential to be, important to the ecosystem of Technical Projects or the open wallet ecosystem as a whole. They may be early-stage code just getting started, or they may be long-established projects with minimal resource needs. The Labs stage provides a beneficial, neutral home for these projects in order to foster collaborative development and provide a path to deeper alignment with other OpenWallet Foundation projects via the project lifecycle process.
Examples
Experimental code that is designed to extend one or more OpenWallet Foundation projects with functionality or interoperability libraries.
Independent code that fits within the Foundation's mission and provides potential to meet an unfulfilled need.
Code commissioned or sanctioned by the OpenWallet Foundation.
Any code that intends to join the Growth or later stages in the future and wishes to lay the foundation for that transition.
Expectations
End users should evaluate Labs with care, as this stage does not set requirements for community size, governance, or production readiness. Labs will receive minimal support from the Foundation. Labs will be reviewed on an annual basis; they may also request a status review by submitting a report to the TAC.
Acceptance Criteria
To be considered for the Labs Stage, the project must meet the following requirements:
Complete an project intake form. This intake form will create:
A project charter (sample) that documents an intellectual property policy that leverages the Apache 2.0 license or a permissive open source license.
A collaboration agreement that in the case of existing projects, provides an agreement to transfer the project name, trademarks, and electronic account assets (github repo, social media accounts, domain names, etc.) to Linux Foundation Europe for the benefit of the OpenWallet Foundation.
Submit a project proposal.
Upon acceptance, Labs must list their status prominently on their website/README (e.g., PROJECT, an OpenWallet Foundation Lab).
The Growth Stage is for projects that are interested in reaching the Impact Stage, and have identified a growth plan for doing so. Growth Stage projects will receive mentorship from the TAC and are expected to actively develop their community of contributors, governance, project documentation, roadmap, and other variables identified in the growth plan that factor into broad success and adoption.
In order to support their active development, projects in the Growth stage have a higher level of access to Foundation resources, which will be agreed upon and reviewed on a yearly basis. A project's progress toward its growth plan goals will be reviewed on a yearly basis, and the TAC may ask the project to move to the Labs stage if progress on the plan drops off or stalls.
Examples
Projects that are on their way or very likely to become Growth or Impact projects.
Projects that have developed new growth targets or other community metrics for success.
Projects that are looking to create a lifecycle plan (maintainership succession, contributor programs, version planning, etc.).
Projects that need more active support from the Foundation or TAC mentorship in order to reach their goals.
Expectations
Projects in the Growth stage are generally expected to move out of the Growth stage within two years. Depending on their growth plans, projects may cycle through Labs, Growth, or Impact stage as needed.
Acceptance Criteria
To be considered for Growth Stage, the project must meet the Labs requirements as well as the following:
A presentation at the meeting of the TAC.
2 TAC sponsors to champion the project and provide mentorship as needed.
Development of a growth plan, to be done in conjunction with their project mentor(s) at the TAC.
Development of a project roadmap that provides differentiated features and capabilities and the timeframe for completion.
Document that it is being used successfully in either proof of concepts or pilots by at least two independent end users which, in the TAC\u2019s judgment, are of adequate quality and scope.
Demonstrate a substantial ongoing flow of commits and merged contributions.
Demonstrate that the current level of community participation is sufficient to meet the goals outlined in the growth plan and roadmap.
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.
Demonstrates how this project differs from existing projects in the Growth and Impact stages.
Receive a two-thirds supermajority vote of the TAC to move to Growth Stage.
Upon acceptance, Growth projects must list their status prominently on their website/README (e.g., PROJECT, an OpenWallet Foundation Project).
The Impact Stage is for projects that have reached their growth goals and are now on a sustaining cycle of development, maintenance, and long-term support. Impact Stage projects are used commonly in enterprise production environments and have large, well-established project communities.
Examples
Projects that have publicly documented release cycles and plans for Long Term Support (\"LTS\").
Projects that have themselves become platforms for other projects.
Projects that are able to attract a healthy number of committers on the basis of its production usefulness (not simply 'developer popularity').
Projects that have several, high-profile or well known end-user implementations.
Expectations
Impact Stage projects are expected to participate actively in TAC proceedings, and as such have a binding vote on TAC matters requiring a formal vote, such as the election of a TAC representative. They receive ongoing financial and marketing support from the Foundation, and are expected to cross promote the Foundation along with their activities.
Acceptance Criteria
To move from Labs or Growth status, or for a new project to join as an Impact project, a project must meet the Growth stage criteria plus:
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.
Have a documented and publicly accessible description of the project's governance, decision-making, and release processes.
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.
Have a Code of Conduct in a form acceptable to the OpenWallet Foundation.
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).
Document that it is being used successfully in production by at least two independent end users which, in the TAC\u2019s judgment, are of adequate quality and scope.
Have a public list of project adopters for at least the primary repo (e.g., ADOPTERS.md or logos on the project website).
Have a good standing with respect to security.
Other metrics as defined by the applying Project during the application process in cooperation with the TAC.
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.
Upon acceptance, Impact projects must list their status prominently on their website/README (e.g., PROJECT, an OpenWallet Foundation Project).
Emeritus projects are projects which the maintainers feel have reached or are nearing end-of-life. Emeritus projects have contributed to the ecosystem, but are not necessarily recommended for modern development as there may be more actively maintained choices. The Foundation appreciates the contributions of these projects and their communities, and the role they have played in moving the ecosystem forward.
Examples
Projects that are \"complete\" by the maintainers' standards.
Projects that do not plan to release major versions in the future.
Expectations
Projects in this stage are not in active development. Their maintainers may infrequently monitor their repositories, and may only push updates to address security issues, if at all. Emeritus projects should clearly state their status and what any user or contributor should expect in terms of response or support. If there is an alternative project the maintainers recommend, it should be listed as well. The Foundation will continue to hold the IP and any trademarks and domains, but the project does not draw on Foundation resources.
Acceptance Criteria
Projects may be granted Emeritus status via a two-thirds vote from the TAC and with approval from project ownership. In cases where there is a lack of project ownership, only a two-thirds vote from the TAC is required.
Upon acceptance, Emeritus projects must list their status prominently on their website/README.
Info
If members of the community would like to re-active a project that has been granted Emeritus status, the community must start the lifecycle over again by submitting a new proposal to the TAC.
Releases at OpenWallet Foundation must be done according to the SemVer taxonomy. In addition to the semantic versioning scheme, where we use MAJOR.MINOR.PATCH numbering, following the established guidance given in the semver specification, it is also strongly encouraged that projects should use the following tags, as permitted by semver:
preview
alpha
beta
rcN (release candidate N - where N is 1-n incremented for each candidate)
snapshot-<sha> for interim, possible unstable builds
Note
Further, for interim, possibly unstable builds working towards a tagged release, we will append the first seven (7) characters of the SHA-1 hash of the latest commit for the branch from which the build is produced, so that we can identify the commit level of a given test, etc. e.g. 0.6-snapshot-36e99cd
Not feature complete, but most functionality is implemented. Any missing functionality that is committed to the production release is identified, and there are specific people working on those features. Not heavily performance tuned, but performance testing has started with the first few hotspots identified and perhaps even addressed. No highest priority issues are in an open state. First-level developer documentation provided to help new developers with the learning curve.
Feature complete, for all features committed to the production release. Ready for Proof of Concept-level deployments. Performance can be characterized in a predictable way, so that basic PoC's can be done within the bounds of published expectations. APIs are documented. First attempts at end-user documentation have been made. Developer documentation is further advanced. No highest priority issues are in an open state.
Feature complete for all features committed to the production release, perhaps with optional features when safe to add. Ready for Pilot-level engagements. Performance is very well characterized and active optimizations are being done, with a target set for the Production release. No highest priority or high priority bugs are in an open state. Developer documentation is complete; end-user documentation is mostly done.
For a forthcoming production release, we will prepare multiple candidate releases intended to be heavily tested by the community. As we cycle through resolving uncovered issues, we will issue another when no remaining highest or high priority issues remain, and repeat until we feel confident in releasing a production release, with no qualifier. e.g. 1.0.
This document is based on the Hyperledger Foundation's Release Taxonomy policy.
"},{"location":"governance/roles-and-responsibilities/","title":"Roles and Responsibilities","text":""},{"location":"governance/roles-and-responsibilities/#technical-advisory-council","title":"Technical Advisory Council","text":"
The OpenWallet Foundation charter states that the TAC is responsible for:
Quote
maintaining an overall strategic vision for technical collaboration and coordinating collaboration among Technical Projects, including development of an overall technical vision for the community;
making recommendations to the Budget Committee of resource priorities for Technical Projects;
electing annually a chairperson to preside over meetings, set the agenda for meetings, ensure meeting minutes are taken and who will also serve on the Governing Board as the TAC\u2019s representative (the \u201cTAC Representative\u201d);
creating, maintaining and amending project lifecycle procedures and processes, deciding where Technical Projects fall within that lifecycle;
determining when a technical project should be admitted as a Technical Project or any Technical Project should be considered a TAC Project; and
such other matters related to the technical role of the TAC as may be communicated to the TAC by the Governing Board.
Subscribe to the TAC mailing list and the OpenWallet Github organization to stay aware of the TAC related updates and issues
Regularly participate in the TAC meetings
Bring up and help resolve any issues related to the needs of the OpenWallet technical community
Participate in, and optionally chair, the Task Forces set up by the TAC to address specific issues
Act as stewards for OpenWallet Foundation promoting and helping grow the organization and its activities by engaging of their own accord in activities such as posting on social media, responding to questions raised in forums, helping new community members find their way around, and giving talks at conferences on OpenWallet Foundation related topics
Participate in the appointment and election of \"at large\" representatives
The TAC chair has the following additional responsibilities:
Running the TAC meetings, such as the TAC calls per the agreed upon schedule. This includes: setting up and publishing an agenda, running the meeting, and ensuring any outcome is duly recorded
Representing the TAC, and more broadly the OpenWallet Foundation technical community, on the Governing Board, and giving updates to the Governing Board on TAC activities
The following is the best practices template security vulnerability disclosure policy for OpenWallet Foundation's projects. Please copy the text below, place it into the SECURITY.md file for the primary repository of your project, and adjust it as necessary for your project. Notably:
Remove this \"Instructions\" section.
Replace PROJECT in the title of this page with the name of your project.
Populate the Security Team section with maintainers who have agreed to be on the security team.
See the \"Alternative\" notes in the OpenWallet Foundation's security vulnerability disclosure policy document for how the \"best practices\" in this document can be changed to meet the needs of your project while still adhering to the OpenWallet Foundation's policies.
Once your project's security vulnerability disclosure policy document is published, place a copy of it into each of your project's repositories (or link to the main repository's SECURITY.md).
"},{"location":"governance/security-template/#about-this-document","title":"About this Document","text":"
This document document defines how security vulnerability reporting is handled in this project. The approach aligns with the OpenWallet Foundation's security vulnerability disclosure policy. Please review that document to understand the basis of the security reporting for this project
This policy borrows heavily from the recommendations of the OpenSSF Vulnerability Disclosure working group. For up-to-date information on the latest recommendations related to vulnerability disclosures, please visit the GitHub of that working group.
If you are already familiar with what a security vulnerability disclosure policy is and are ready to report a vulnerability, please jump to Report Intakes.
"},{"location":"governance/security-template/#what-is-a-vulnerability-disclosure-policy","title":"What Is a Vulnerability Disclosure Policy?","text":"
No piece of software is perfect. All software (at least, all software of a certain size and complexity) has bugs. In open source development, members of the community or the public find bugs and report them to the project. A vulnerability disclosure policy explains how this process functions from the perspective of the project.
This vulnerability disclosure policy explains the rules and guidelines for this project. It is intended to act as both a reference for outsiders\u2013including both bug reporters and those looking for information on the project\u2019s security practices\u2013as well as a set of rules that maintainers and contributors have agreed to follow.
This project uses the following mechanism to submit security vulnerabilities. While the security team members will do their best to respond to bugs disclosed in all possible ways, it is encouraged for bug finders to report through the following approved channel:
Open a GitHub security vulnerability report: Open a draft security advisory on the \"Security\" tab of this GitHub repository. See GitHub Security Advisories to learn more about the security infrastructure in GitHub.
Name Email ID Chat ID Area/Specialty <> <> <> <> <> <> <> <> <> <> <> <>
The security team for this project must include at least three project Maintainers that agree to carry out the following duties and responsibilities. Members are added and removed from the team via approved Pull Requests to this repository. For additional background into the role of the security team, see the People Infrastructure section of the OpenWallet Foundation's security vulnerability disclosure policy.
Responsibilities:
Acknowledge receipt of the issue (see Report Intakes) to the reporter within 2 business days.
Assess the issue. Engage with the reporter to ask any outstanding questions about the report and how to reproduce it. If the report is not considered a vulnerability, then the reporter should be informed and this process can be halted. If the report is still a regular bug (just not a security vulnerability), the reporter should be informed (if necessary) of the regular process for reporting bugs.
Some issues may require more time and resources to correct. If a particular report is more complex, discuss an embargo period with the reporter. The embargo period should be negotiated with the reporter and must not be longer than 90 days.
Create a patch for the issue (see Private Patch Deployment Infrastructure).
Request a CVE for the issue (see CNA/CVE Reporting).
Decide the date of public release.
If applicable, notify members of the embargo list of the upcoming patch and release, as described above.
Cut a new (software) release in which the bug is fixed.
Publicly disclose the issue within 48 hours after the release (see GitHub Security Advisories).
Discussions about each reported vulnerability are carried out in the private GitHub security advisory about the vulnerability. If necessary, a private channel specific to the issue may be created on the OpenWallet Foundation's Discord server with invited participants added to the discussion.
This project maintains a private embargo list. If you wish to be added to the embargo list for a project, please email the [OpenWallet Foundation's security list], including the project name and reason for being added to the embargo list. Requests will be assessed by the security team in conjunction with the appropriate OpenWallet Foundation staff, and a decision will be made whether to accommodate the request.
In creating patches and new releases that address security vulnerabilities, this project uses the private development features of GitHub for security vulnerabilities. GitHub has extensive documentation about these features.
This document outlines the OpenWallet Foundation's security vulnerability disclosure policy that all OpenWallet Foundation projects MUST follow. The associated security template file is a \"best practices\" security vulnerability disclosure policy that project Maintainers SHOULD use for publishing the security policy and procedures for their project by copying the file into their project repositories and updating it according to the instructions in the document. This document includes the \"best practices\" text, and defines how project Maintainers can use alternatives to the best practices for their project. A project's resulting alternative policy MUST adhere to the OpenWallet Foundation's security vulnerability disclosure policy.
All project repositories MUST have a published security vulnerability disclosure policy or have link to a common policy document for the project. In rare cases, a repository within a project MAY have a policy different from the project, as long as the repository policy also adheres to this OpenWallet Foundation's security vulnerability disclosure policy.
"},{"location":"governance/security/#about-this-document","title":"About This Document","text":"
This policy borrows heavily from the recommendations of the OpenSSF Vulnerability Disclosure working group. For up-to-date information on the latest recommendations related to vulnerability disclosures, please visit the GitHub of that working group.
In each of the document's sections, and in the associated security template, the current OpenWallet Foundation's \"best practices\" are defined.
Alternative
Alternatives that a project may use exist for some sections and are contained in these \"Alternative boxes\". When projects vary from the current OpenWallet Foundation's best practices, the documented alternatives MUST adhere to this policy.
"},{"location":"governance/security/#what-is-a-vulnerability-disclosure-policy","title":"What Is a Vulnerability Disclosure Policy?","text":"
No piece of software is perfect. All software (at least, all software of a certain size and complexity) has bugs. In open source development, members of the community or the public find bugs and report them to the project. A vulnerability disclosure policy explains how this process functions from the perspective of the project.
This vulnerability disclosure policy explains the rules and guidelines for OpenWallet Foundation's projects. It is intended to act as both a reference for outsiders\u2013including both bug reporters and those looking for information on the project\u2019s security practices\u2013as well as a set of rules that maintainers and contributors have agreed to follow.
"},{"location":"governance/security/#vulnerability-disclosure-process-and-associated-rules","title":"Vulnerability Disclosure Process and Associated Rules","text":"
All OpenWallet Foundation's projects, including this project, follow the associated process and rules for vulnerability disclosures. We note that this outline is derived from the OpenSSF maintainers guide.
Each project will have a security team. The security team will be comprised of maintainers or contributors to the project who are knowledgeable about security and is responsible for responding to and helping to fix security vulnerabilities.
The security team for this project will do the following for each reported vulnerability:
Acknowledge receipt of the issue (see Report Intakes) to the reporter within 2 business days.
Assess the issue. Engage with the reporter to ask any outstanding questions about the report and how to reproduce it. If the report is not considered a vulnerability, then the reporter should be informed and this process can be halted. If the report is still a regular bug (just not a security vulnerability), the reporter should be informed (if necessary) of the regular process for reporting bugs.
Some issues may require more time and resources to correct. If a particular report is more complex, discuss an embargo period with the reporter. The embargo period should be negotiated with the reporter and must not be longer than 90 days.
Create a patch for the issue (see Private Patch Deployment Infrastructure).
Request a CVE for the issue (see CNA/CVE Reporting).
Decide the date of public release.
If applicable, notify members of the embargo list of the upcoming patch and release, as described above.
Cut a new (software) release in which the bug is fixed.
Publicly disclose the issue within 48 hours after the release (see GitHub Security Advisories).
OpenWallet Foundation's projects use the following mechanism to submit security vulnerabilities. While the security team members will do their best to respond to bugs disclosed in all possible ways, it is encouraged for bug finders to report through the following approved channel:
Open a GitHub security vulnerability report: Open a draft security advisory on the \"Security\" tab of this GitHub repository. See GitHub Security Advisories to learn more about the security infrastructure in GitHub.
Alternative
Projects MAY publish in their security policy that they accept security vulnerability disclosures via other mechanism. The policy MUST document the necessary details in using the alternate reporting mechanism(s). Projects MUST accept reports via the recommended GitHub security vulnerability process.
This section details the required basic vulnerability disclosure infrastructure for all OpenWallet Foundation's projects. There are quite a few necessary pieces of infrastructure, and we go through them in detail here.
Projects MUST have a security response team of at least three maintainers. This response team shall be set up BEFORE incidents happen so that people know who to contact and how to contact them when an emergency issue arises. It can be difficult to track down someone with unique knowledge (e.g. in a particular area of cryptography) who is capable of fixing a problem in a short period of time.
Each security team member will be a member of any OpenWallet Foundation-wide security infrastructure.
If a project has specialized code related to certain aspects of security or cryptography (e.g. consensus algorithms or cryptographic algorithms), then a corresponding specialist should be on the response team (e.g. someone knowledgeable in consensus or cryptography, respectively). If a specialist is not on the team, then the individual who is responsible for contacting or engaging the specialists should be designated in their stead. We emphasize that projects should have access to specialists in an area for which they maintain code while recognizing that it may not be practical for these experts to be on the response team.
Each project/repository must have a table in the security document listing the team members in the following format.
Name Email ID Chat ID Area/Specialty <> <> <> <> <> <> <> <> <> <> <> <>"},{"location":"governance/security/#discussion-forum","title":"Discussion Forum","text":"
Discussions about each reported vulnerability SHOULD be carried out in the private GitHub security advisory about the vulnerability. If necessary, a private channel specific to the issue MAY be created on the OpenWallet Foundation's Discord server with invited participants added to the discussion.
Alternative
Projects MAY document on their security policy that they use other forums for private discussion forums for approved maintainers and security team participants to discuss vulnerabilities. If other forum(s) are used, details about them MUST be included.
OpenWallet Foundation's projects maintain a list of Common Vulnerabilities and Exposures (CVE) and use GitHub as its CVE numbering authority (CNA) for issuing CVEs.
Alternative
A project MAY document in its security policy that it uses a different CVE numbering authority. For example, the project might add the following text to this section of their security policy document:
This project uses the following CNA(s) in the following situations:\n1. `CNA_1`: `situation_1, can just state \u201cdefault\u201d if only one CNA`\n2. `CNA_2`: `situation_2`\n
An embargo list is a list of known, trusted entities that run large deployments of a given OpenWallet Foundation's project. These entities are notified ahead of time when important security patches are incoming to minimize potential security risks to large deployments of projects. Embargo lists are maintained by the security team for a given project/repository.
Parties are on an embargo list for (usually) one of two reasons, because they can either help fix the problem (perhaps through testing a fix at scale) or they need extra time to help prepare their ecosystem to roll out fixes quickly. Approval is not given lightly: project leadership (maintainers) must be convinced that institutions on the list \u201cneed to know\" about issues in advance.
Participation in an embargo list should not be taken lightly. List members are expected to respect the materials shared through it and not disclose any information to unauthorized parties until the public disclosure date. Institutions are on this list because their presence helps the project and its users; if their actions do not help the project and its users, they can expect to be removed from the list.
The list itself is private in order to make it slightly more difficult for attackers with vulnerabilities to find systems to attack. Entities may be added to the embargo list by a majority vote of the project security response team and should request to join the embargo list by contacting one or more of the members of the security response team. If there is an issue about embargo list membership where an entity feels like they are being dealt with unfairly by the security response team, then they are encouraged to bring up the issue in front of the OpenWallet Foundation's TAC, who can act as moderators.
OpenWallet Foundation's projects maintain private embargo lists. If you wish to be added to the embargo list for a project, please email the [OpenWallet Foundation's security list], including the project name and reason for being added to the embargo list. Requests will be assessed by the respective OpenWallet Foundation's security team in conjunction with the appropriate OpenWallet Foundation staff, and a decision will be made to accommodate or not the request.
Alternative
Projects MAY choose to document in their security document that they do not have an embargo list. The reason for not having an embargo list SHOULD be included when a project chooses not to have an embargo list.
OpenWallet Foundation's projects use GitHub security advisories and the GitHub security process for handling security vulnerabilities. In particular, this best practice is strongly recommended for projects that do not have a large number of security experts as the features serve as a nice set of guardrails to help make sure that things are done correctly.
Alternative
Projects MAY document in their security policy document that they use a security advisory mechanism other than GitHub to publish their disclosures. The alternate mechanism MUST be documented sufficiently for users to understand how to monitor the security advisories published by the project.
Patches to fix OpenWallet Foundation's project security vulnerabilities are typically developed without public visibility by using the private development features of GitHub. Projects with maintainers that are not familiar with these capabilities are encouraged to contact the OpenWallet Foundation Community Architects to learn more.
Alternative
Projects MAY document in their security policy document that they do use a service other than GitHub for private patch deployment infrastructure, or that they don't use any private patch deployment infrastructure at all. In either case, the document MUST include the details of what is used instead.
A special interest group (SIG) under the Technical Advisory Council (TAC) is a group with a shared interest in advancing a specific area of knowledge, learning, or technology related to the mission of the OpenWallet Foundation where members cooperate to affect or to produce solutions within their particular field. Unlike a task force, SIGs are typically long running and may or may not produce any deliverables. A SIG can be created by anyone in the OpenWallet Foundation community and must be proposed to and approved by the TAC.
"},{"location":"governance/special-interest-group-process/#propose-a-special-interest-group","title":"Propose a Special Interest Group","text":"
To propose a special interest group, create an issue in the TAC GitHub repository using the Special Interest Group template. The issue should be named \"Special Interest Group Proposal: \\<name of special interest group>\". The issue should include the following information:
The TAC will review the special interest group proposal first by providing comments in the issue and secondly by bringing the special interest group proposal to a discussion and vote in a TAC meeting.
The decision of the vote will be documented in the issue. If the special interest group is approved, a discussion channel in Discord will be created. In addition, we will work with the OpenWallet Foundation operations team to schedule a meeting on the OpenWallet Foundation calendar. If necessary, a GitHub repository and/or mailing list will also be created at the request of the special interest group leader(s).
"},{"location":"governance/special-interest-group-process/#special-interest-group-procedures","title":"Special Interest Group Procedures","text":"
The special interest group can decide on the mechanism for running the SIG. Meeting minutes and a log of decisions that have been made should be kept for ensuring continuity of the special interest group. The special interest group should update the issue to reflect where the meeting notes and log of decisions is kept or use the issue directly to capture this information.
"},{"location":"governance/special-interest-group-process/#reporting-on-special-interest-group-activities","title":"Reporting on Special Interest Group Activities","text":"
Every quarter the special interest group leader should report on the activities of the SIG at a TAC meeting. This will ensure that the SIG is still active and that there is still value in hosting the special interest group. Please see the schedule for when these updates should occur.
"},{"location":"governance/tac/","title":"Open Wallet Foundation TAC composition","text":""},{"location":"governance/tac/#current-composition","title":"Current Composition","text":"Member (alphabetical by first name) Representing David Zeuthen Google Jaehoon (Ace) Shim At Large Pete Cooling Visa Rolson Quadras Gen Stavros Kounis (vice chair) At Large Tracy Kuhrt (chair) Accenture Wenjing Chu FutureWei Technologies"},{"location":"governance/tac/#history","title":"History","text":""},{"location":"governance/tac/#2023-03-08","title":"2023-03-08","text":"
A task force is a group that is focused on a task with limited scope and fixed time to complete. Unlike a special interest group, a task force will have a specific set of deliverables or work products that it will create and be limited in time to completion. A task force can be created by anyone in the OpenWallet Foundation community and must be proposed to and approved by the TAC.
"},{"location":"governance/task-force-process/#propose-a-task-force","title":"Propose a Task Force","text":"
To propose a task force, create an issue in the TAC GitHub repository. The issue should be named \"Task Force Proposal: \\<name of task force>\". The issue should include the following information:
The TAC will review the task force proposal first by providing comments in the issue and secondly by bringing the task force proposal to a discussion and vote in a TAC meeting.
The decision of the vote will be documented in the issue. If the task force is approved, a discussion channel in Discord will be created. In addition, we will work with the OpenWallet Foundation operations team to schedule a meeting on the OpenWallet Foundation calendar. If necessary, a GitHub repository and/or mailing list will also be created at the request of the task force leader(s).
"},{"location":"governance/task-force-process/#task-force-procedures","title":"Task Force Procedures","text":"
The task force can decide on the mechanism for creating the deliverables. Meeting minutes and a log of decisions that have been made should be kept for ensuring continuity of the task force. The task force should update the issue to reflect where the meeting notes and log of decisions is kept or use the issue directly to capture this information.
"},{"location":"governance/task-force-process/#reporting-on-task-force-completion-of-deliverables","title":"Reporting on Task Force Completion of Deliverables","text":"
Upon completion of the task force's deliverables, the task force should arrange a time with the TAC chair to present the deliverables at a TAC meeting. This can be accomplished by sending an email to the TAC mailing list at tac@lists.openwallet.foundation.
"},{"location":"governance/task-force-process/#requesting-an-extension-on-completion-date","title":"Requesting an Extension on Completion Date","text":"
If the task force is not able to complete the deliverables by the specified completion date, then the leader of the task force should arrange a time with the TAC chair to discuss the extension at a TAC meeting. This discussion should include information on the current status, the delays, and the expected updates to the schedule. This can be accomplished by sending an email to the TAC mailing list at tac@lists.openwallet.foundation.
TAC meetings are intended to be open to observe by Sponsors, contributors to any TAC Project, and others in the general public interested in the OpenWallet Foundation.
The meetings will be held bi-weekly starting Wednesday, March 8, 2023 at 7:00am PT.
Join link with meeting ID and passcode embedded: https://zoom-lfx.platform.linuxfoundation.org/meeting/94569749258?password=68170ae3-3074-45fb-9b2e-4c479ed7d8d7
The TAC is responsible for maintaining an overall strategic vision for technical collaboration and coordinating collaboration among Technical Projects, including development of an overall technical vision for the community.
Section 5 of https://cdn.platform.linuxfoundation.org/agreements/openwalletfoundation.pdf
TAC Chair Election
Tracy Kuhrt is running unopposed \u2013 will move to email vote to formalize
Composition
Accenture - Tracy Kuhrt
Futurewei - Wenjing Chu
Gen Digital - Drummond Reed
Visa - Marie Austenaa
\u201cat large\u201d representative #1 appointed by vote of the TAC
\u201cat large\u201d representative #2 appointed by vote of the TAC
one representative appointed by the technical oversight body (e.g., a technical steering committee) of each TAC Project
Tracy gave an overview of a proposed website and policies for the TAC at https://github.com/openwallet-foundation/tac
Open Discussion
The Governing Board met yesterday and appointed Daniel Goldscheider as Interim Executive Director. Daniel introduced himself and provided his thoughts on the future of OWF.
A suggestion was made for a landscape review. A comment was made that that work has begun here.
Conduct an email vote for the Governance documents approval and adoption - results 3 TAC members voted in favor; 1 TAC member abstained
Conduct an email vote for the TAC \"at large\" schedule and process - results 3 TAC members voted in favor; 1 TAC member abstained
Todd to confirm whether the TAC can create an alternate policy or whether the Governing Board will need to update the charter to reflect - currently no policy for TAC alternates; if we want this, we would need to present this to the GB to get a charter update
The TAC would like to recommend that the board create an alternate policy for the TAC.
The language will be similar to the following \"A TAC member can designate an alternate for a specific meeting, and has to notify the chair in advance.\"
Tracy to create a pull request to update the project proposal template to include links to the mission and project lifecycle - pull request created and merged
Create a GitHub organization (openwallet-foundation-labs) to host incoming labs - not yet completed
TAC \"at large\" election results
Jeremie Miller
Stavros Kounis
Architecture SIG update
Digital wallet engine architecture topics brainstorm - please add any topics that you think we missed
Discussion on MOST important architecture topic - please add to the discussion
A question was brought up about the status of this group and whether it is a task force or a special interest group. The TAC formalized the group as a special interest group under the TAC.
Call for code from the community
Next steps
Discussion regarding the upcoming conference season, including IIW, EIC, and others.
Suggestion was made to create an OpenWallet Foundation event calendar.
Tracy to rename the architecture-task-force GitHub repo to architecture-sig - completed
Jenn to rename the meeting invite for the Outside Architecture Special Interest Group to reflect that the name should be the Architecture SIG - completed
Jenn to add Stavros to the TAC meeting invite - completed
Jenn to add Jeremie to the TAC meeting invite - completed
Create a GitHub organization (openwallet-foundation-labs) to host incoming labs - completed
Priorities
Projects
Pipeline of projects
Getting a method of tracking and accessing projects
Rule book / guide on the evaluation process and criteria for new projects
Technical Focus
Cloud based, edge based, and hybrid wallets
Common components for wallets
Specific components for money, identity, and object wallets
Collaboration between OWF and European Commission
Tracking changes in the next European Digital Identity Wallet Architecture and Reference Framework (ARF) and making sure it lines up with OWF thinking
Maintaining dialog and exploring alignment
Internet Identity Workshop (IIW) updates
Topics on digital wallets, credentials, and interoperability
Sessions on EUDI and the ARF
A number of OpenWallet topics will be discussed on day 2 and 3
Discussions about the Linux Foundation Trust umbrella
Call for code from the community
Completing the assessment framework may allow people to better understand what type of projects should be considered for contribution
Document process for creating a task force - pull request -- completed
Welcome new TAC member
We welcomed Troy Ronda from Gen Digital who is replacing Drummond Reed
Task Force Proposal
RESOLVED: That the task force process documented in this pull request and rendered on this page and using this issue template is hereby confirmed, approved, and adopted.
Unanimously passed
Assessment Framework
How do we want to assess incoming projects?
Currently documented project acceptance process
Each Project Lifecycle Stage documents its acceptance criteria
What are the types of projects that we want to include?
Alignment with the OpenWallet Foundation mission
\u201cvarious open source, open data and/or other open projects relating to or supporting development of digital wallets, including infrastructure and support initiatives related\u201d
Discussion
Projects that would satisfy components of the conceptual architecture created by the architecture SIG
Projects that would fit in slide 6 of the OpenWallet Foundation Overview 2023.02.23 deck
Update Task Force process to include information on optional mailing lists and capturing meeting notes -- commit -- completed
Create process for Special Interest Groups similar to Task Force process and cross link the two processes together -- PR -- completed
New lab proposals
SD-JWT Kotlin Library
RESOLVED: That the SD-JWT Kotlin Library lab is hereby confirmed, approved, and adopted.
Unanimously approved by the present TAC voting members.
SD-JWT Python Reference Implementation
RESOLVED: That the SD-JWT Python Reference Implementation lab is hereby confirmed, approved, and adopted.
Unanimously approved by the present TAC voting members.
Special Interest Group process proposal
RESOLVED: That the special interest group (SIG) process documented in this pull request and rendered on this page and using this issue template is hereby confirmed, approved, and adopted.
Unanimously approved by the present TAC voting members.
OID4VCI and OID4VP Due Diligence Task Force
Support exists for this task force, but we ran out of time to conclude the discussion.
Request for comments on OID4VCI and OID4VP Due Diligence Task Force proposal and +1 if you are interested in participating.
Hakan will update to reflect comments so that we can bring this to a vote at the next TAC meeting.
Work with Fabian to transfer SD-JWT Kotlin repo to openwallet-foundation-labs organization -- completed SD-JWT-Kotlin
Work with Daniel to transfer SD-JWT Python repo to openwallet-foundation-labs organization -- in progress
Comment on OID4VC Due Diligence Task Force proposal and update to reflect comments -- in progress
Update on TAC alternates
The Governing Board agreed to modify the Charter to include the following language:
Updated Language
5.c) TAC meetings are intended to be open to observe by Sponsors, contributors to any TAC Project and others in the general public interested in the OpenWallet Foundation. The TAC may decide whether to allow named representatives (one per voting member) to attend as an alternate.
OID4VC Due Diligence Task Force
Unanimously approved by the present TAC voting members.
Credential Format Comparison SIG
Unanimously approved by the present TAC voting members.
OID4VC Due Diligence Task Force kickoff meeting \u2013 Wednesday, the 21st at 5pm CEST
Architecture SIG merged Key Management Services conceptual architecture
Credential Format Comparison SIG will meet on Wednesdays at 5pm CEST on alternate weeks to the OID4VC Due Diligence Task Force. Kickoff meeting planned for June 28th
Review action items from last meeting
Work with Daniel to transfer SD-JWT Python repo to openwallet-foundation-labs organization -- in progress
Create proposed language for TAC alternates -- completed
Add link to community calendar to website -- completed
OID4VC Due Diligence Task Force -- completed
Create Discord channel (#oid4vc-due-diligence-tf)
Add information about Task Forces to TAC website
Add link to the above to the OpenWallet Foundation GitHub Profile
Work with Torsten to get GitHub repo transferred to OpenWallet Foundation
Determine leader of the SIG (Mirko Molik)
Add information about Special Interest Groups to TAC website
Add link to the above to the OpenWallet Foundation GitHub Profile
TAC Alternates Policy
RESOLVED: That the TAC Alternates Policy is hereby confirmed, approved, and adopted.
Unanimously approved by the present TAC voting members.
Call for code from the community
A question was asked whether we were tracking a wishlist for potential projects
In general, we are looking for projects that fit with the vision of the OpenWallet Foundation. Those that are focused on wallet engine related to identity, money, and objects
We previously were capturing potential code projects using this Google sheet
If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up
Open discussion and next steps
Relative to the Credential Format Comparison SIG, the ToIP Foundation has just started a task force on the same thing for credential exchange protocols. See this spreadsheet
David Alexander will present on wallets and personal data stores at the next meeting and we will discuss further
Background blog post
Thread from Architecture SIG on personal data
There\u2019s also the Decentralized Web Node project that Block is leading at the Decentralized Identity Foundation
Credential Format Comparison SIG will meet on Wednesdays at 4pm CEST on alternate weeks to the TAC. Kickoff meeting planned for July 7th.
OID4VC Due Diligence task force will meet weekly on Wednesdays at 5pm CEST.
Pete Cooling was introduced as Visa's TAC voting representative.
Review action items from last meeting
Determine vice chair language -- completed
Work with Daniel to transfer SD-JWT Python repo to openwallet-foundation-labs organization -- in progress
Credential Format Comparison SIG: Work with Torsten to get GitHub repo transferred to OpenWallet Foundation -- in progress
Vice chair seat and responsibilities
RESOLVED: That the Vice Chair Seat and Responsibilities is hereby confirmed, approved, and adopted.
Unanimously approved by the present TAC voting members.
Voting schedule
Call for nominations: June 28
End of call for nominations: July 5, Noon PT
A ballot will be distributed on: July 5 by end of day PT
The election will be completed on: July 11, Noon PT
Election results are announced at the July 12 meeting
If you would like to submit your nomination for TAC Vice Chair, please create an issue at https://github.com/openwallet-foundation/tac/issues
Title of issue: [NOMINATION]: 2023 Vice Chair - Name
Include a short bio, outline your qualifications, and provide a statement explaining why you would be a good choice for the seat
Wallets and personal data stores
Background blog post
Thread from Architecture SIG on personal data
Presentation by David Alexander
Call for code from the community
If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up
For Associate non-profit members of the OpenWallet Foundation: voting is now open to select the Associate Representative for the Governing Board. Please email operations@openwallet.foundation if you have any questions about your organization's participation in this vote.
Review action items from last meeting
Work with Daniel to transfer SD-JWT Python repo to openwallet-foundation-labs organization -- in progress
Credential Format Comparison SIG: Work with Torsten to get GitHub repo transferred to OpenWallet Foundation -- completed (new repo created)
Review Farmworker Wallet OS project proposal - all
Vice Chair
RESOLVED: That the voting schedule for vice chair is hereby revised, approved, and adopted as specified.
Revised voting schedule
Call for nominations: July 12
End of call for nominations: August 2, Noon PT
A ballot will be distributed on: August 2 by end of day PT
The election will be completed on: August 8, Noon PT
Election results are announced at the August 9 meeting
Unanimously approved by the present TAC voting members.
Farmworker Wallet OS project proposal
Video shared on Discord
Question asking for clarification of the scope of the contribution
Concerns raised about the licensing terms of the generated output from Mendix
Mendix does not make any intellectual property claims on the output
Question raised about the proposed license that will need to be run past LF legal and the Governing Board
Need to consider naming of the repos to ensure that it allows people to determine that they are part of the same project
Question raised about the difference between the Aries SDK proposed to be part of this project and the one in Hyperledger
The one in this project is a wrapper around the SDK in Hyperledger that can be used by Mendix developers
Continue conversation on the pull request
Call for code from the community
If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up
Credential Format Comparison SIG will meet on Wednesdays at 4pm CEST on alternate weeks to the TAC
OID4VC Due Diligence task force will meet weekly on Wednesdays at 5pm CEST
Architecture SIG meets weekly on Mondays at 11am US/Pacific
Vice chair nomination period open until August 2nd. Please submit your nominations
TAC website now available at https://tac.openwallet.foundation
OpenWallet Foundation Discord has a custom invite link: https://discord.gg/openwalletfoundation
Review action items from last meeting
Work with Daniel to transfer SD-JWT Python repo to openwallet-foundation-labs organization -- in progress
Review Farmworker Wallet OS project proposal -- in progress
Review the proposed license of Farmworker Wallet OS project with LF legal -- completed
Materials for MkDocs Insiders version
RESOLVED: That the TAC recommends to the Governing Board the sponsorship of Material for MkDocs to obtain access to the Insiders Version is hereby confirmed, approved, and adopted.
Proposed resolution was not voted on. It was suggested that we develop a proposal that would include other tools that the technical community would need to limit the number of requests to the Governing Board.
Farmworker Wallet OS project proposal
Discussion items
Code of Conduct
plan to change to use OWF\u2019s CoC
we may need to consider changing the template since it asks for the current CoC
License
change to use Apache 2.0 license
Project Governance
no change needed at this point
Repo names
Discussion was had to make sure that we are prefixing repo names with the project name to ensure that it is easy for someone to find all repos associated with a single project
Interoperable roadmap
No limit on what will be supported
Hosting Aries-specific stuff at OWF
TAC considers wrappers of other projects to be better suited to be included with the parent project
Tracy to work with Jorge on creating a lab proposal for Hyperledger for the Aries-specific wrappers
Jorge to update proposal to reflect the above recommendation
Call for code from the community
If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up
Jorge to update code of conduct on Farmworker Wallet OS proposal -- completed
Create repositories for the Farmworker Wallet OS Lab
Share document with governance best practices -- completed
OWF Project Guidance -- this document assumes a fairly mature project that consists of a technical steering committee and maintainers for the project. Please comment and add your thoughts/suggestions.
Credential Format Comparison SIG will meet on Wednesdays at 4pm CEST on alternate weeks to the TAC
OID4VC Due Diligence task force will meet weekly on Tuesdays at 5pm CEST
Architecture SIG meets weekly on Mondays at 11am US/Pacific
sd-jwt-python source is now available
Review action items from last meeting
Work with Daniel to transfer SD-JWT Python repo to openwallet-foundation-labs organization -- completed
Review Farmworker Wallet OS project proposal -- in progress
Tracy to work with Jorge on creating a lab proposal for Hyperledger for the Aries-specific wrappers -- completed
Develop list of budget line items needed by the TAC \u2013 in progress
Farmworker Wallet OS project proposal
RESOLVED: That the Farmworker Wallet OS lab is hereby confirmed, approved, and adopted.
Unanimously approved by the present TAC voting members.
Budget Request to Governing Board
Thread started on Discord
Sponsorship of Material for MkDocs to obtain access to the Insiders Version at $125/month to support the TAC website
Wiki (Confluence or similar)
License Scanning
Package Hosting - GitHub? ghcr.io? Is there a package hosting solution for all technologies that exists?
Playground/Sandbox Hosting
Others?
Vice Chair
RESOLVED: That Stavros Kounis is hereby confirmed and approved as the TAC Vice Chair
Approved by the present TAC voting members with Stavros abstaining.
Call for code from the community
If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up
Question asked about code proposal that depends on Aries/Bifold and whether that could be submitted to OWF?
If the project is only dependent on Aries/Bifold, then it can be submitted to OWF.
If, however the project is a wrapper of Aries/Bifold, then that should probably be submitted to Hyperledger.
Question about project governance best practices and whether we could document these best practices for new projects.
OWF Project Guidance -- this document assumes a fairly mature project that consists of a technical steering committee and maintainers for the project. Please comment and add your thoughts/suggestions.
In addition, we can look at Hyperledger's Project Best Practices for additional thoughts on guiding OpenWallet Foundation projects.
Credential Format Comparison SIG will meet on Wednesdays at 4pm CEST on alternate weeks to the TAC
OID4VC Due Diligence task force will meet weekly on Tuesdays at 5pm CEST
Architecture SIG meets weekly on Mondays at 11am US/Pacific
Farmworker Wallet OS repositories created
Project pages created for each approved project on the TAC website
Slide deck available covering the OWF Project Proposal Process
Review action items from last meeting
Continue to work on budget line items -- all
Jorge to update code of conduct on Farmworker Wallet OS proposal -- completed
Create repositories for the Farmworker Wallet OS Lab -- completed
Share document with governance best practices -- completed
Comment on OWF Project Guidance - all
Budget Request to Governing Board
Sponsorship of Material for MkDocs to obtain access to the Insiders Version at $125/month to support the TAC website
Wiki
Options:
Dokuwiki is currently included in our current LFIT budget
Confluence would be an additional $800/month
Continue utilizing GitHub wiki
Update the TAC website as necessary
Discussion:
Confluence is nice to allow for the ability to search across the entire foundation
Consider the migration costs
Confluence has a lot of nice features that GitHub wiki and Dokuwiki do not have
It is easier to bring markdown files into Confluence than to export to markdown
Most documentation for projects will be captured within projects as markdown files and hosted using something like ReadTheDocs.io or GitHub Pages
We do not currently have anyone that is asking for Confluence
If we sponsor Material for Mkdocs insiders version, then all OpenWallet Foundation projects will be able to utilize
Outcome: We will postpone asking for budget until we have a need
License Scanning
Another project within the Linux Foundation cost is $65,000/year
We should ask for this as it allows us to remain compliant with the open licenses
Package Hosting - GitHub? ghcr.io? Is there a package hosting solution for all technologies that exists?
ghcr.io (GitHub Packages) is free for all public GitHub repositories \u2013 recommend we start there
Support for Package Registries
The only thing that we have currently that is not supported by GitHub Packages is Python
Playground/Sandbox Hosting
We do not yet have a price for this, but following are some of the things that we could see needing a sandbox
Accessing server-side APIs
Deployment of server-based reference wallet
Interop testing
Reference implementation of data objects that a wallet contain - example VC issuance and verification
Harm mentioned that he has some information on the infrastructure costs for hosting the European Interoperability Test Bed, which was presented to the architecture SIG on March 27, 2023. Harm will provide information on these costs
Harm is also interested in bringing the Interoperability Test Bed as a project to the OWF
DevSecOps
The Linux Foundation is recommending that projects use GH Actions
Automated security/code scanning
SonarQube - Static code analysis
OWF Project Governance Guidance
Request to review, add comments and feedback
David Alexander recommended that we include information about momentum and duty of care and working across the foundation
Stavros asked if a TSC is required for projects
No, a TSC is not mandatory. The idea is that if a project gets big enough where all the maintainers cannot get together easily and make decisions, more governance framework is needed, and this is the way to go in that case.
As such, we should make sure that this document provides the right level of guidance for projects at different stages in their lifecycle
Call for code from the community
If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up
Next time we meet, we will be reviewing the VC-API prject proposal
Credential Format Comparison SIG will meet on Wednesdays at 4pm CEST on alternate weeks to the TAC (next call September 13)
OID4VC Due Diligence task force will meet bi-weekly on Tuesdays at 5pm CEST (next call September 12)
Architecture SIG meets weekly on Mondays at 11am US/Pacific (next call September 11)
Review action items from last meeting
Review, comment, and add feedback to OWF Project Governance Guidance - all
Review, comment, and add feedback to VC-API prject proposal - all
Provide infrastructure costs for the European Interoperability Test Bed - Harm Jan Arendshorst
Welcome new TAC member
We welcomed David Zeuthen, Google premier member representative
VC-API Project Proposal
How does this codebase relate to the energywebfoundation/ssi?
Does this proposal refer to the ssi repository OR only to work under the /vc-api path?
The intention is to bring over only the /vc-api path. We could consider whether it makes sense to bring over the other application, but it would require a separate proposal.
Are there dependencies or references to any implementation outside this folder that need attention if it is the latter?
Refer to the \"Source Control\" section of the proposal for information on what the dependencies are for the VC-API
Could we prepare a list of all the single repositories the vc-api needs and will be part of this proposal? I would also suggest supplementing this list with the purpose of these additional repos and their relationship/dependencies to vc-api.
This is captured in the \"Source Control\" section of the proposal.
For licensing purposes, will we leave related repositories in the organization they currently are? Should we expect a licensing conflict in this case?
John will follow up on the license with Energy Web Foundation.
What referenced tutorials and documentation will moved from energywebfoundation GitHub organization to the OWF?
Yes, we can move the tutorials and documentation into OWF.
Is this project an implementation of a VC API server or also client/wallet libraries?
Server only
Is this project based on the latest version of the CCG VC API? Does it already implement the full community report?
It implements the latest published version of the CCG VC API. It may be missing one or two endpoints. I don't think that we have implemented derived presentation.
Which credential formats and signature formats are supported?
Those that are supported by SpruceID's DIDKit
How have you tested interop?
We have not yet tested interop. The testing that we have done is with the available test suites.
What will be the prefix for this project?
We need to determine a way in which projects can be separated if they implement the same specification. Project prefixes are a way to do this and will allow us to trademark them in the future.
License
John to follow up with Energy Web Foundation about the possibility or re-licensing
Develop recommendation for the OWF governing board on licenses that are compatible with Apache 2.0
Missing DCO on existing repository
Call for code from the community
If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up
Credential Format Comparison SIG will meet on Wednesdays at 4pm CEST on alternate weeks to the TAC (next call September 27)
OID4VC Due Diligence task force will meet bi-weekly on Tuesdays at 5pm CEST (next call September 26)
Architecture SIG meets weekly on Mondays at 11am US/Pacific (next call September 25)
New Project Proposal - Wallet Framework .NET - Please review
Suggested Future Project - Support the Apple pass format
Review action items from last meeting
Review, comment, and add feedback to OWF Project Governance Guidance by October 4th - all
Review, comment, and add feedback to VC-API project proposal - all
Provide infrastructure costs for the European Interoperability Test Bed - Harm Jan Arendshorst
Create recommendation for governing board for intellectual property policy -- Tracy -- completed
Update VC-API PR to answer questions asked during the meeting -- John \u2013 completed
Determine if Energy Web Foundation is willing to relicense VC-API -- John \u2013 completed
SIG Proposal - SSI Wallet and Agent Overviews
RESOLVED: That the SSI Wallet and Agent Overviews special interest group is hereby confirmed, approved, and adopted.
Unanimously approved by the present TAC voting members
SIG Proposal - Anti-Correlation and Anti-Profiling
RESOLVED: That the Anti-Correlation and Anti-Profiling special interest group is hereby confirmed, approved, and adopted.
Unanimously approved by the present TAC voting members
VC-API Project Proposal
Discussion
RESOLVED: That the VC-API lab is hereby confirmed, approved, and adopted.
Since we did not have enough TAC voting members to meet the \u2154 supermajority vote, we will conduct an email vote.
Intellectual Property Policy
Apache 2.0 for source code
CC-BY-4.0 for documentation
Allowed Third Party License Policy
RESOLVED: That the proposed Intellectual Property Policy will be forwarded to the Governing Board for consideration.
Please review and provide your feedback
We will vote on this next time we meet
Call for code from the community
If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up
Open discussion and next steps
Next meeting is October 4, 2023
Discussed whether to move to weekly meetings to support influx of project proposals. It was determined that we could be more efficient on these calls if we commented on the PRs when they are submitted to get questions answered that may delay the vote.
Credential Format Comparison SIG meets bi-weekly on Wednesdays at 4pm CEST on alternate weeks to the TAC (next call October 11)
OID4VC Due Diligence task force meets bi-weekly on Tuesdays at 5pm CEST (next call October 24)
Architecture SIG meets weekly on Mondays at 11am US/Pacific (next call October 16)
Please submit any code proposals using the process defined at openwallet-foundation/project-proposals. We will review proposals in the order submitted at a TAC meeting. If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up.
Pre-IIW Developer Face-to-Face October 9
Review action items from last meeting
Review, comment, and add feedback to OWF Project Governance Guidance - all
Review, comment, and add feedback to the Intellectual Property Proposal - all
Review, comment, and add feedback to the Wallet Framework .NET project proposal - all
Provide infrastructure costs for the European Interoperability Test Bed - Harm Jan Arendshorst
Digital Wallet and Agent Overviews SIG onboarding - completed
Anti-Correlation and Anti-Profiling SIG Onboarding - completed
Conduct email vote for VC-API project approval - Tracy - completed and approved
Project Proposal - Wallet Framework .NET
RESOLVED: That the Wallet Framework .NET proposal is hereby confirmed, approved, and adopted.
Unanimously approved by the present TAC voting members.
Project Proposal - Android Identity Library
RESOLVED: That the Android Identity Library proposal is hereby confirmed, approved, and adopted.
Move to next meeting
Intellectual Property Policy
Apache 2.0 for source code
CC-BY-4.0 for documentation
Allowed Third Party License Policy
Open Standards and Specifications
RESOLVED: That the proposed Intellectual Property Policy will be forwarded to the Governing Board for consideration.
Conduct an email vote
Open discussion and next steps
Discussion regarding conflict of the Safe Wallet SIG with other meetings
Standing agenda items that we might want to add:
Socialization of what others in the community are doing
Architecture SIG meets weekly on Mondays at 11am US/Pacific (next call October 30)
OID4VC Due Diligence task force meets bi-weekly on Tuesdays at 5pm CEST (next call October 24)
Safe Wallet SIG meets weekly on Tuesdays at 8am US/Pacific (next call October 24)
Credential Format Comparison SIG meets bi-weekly on Wednesdays at 4pm CEST on alternate weeks to the TAC (next call October 25)
Digital Wallets and Agents Overviews SIG meets biweekly on Thursdays at 5:00pm CEST on alternate weeks to the TAC (next meeting October 26)
Please submit any code proposals using the process defined at https://github.com/openwallet-foundation/project-proposals. We will review proposals in the order submitted at a TAC meeting. If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up.
Review action items from last meeting
Conduct email vote on the Intellectual Property Policy \u2013 completed
Add project page for the Wallet Framework .NET project \u2013 completed
Work with Sebastian to transfer Wallet Framework .NET project code to OWF \u2013 completed
Review, comment, and add feedback to Android Identity Library project proposal - all
Provide infrastructure costs for the European Interoperability Test Bed - Harm Jan Arendshorst
Welcome New TAC Member
Mike Varley will represent Gen Digital moving forward.
Hold for next meeting as Mike could not attend today.
Legal Discussion
Discuss project charters
Sample charter
Intake form
Copyleft vs. Permissive licenses (LF allows any OSI license. The OWF can decide on whether they only want permissive license.)
Project Proposal - Android Identity Library
RESOLVED: That the Android Identity Library proposal is hereby confirmed, approved, and adopted.
6* Approve, 1 Abstain (David) - Project accepted
Info (*)
During the meeting, Pete abstained. After the meeting, Pete changed his vote via email from Abstain to Approve.
Project Proposal - SD-JWT JS
RESOLVED: That the SD-JWT JS lab proposal is hereby confirmed, approved, and adopted.
Some discussion about why a new project is needed instead of utilizing existing typescript implementations.
Open discussion and next steps
David Alexander suggested that the OpenWallet Foundation work closely with MyData.
Architecture SIG meets weekly on Mondays at 11am US/Pacific (next call November 6)
OID4VC Due Diligence task force meets bi-weekly on Tuesdays at 5pm CEST (next call November 7)
Safe Wallet SIG meets weekly on Tuesdays at 8am US/Pacific (next call November 7)
Credential Format Comparison SIG meets bi-weekly on Wednesdays at 4pm CEST on alternate weeks to the TAC (next call November 8)
Digital Wallets and Agents Overviews SIG meets biweekly on Thursdays at 5:00pm CEST on the same weeks as the TAC (next meeting November 2)
Please submit any code proposals using the process defined at https://github.com/openwallet-foundation/project-proposals. We will review proposals in the order submitted at a TAC meeting. If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up.
Review action items from last meeting
Update project proposal template to make it easier for people to understand what the TAC is expecting for answers related to each question -- Tracy -- completed
Architecture SIG meets weekly on Mondays at 11am US/Pacific (next call November 27; skipping week of US Thanksgiving)
OID4VC Due Diligence task force meets bi-weekly on Tuesdays at 5pm CET (next call November 21)
Safe Wallet SIG meets weekly on Tuesdays at 8am US/Pacific (next call November 21)
Credential Format Comparison SIG meets bi-weekly on Wednesdays at 4pm CET on alternate weeks to the TAC (next call November 22)
Digital Wallets and Agents Overviews SIG meets biweekly on Thursdays at 5:00pm CET on the same weeks as the TAC (next meeting November 16)
Please submit any code proposals using the process defined at https://github.com/openwallet-foundation/project-proposals. We will review proposals in the order submitted at a TAC meeting. If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up.
SIG quarterly updates will begin in January 2024
Review action items from last meeting
Update \"permissive license\" to \"OSI-approved permissive license\" in the project lifecycle and template PRs \u2013 completed and merged (lifecycle PR 69 and template PR 22)
Update Paid Tooling PR to reflect other requests require the Governing Board approval \u2013 completed and merged
Onboarding SD-JWT JS lab
Create sd-jwt-js repo in OpenWallet Foundation Labs GitHub \u2013 completed
Architecture SIG meets weekly on Mondays at 11am US/Pacific (next call December 4)
OID4VC Due Diligence task force meets bi-weekly on Tuesdays at 5pm CET (next call December 5)
Safe Wallet SIG meets weekly on Tuesdays at 7am US/Pacific (next call December 5)
Credential Format Comparison SIG meets bi-weekly on Wednesdays at 4pm CET on alternate weeks to the TAC (next call December 6)
Digital Wallets and Agents Overviews SIG meets biweekly on Thursdays at 5:00pm CET on the same weeks as the TAC (next meeting November 30)
Please submit any code proposals using the process defined at https://github.com/openwallet-foundation/project-proposals. We will review proposals in the order submitted at a TAC meeting. If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up
SIG quarterly updates will begin in January 2024
Review action items from last meeting
Onboarding SD-JWT Rust lab
Create sd-jwt-rust repo in OpenWallet Foundation Labs GitHub \u2013 completed
Architecture SIG meets weekly on Mondays at 11am US/Pacific (next call January 8)
OID4VC Due Diligence task force meets bi-weekly on Tuesdays at 5pm CET (next call December 19)
Safe Wallet SIG meets weekly on Tuesdays at 7am US/Pacific (next call December 19)
Credential Format Comparison SIG meets bi-weekly on Wednesdays at 4pm CET on alternate weeks to the TAC (next call December 20)
Digital Wallets and Agents Overviews SIG meets biweekly on Thursdays at 5:00pm CET on the same weeks as the TAC (next meeting December 14)
Please submit any code proposals using the process defined at https://github.com/openwallet-foundation/project-proposals. We will review proposals in the order submitted at a TAC meeting. If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up
Review action items from last meeting
Onboard SD-JWT .NET \u2013 completed
Transfer sd-jwt-dotnet repo to OpenWallet Foundation Labs GitHub \u2013 completed
Follow up with LF Legal on project intake form \u2013 completed
Work with John Henderson to transfer VC-API project to OpenWallet Foundation Labs \u2013 in progress
Work with David Zeuthen to transfer Android Identity Library project to OpenWallet Foundation Labs \u2013 completed
Moving to LFX Meetings
Reviewed LFX Meetings
See LFX Meetings Management Guide
Resolution: Add Schedule for Quarterly SIG Updates
RESOLVED: That the pull request \"Resolution: Add Schedule for Quarterly SIG Updates\" is hereby confirmed, approved, and adopted.
Motion Wenjing, second Jeremie
Resolution passed with no objections or abstentions
2023 Retrospective
Reviewed accomplishments
Also include in the accomplishments the face-to-face and the discussion with LF Legal on project charters
Retrospective
Shoutouts?
Google for hosting us at our face-to-face in Mountain View
Tracy for leading meetings
SIG and Task Force leaders
What went well?
Good structure on the TAC
Opportunity to collaborate
Consistency of how TAC meetings are managed and the access to the information needed so that you can do prep
Transparency
Inclusiveness
Team spirit
Advocacy
Provided confidence to move from being a consumer of open source to actually publishing open source at OWF
Learning process of what's involved in open source has been incredibly useful
Collaboration
Donation
Strong community engagement
Support OpenWallet has received in terms of projects, sponsors and Governmental Advisory Council members
What could we do differently next year?
Include voting members on the agenda and let people know who can vote at these meetings
Recommendations for next year
List of events for next year -- include in the #events channel on Discord
Creating a resource of slides that others have presented at conferences to present OWF
Challenge: helping projects grow within the OWF
Challenge: helping projects collaborate and work with one another
Engaging with the EUDI and bringing projects into OWF
Interoperability is a topic for us to focus on next year. Not just for the same protocols, but also across protocols. SIDI is also something that we should work closely with
Publish a white paper documenting our overall architectural considerations for open wallets (started already in the Architecture SIG)
Engaging with Trust Over IP
Open discussion and next steps
Vulnerability Disclosure Policy
Look at creating this next year
Resources:
OpenSSF Guide to implementing a coordinated vulnerability disclosure process for open source projects
Architecture SIG meets weekly on Mondays at 11am US/Pacific (next call January 15)
OID4VC Due Diligence task force meets bi-weekly on Tuesdays at 5pm CET (next call January 17)
Safe Wallet SIG meets weekly on Tuesdays at 7am US/Pacific (next call January 16)
Credential Format Comparison SIG meets bi-weekly on Wednesdays at 4pm CET on alternate weeks to the TAC (next call January 17)
Digital Wallets and Agents Overviews SIG meets biweekly on Thursdays at 5:00pm CET on the same weeks as the TAC (next meeting January 11)
Please submit any code proposals using the process defined at https://github.com/openwallet-foundation/project-proposals. We will review proposals in the order submitted at a TAC meeting. If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up
Review action items from last meeting
Work with John Henderson to transfer VC-API project to OpenWallet Foundation Labs \u2013 completed
See Architecture SIG Q1 2024 Update for the answers to the following questions:
What is the Architecture SIG?
What has the Architecture SIG accomplished?
What is next for the Architecture SIG?
Where can I get information on the Architecture SIG?
How do I participate in the Architecture SIG?
Discussion on how the Architecture SIG should work with projects
In general, people see the role of the architecture SIG as a group that provides information on the state of the digital wallet architectues that can be used to provide insight into projects that may be missing from the OWF and in the long term a place that will help projects work more closely together.
Discuss Drafted Vulnerability Disclosure Policy
Discuss pull request
Rework to consider the following audiences: reporters, people using the code, and maintainers
Separate out standard text from project-specific text
Goals for 2024
What specific goals does the TAC have for 2024?
Brian suggested looking at what other TAC goals have been
Architecture SIG meets weekly on Mondays at 11am US/Pacific (next call January 29)
OID4VC Due Diligence task force meets bi-weekly on Tuesdays at 5pm CET (next call January 30)
Safe Wallet SIG meets weekly on Tuesdays at 7am US/Pacific (next call January 30)
Credential Format Comparison SIG meets bi-weekly on Wednesdays at 4pm CET on alternate weeks to the TAC (next call January 31)
Digital Wallets and Agents Overviews SIG meets biweekly on Thursdays at 5:00pm CET on the same weeks as the TAC (next meeting January 25)
Please submit any code proposals using the process defined at https://github.com/openwallet-foundation/project-proposals. We will review proposals in the order submitted at a TAC meeting. If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up
Review action items from last meeting
List of TAC goals from other LF projects \u2013 Brian
Other projects at the LF only have a responsiblities list with the main goal of the TAC, TOC, or TSC to successfully carry out these responsibilities
Hyperledger Foundation has been putting together goals for the last couple of years (2023 Goals, 2024 Goals)
Architecture SIG meets weekly on Mondays at 11am US/Pacific (next call February 12)
OID4VC Due Diligence task force meets bi-weekly on Tuesdays at 5pm CET (next call February 13)
Safe Wallet SIG meets weekly on Tuesdays at 7am US/Pacific (next call February 13)
Credential Format Comparison SIG meets bi-weekly on Wednesdays at 4pm CET on alternate weeks to the TAC (next call February 14)
Digital Wallets and Agents Overviews SIG meets biweekly on Thursdays at 5:00pm CET on the same weeks as the TAC (next meeting February 8)
Please submit any code proposals using the process defined at https://github.com/openwallet-foundation/project-proposals. We will review proposals in the order submitted at a TAC meeting. If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up
Architecture SIG meets weekly on Mondays at 11am US/Pacific (next call February 26)
OID4VC Due Diligence task force meets bi-weekly on Tuesdays at 5pm CET (next call February 27)
Safe Wallet SIG meets weekly on Tuesdays at 7am US/Pacific (next call February 27)
Credential Format Comparison SIG meets bi-weekly on Wednesdays at 4pm CET on alternate weeks to the TAC (next call February 28)
Digital Wallets and Agents Overviews SIG meets biweekly on Thursdays at 5:00pm CET on the same weeks as the TAC (next meeting February 22)
Please submit any code proposals using the process defined at https://github.com/openwallet-foundation/project-proposals. We will review proposals in the order submitted at a TAC meeting. If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up
Review action items from last meeting
Sean to work with Mirko on a blog post on the Credential Format Comparison SIG \u2013 in progress
Digital Wallets and Agents Overviews SIG Update
Information included in the slides on the work that is being done.
Bifold Project Proposal
RESOLVED: That the Bifold project proposal is hereby confirmed, approved, and adopted as a growth project.
Wenjing volunteered to be second sponsor for the project
Our current project lifecycle does not clearly outline the steps necessary for projects to progress in the lifecycle.
Suggested changes to the lifecycle to create a PR to update the original project proposal to include the new stage and other information relevant to meet the proposed stage\u2019s criteria.
Upside: This process is similar to the original project proposal process.
Possible Downside: This will overwrite the original proposal but might not be a concern given the history in GitHub on the file.
If we do a PR to the original proposal, we will need to make sure that we can have links to the previous versions that were approved.
We can possibly do this via the project pages by adding a new section
Action: Tracy to create a PR to provide details on what this will look like.
Architecture SIG meets weekly on Mondays at 11am US/Pacific (next call March 11)
OID4VC Due Diligence task force meets bi-weekly on Tuesdays at 5pm CET (next call March 12)
Safe Wallet SIG meets weekly on Tuesdays at 7am US/Pacific (next call March 12)
Credential Format Comparison SIG meets bi-weekly on Wednesdays at 4pm CET on alternate weeks to the TAC (next call March 13)
Digital Wallets and Agents Overviews SIG meets biweekly on Thursdays at 5:00pm CET on the same weeks as the TAC (next meeting March 7)
Please submit any code proposals using the process defined at https://github.com/openwallet-foundation/project-proposals. We will review proposals in the order submitted at a TAC meeting. If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up
Reminder: Elections are coming up starting March 20, 2024; we will be accepting TAC \u201cat large\u201d nominations
Join the OpenWallet Foundation for our 1 year anniversary webinar on March 14, 9am PDT / 1700 CET / 9:30pm IST https://zoom.us/webinar/register/WN_MiUSaLFgQFOhVdTBMtlLuA#/registration
Review action items from last meeting
Create a PR against the project lifecycle to include information on transitioning through the lifecycle stages \u2013 complete
Work with Bifold to onboard project into OWF \u2013 completed
Safe Wallet SIG Update
Information included in the slides on the updates.
OWF Wallet Stacks
Brian presented the idea of Wallet Stacks as outlined in the slides
Discussion ensued
A discussion item in the TAC GitHub will be created to continue discussions and feedback on the idea
Project Promotion Process
RESOLVED: That the project promotion process is hereby confirmed, approved, and adopted.
Moved to the next meeting
Request that TAC members review the PR and provide any feedback
Architecture SIG meets weekly on Mondays at 11am US/Pacific (next call March 25)
OID4VC Due Diligence task force meets bi-weekly on Tuesdays at 5pm CET (next call March 26)
Safe Wallet SIG meets weekly on Tuesdays at 7am US/Pacific (next call March 26)
Credential Format Comparison SIG meets bi-weekly on Wednesdays at 4pm CET on alternate weeks to the TAC (next call March 27)
Digital Wallets and Agents Overviews SIG meets biweekly on Thursdays at 5:00pm CET on the same weeks as the TAC (next meeting March 21)
Please submit any code proposals using the process defined at https://github.com/openwallet-foundation/project-proposals. We will review proposals in the order submitted at a TAC meeting. If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up
Review action items from last meeting
Create discussion item to continue discussion on Wallet Stacks - Tracy -- completed
Project Promotion Process
RESOLVED: That the project promotion process is hereby confirmed, approved, and adopted.
Motion - David Z; Seconded - Jeremie M
Unanimously approved
TAC \u201cAt Large\u201d Nomination Process
Submit nominations via a GitHub issue at 2024 \"At Large\" Nomination
Title of issue: [NOMINATION]: 2024 \u201cat large\u201d Name
Include a short bio, outline your qualifications, and provide a statement explaining why you would be a good choice for the seat
TAC \"At Large\" Voting Schedule
2024-03-20 Nomination Period Begins
2024-03-27 Noon PT Nomination Period Ends
2024-03-27 Helios Voting Ballot Distributed to Existing TAC Members
2024-04-02 Noon PT Voting Ends
2024-04-02 Results Announced on the TAC mailing list
2024-04-03 New \u201cat large\u201d representatives begin their term
Open discussion and next steps
Next TAC Meeting April 3 2024
Architecture SIG Q2 Update
Question asked about the OWF Developer Day on April 15 - should have more details early next week
Question asked about making it easier to find the sample project charter on the TAC website
Question asked about how to get sponsors for the SD-JWT JavaScript project to move to Growth - reach out to the TAC members (individually, on the #tac Discord channel, or on the TAC mailing list)
Question asked about how to find out what was going on in the community and how to get involved:
Walked therough the TAC website
Walked through the OpenWallet Foundation Participate page
Architecture SIG meets weekly on Mondays at 11am US/Pacific (next call April 8)
OID4VC Due Diligence task force meets bi-weekly on Tuesdays at 5pm CET (next call April 9)
Safe Wallet SIG meets weekly on Tuesdays at 7am US/Pacific (next call April 9)
Credential Format Comparison SIG meets bi-weekly on Wednesdays at 4pm CET on alternate weeks to the TAC (next call April 10)
Digital Wallets and Agents Overviews SIG meets biweekly on Thursdays at 5:00pm CET on the same weeks as the TAC (next meeting April 4)
Please submit any code proposals using the process defined at https://github.com/openwallet-foundation/project-proposals. We will review proposals in the order submitted at a TAC meeting. If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up
Jorge Flores (Co-Founder & CTO of Entidad) and Jesus Torres (Co-Founder & CEO of Entidad): How an Aries digital trust ecosystem helped distribute $60M USD (& counting) to essential workers - Presenting at the Hyperledger Identity Special Interest Group on Thursday, April 4 @ 3PM UTC, 8AM PDT, 9AM MDT, 11AM EDT. Join on Zoom: https://zoom.us/j/93003523877?pwd=Q3VvMnJ1N0lSUEZSc283SmFGRk9SQT09
IIW Planning discussion taking place on Discord in the #iiw-planning channel
EIC Planning discussions taking place on Discord in the #eic-planning channel
Review action items from last meeting
Determine way to get the sample project charter more visible on the website -- completed
Welcome New \u201cAt Large\u201d Representatives
Thank you to all the nominees.
Welcome back, Stavros!
Welcome, Ace!
Thank you for your service, Jeremie!
Architecture SIG Q2 Update
Reviewed these slides
TAC Chair/Vice Chair Nomination Process
Only TAC voting members are eligible to run for the TAC chair and vice chair seats
Electing a vice chair will be held in conjunction with the chair election; the person with the second highest number of votes will serve as the vice chair
Submit nominations via a GitHub issue at 2024 Chair/Vice Chair Nomination
Title of issue: [NOMINATION]: 2024 Chair/Vice Chair Name
Include a short bio, outline your qualifications, and provide a statement explaining why you would be a good choice for the seat
See Elections for more information
TAC Chair/Vice Chair Voting Schedule
2024-04-03 Nomination Period Begins
2024-04-10 Noon PT Nomination Period Ends
2024-04-10 Helios Voting Ballot Distributed to Existing TAC Members
2024-04-16 Noon PT Voting Ends
2024-04-16 Results Announced on the TAC mailing list
2024-04-17 New Chair and Vice Chair begin their term
Wiki Update
https://wiki.openwallet.foundation
Discussion about content plan. Where should information live? Who is responsible for changes?
TAC website makes sense for things that the TAC is responsible for
The maintainers should be responsible for project information
The LF Staff is responsible for the openwallet.foundation website content
Architecture SIG meets weekly on Mondays at 11am US/Pacific (next call April 22)
OID4VC Due Diligence task force meets bi-weekly on Tuesdays at 5pm CET (next call April 23)
Safe Wallet SIG meets weekly on Tuesdays at 7am US/Pacific (next call April 23)
Credential Format Comparison SIG meets bi-weekly on Wednesdays at 4pm CET on alternate weeks to the TAC (next call April 24)
Digital Wallets and Agents Overviews SIG meets biweekly on Thursdays at 5:00pm CET on the same weeks as the TAC (next meeting April 18)
Please submit any code proposals using the process defined at https://github.com/openwallet-foundation/project-proposals. We will review proposals in the order submitted at a TAC meeting. If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up
EIC Planning discussions taking place on Discord in the #eic-planning channel
The Hyperledger Identity SIG (ID SIG) recently hosted Jorge and Jesus from Entidad for \"How The Aries Digital Trust Ecosystem Helped Distribute $60M USD (and counting) to Essential Workers. You can check out the recording on YouTube.
Michel Sahli is our GAC representative
Review action items from last meeting
Create a content plan for where stuff should live and who should control the content -- in progress
Chair/Vice Chair Results
Thank you to all nominees
Stavros, vice chair
Tracy, chair
Project Proposal: React Native Kit for EUDI Wallet Reference Implementation
RESOLVED: That the React Native Kit for EUDI Wallet Reference Implementation lab proposal is hereby confirmed, approved, and adopted.
Stavros motion; Ace seconded; Approved unanimously by the present TAC members
OWF Naming Policy Update
Reviewed Project Naming Policy
Request that the community provide suggested edits and comments
After incoming feedback, Sean will work with the LF Staff prior to bringing back to the TAC for approval
Content Plan
Quickly reviewed Content Plan
Request that the community provide suggested edits and comments
Determine where source of truth is for certain items, like the project list
Architecture SIG meets weekly on Mondays at 11am US/Pacific (next call May 6)
OID4VC Due Diligence task force meets bi-weekly on Tuesdays at 5pm CET (next call May 7)
Safe Wallet SIG meets weekly on Tuesdays at 7am US/Pacific (next call May 7)
Credential Format Comparison SIG meets bi-weekly on Wednesdays at 4pm CET on alternate weeks to the TAC (next call May 8)
Digital Wallets and Agents Overviews SIG meets biweekly on Thursdays at 5:00pm CET on the same weeks as the TAC (next meeting May 2)
Please submit any code proposals using the process defined at https://github.com/openwallet-foundation/project-proposals. We will review proposals in the order submitted at a TAC meeting. If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up
EIC Planning discussions taking place on Discord in the #eic-planning channel
Review action items from last meeting
Set up new lab eudi-wallet-kit-react-native - complete
Discord channel
GitHub repo
Content Plan
RESOLVED: That the Content Plan is hereby confirmed, approved, and adopted.
Wenjing motion; Rolson seconded
Unanimously approved by the present TAC voting members
Reference Architecture Contribution
Pull Request (Rendered version)
Proposed next steps:
Input from community - please provide comments on the PR
Add a heatmap that maps our current projects to the technology capabilities
David Z is concerned that the whitepaper may conflict with existing guidance
Request that a list of existing guidance be provided in the PR so that we may validate that the reference architecture whitepaper does not conflict with existing guidance
Architecture SIG meets weekly on Mondays at 11am US/Pacific (next call June 3)
Safe Wallet SIG meets weekly on Tuesdays at 7am US/Pacific (next call June 4)
Credential Format Comparison SIG meets bi-weekly on Wednesdays at 4pm CET on alternate weeks to the TAC (next call June 5)
Digital Wallets and Agents Overviews SIG meets biweekly on Thursdays at 5:00pm CET on the same weeks as the TAC (next meeting May 30)
Please submit any code proposals using the process defined at https://github.com/openwallet-foundation/project-proposals. We will review proposals in the order submitted at a TAC meeting. If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up
EIC Planning discussions taking place on Discord in the #eic-planning channel
Welcome new TAC member
Rolson Quadras will represent Gen Digital moving forward
Thank you Mike Varley for your service
Review action items from last meeting
Update Content Plan PR to include links - completed
Project Proposal: OpenId4BLE Library
Recommended that project come in at Labs stage
Recommended that project move to GitHub issues (to be completed in 3-6 months)
Recommended that project use Discord for communication instead of Slack
Discussed governance and diversity of maintainers
RESOLVED: That the OpenId4BLE Library lab proposal is hereby confirmed, approved, and adopted.
Stavros motioned; David seconded
Unanimously approved by the present TAC voting members.
Project Proposal: Trust Spanning Protocol
Discussed the need for language bindings that can be used by OWF projects. Recommendation is to implement the language bindings in conjunction with the projects that will use it to ensure correctness.
Research needs to be done on the license of https://github.com/dalek-cryptography/curve25519-dalek and whether an alternate implementation is needed
RESOLVED: That the Trust Spanning Protocol lab proposal is hereby confirmed, approved, and adopted.
Stavros motioned; Rolson seconded
Unanimously approved by the present TAC voting members.
Project Annual Reviews
RESOLVED: That the Project Annual Reviews pull request is hereby confirmed, approved, and adopted.
Adds template
Adds schedule
Vote moved to PR review
OID4VC Due Diligence Task Force Update
Torsten provided an update on the OID4VC Due Diligence task force and recommended closing the task force as it has accomplished its goals.
Please see the OpenWallet Foundation calendar for a list of upcoming meetings
Please submit any code proposals using the process defined at https://github.com/openwallet-foundation/project-proposals. We will review proposals in the order submitted at a TAC meeting. If you know of any potential projects that might be of interest to the OpenWallet Foundation, please let a staff member know so that they can follow up
EIC Planning discussions taking place on Discord in the #eic-planning channel
If you are interested in participating in the architecture SIG calls, we have a when2meet survey out there to find a new meeting time
EUDI Architecture Reference Framework v1.4 published
OpenWallet Foundation is hosting two workshops -- one for OpenID Connect for VCI and one for OpenID Connect for VP -- on June 10th and June 12th. Please be on the lookout for registration links coming soon
Review action items from last meeting
Onboard OpenID4BLE Library lab
Created Discord channel (#tuvali) - completed
Need to transfer repo (Issue #151) - in progress
Working on project page (PR #149) - in progress
Onboard Trust Spanning Protocol lab
Created Discord channel (#tsp) - completed
Need to transfer repo (Issue #150) - in progress
Working on project page (PR #149) - in progress
Project Proposal: credhub
RESOLVED: That the credhub lab proposal is hereby confirmed, approved, and adopted.
Stavros motioned; Wenjing seconded
Unanimously approved
Project Annual Reviews
RESOLVED: That the Project Annual Reviews pull request is hereby confirmed, approved, and adopted.
Projects in the OpenWallet Foundation follow the project lifecycle. This page lists the active projects within the OpenWallet Foundation and their current lifecycle stage.
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.
Key Features and Benefits:
Unified Digital Identity Management: Emphasizing security and user-friendliness, 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.
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.
Community-Driven Development: 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.
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.
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.
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: - As a user I can use multiple clients where my data is synced, we do not have to care about backups or data recovery. - As a developer I can implement the business logic into the cloud and only need the rendering on the client side.
Yes, when I am offline, I do not have access to my data anymore. But beside that the user experience is great!
The credhub project is a typescript based monorepo, using nx to manage multiple components. Compared to other approaches, it also comes with an issuer and verifier service to issue and verify credentials.
There are two clients that can be used to interact with a cloud wallet - a PWA based on Angular - a Chrome Browser Extension based on Angular
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.
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 server for that.
"},{"location":"projects/credhub/#issuer-and-verifier","title":"Issuer and Verifier","text":"
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.
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.
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.
Credential Profile:
Credential Format: SD-JWT-VC
Key Management (issuer): VC-ISSUER Meta data, DID, X509
Credo 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.
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.
The future direction for Credo 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.
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) was chosen as a steward due to its commitment to promoting interoperability without directly developing or maintaining standard protocols.
The project is a cross-platform React Native wrapper for EUDI Wallet reference implementation.
It allows building cross-platform Mobile Wallet applications compliant with Electronic Identification, Authentication and Trust Services (eIDAS) Regulation and EUDI Architecture and Reference Framework (ARF) and based on reference implementations from EUDI (Android and iOS correspondingly).
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 engine that makes it easier for farmworker communities to access an ecosystem of life-altering social and human services.
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 \u2018Essential\u2019 during the recent pandemic. While services and programs exist to help, it\u2019s 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\u2019re eligible for them.
Over the last three years, Entidad and the UFW Foundation have been exploring digital trust technologies to solve this problem. We\u2019ve 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.
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.\u202fMendix, 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.
We\u2019ve built two products, using this technology. For organizations we\u2019ve built Preparese PlatformTM, it allows them to quickly develop and launch digital trust enabled services and programs. For farmworkers, we\u2019ve developed Preparese MobileTM which combines a verifiable digital profile with a suite of tools that simplify interactions with organizations on the platform.
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 in one-time relief payments to over 125,000 workers, under the United States Department of Agriculture\u2019s Farm and Food Workers Relief Program (FFWR).
The second product, Preparese MobileTM, is designed around the unique needs of farmworkers. We\u2019ve developed a react native mobile app that lets farmworkers store, manage, and exchange their verified information. Engagement with organizations is made easier with DIDComm-based communication capabilities such as text and video chat.
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, Hyperledger Aries JS Working Group, and various other communities, including DID Communication Working Group and OpenWallet Foundation of late, to ensure we adhere to best practices and standards.
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.
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.
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.
The first digital service launched supported the UFW Foundation\u2019s 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.\u202f
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.
There are design-time and runtime aspects of app development but one of the great things about this tooling is that there is clean separation between the two.
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.
Mendix Studio Pro v9.24.4 (integrated developer environment)
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 developer workstation.
The initial version of the digital wallet SDK is being built on top of Aries Framework Javascript, an open-source framework maintained by the Hyperledger Aries developer community helping to foster participation with the Aries digital trust ecosystem. Over time, the digital wallet SDK will be extended to support other digital trust open standards such as OpenID for Verifiable Credentials (OID4VC).
Libraries and reference applications for working with real-world identity.
The initial focus for this work was mdoc/mDL according to ISO/IEC 18013-5:2021 and related standards (mainly ISO 23220 series and ISO 18013-7) on Android. Current focus includes other credential formats and operating environments.
The project includes two libraries written in Java and Kotlin. The first is identity which provides the core building blocks and which can also be used on server-side environments. The other is identity-android which provides Android-specific extensions to the former. It is designed to run on Android (API 24 or later) and will take advantage of Android-specific features including hardware-backed Keystore, NFC, Bluetooth Low Energy, and so on.
The libraries are intended to be used by Wallet Applications (mobile applications on the credential holder's device), Reader Applications (applications operated on device controlled by the verifier), and Issuance Systems (applications operated by the credential issuer or their agent). They provide the following building blocks
A light-weight Secure Area abstraction for hardware-backed keystore
Applications can create hardware-backed Elliptic Curve Cryptography keys which can be used for creating Signatures or performing Key Agreement. Each key will have an attestation which can be used to prove to Relying Parties (such as a credential issuer) that the private part of the key only exists in a Secure Area.
The identity-android library includes an implementation based on Android Keystore with support for requiring user authentication (biometric or lock-screen knowledge factor, e.g. system PIN) for unlocking the key and also can use StrongBox if available on the device. This is appropriate to use in Android applications implementing ISO/IEC 18013-5:2021 for storing DeviceKey.
The identity library includes an implementation backed by BouncyCastle with support for passphrase-protected keys. This isn't suitable for use in Mobile Applications as its not backed by Secure Hardware.
Applications can supply their own Secure Area implementations for e.g. externally attached dongles, cloud based HSMs, or whatever the issuer deems appropriate to protect key material associated with their credential.
A Credential Store for storage of one or more Credentials
Each Credential has a Credential Key which can be used by the issuer to bind a credential to a specific device which is useful when issuing updates or refreshing a credential.
Additionally, each Credential has one or more Authentication Keys which can be endorsed by the issuer and used at presentation time.
Finally, namespaced data and arbitrary key/value pairs can be stored in a Credential which can be used for credential data and claims. This data is stored encrypted at rest.
Data structures and code for provisioning of mdoc/mDLs
This code can can be used both on the device and issuer side. No networking protocol is defined, the application has to define its own.
Parsers and generators for all data structures used in ISO/IEC 18013-5:2021 presentations, including DeviceResponse, DeviceRequest, MobileSecurityObject and many other CBOR data structures.
An implementation of the ISO/IEC 18013-5:2021 presentation flows including QR engagement, NFC engagement (both static and negotiated), device retrieval (BLE, Wifi Aware, and NFC)
"},{"location":"projects/identity-credential/#wallet-and-reader-android-applications","title":"Wallet and Reader Android applications","text":"
This repository also contains two Android applications using this library in the appholder and appverifier modules. The Wallet application is a simple self-contained application which allows creating a number of mdoc credentials using four different mdoc Document Types:
org.iso.18013.5.1.mDL: Mobile Driving License
org.micov.1: mdoc for eHealth (link)
nl.rdw.mekb.1: mdoc for Vehicle Registration (link)
eu.europa.ec.eudiw.pid.1: mdoc for Personal Identification
and their associated mdoc name spaces. The first one is defined in ISO/IEC 18013-5:2021 and the other three have been used at mdoc/mDL test events organized by participants of the ISO/IEC JTC1 SC17 WG10 working group.
The wwwverifier module contains the source code for a website acting as an mdoc reader according to the latest ISO 18013-7 working draft (as of Sep 2023) and it's implementing the so-called REST API. There is currently a test instance of this application available at https://mdoc-reader-external.uc.r.appspot.com/. The Wallet Android application also has support for the REST API and registers on Android for the mdoc:// URI scheme. This can be tested end-to-end by going to the reader website (URL above) and clicking on one of the \"Request\" buttons, and then hitting the mdoc:// link presented on the site. This will cause the browser to invoke the Wallet app which will then connect to the reader and send the credential after user consent.
Proposal to enter Labs -- Approved by TAC on 2023-10-18
"},{"location":"projects/multiformat-vc-ios/","title":"Multiformat VC for iOS","text":""},{"location":"projects/multiformat-vc-ios/#project-description","title":"Project Description","text":"
Pure Swift package for creating Verifiable Credentials (VCs) in multiple formats
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/
VC JWT: Verifiable Credentials as JWT - using the format defined at JWT VC Presentation Profile https://identity.foundation/jwt-vc-presentation-profile/
Support for multiple data types for disclosed values including
String
Int
Boolean
Array of Strings - [String]
Dictionary of String keys and String values - [String:String]
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.
This is the reference implementation of the IETF SD-JWT specification maintained by the editors of the specification together with other contributors. It is written in Python.
This project is an early impementation of the draft Trust Spanning Protocol (TSP).
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.\"
A shorter introduction of TSP can be found in this blog post.
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.
In addition, we may add and welcome trust task or application specific extensions.
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 \u201cdraft community report\u201d status.
The VC API\u2019s 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/).
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.
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.
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.
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.
Copy this template to the subdirectory for the current year and name the file YYYY-project-name-annual.md (e.g., 2024-amazingproj-annual.md). Update the title above to replace YYYY with the year of the annual review and PROJECT NAME with the name of the project. Update the index.md file in the current year to include a link to the markdown file. These blocks are instructions. Please remove when section has been completed.
Include information about your project's contributions and activity. You can find information within GitHub by looking at the Insights tab. We will be looking for signs of consistent or increasing contribution activity. Please feel free to add commentary to add color to this information.
How many maintainers do you have, and which organisations are they from? How has the maintainers and diversity of your maintainers changed in the past year? Has the number of active maintainers increased/decreased? Has the diversity of maintainers increased/decreased? Please include a link to your existing MAINTAINERS file and the MAINTAINERS file from last year (if appropriate). This is a good opportunity to ensure that your MAINTAINERS file is up to date and to retire any maintainers.
What do you know about adoption, and how has this changed since your last review or since being accepted into OpenWallet Foundation? If you can list companies that are adopters of your project, please do so. Feel free to link to an existing ADOPTERS file if appropriate.
"},{"location":"projects/reviews/0000-template-annual/#goals","title":"Goals","text":""},{"location":"projects/reviews/0000-template-annual/#performance-against-prior-goals","title":"Performance Against Prior Goals","text":"
Info
Include information about the goals that you previously set for the project in the last review or since the project proposal has been approved. How has the project performed against these goals? If your goals changed from your previous annual report, let us know what changed and why. If you have not achieved the goals that you set out, that is okay. We want to know what you have accomplished and what challenges the project is having in meeting the goals.
What are the goals for the next year of the project? The goals should list what you want to achieve, not just what you know you can achieve. Feel free to include stretch goals and things that you are looking to explore in the next year. For example, are you working on major new features? Or are you concentrating on adoption, community growth, or documentation?
Projects must provide an annual review to the TAC to ensure that the project is still active and in the correct lifecycle stage. The following calendar provides the timing for when these reviews are required to be presented to the TAC:
Project Stage Date Accepted 2024 Review SD-JWT Python Labs May 27, 2023 Jun 12, 2024 SD-JWT Kotlin Labs May 27, 2023 Jun 12, 2024 Farmworker Wallet OS Labs Aug 9, 2023 Aug 21, 2024 VC-API Labs Sep 28, 2023 Oct 2, 2024 Wallet Framework .NET Labs Oct 4, 2023 Oct 16, 2024 Android Identity Library Labs Oct 18, 2023 Oct 30, 2024 SD-JWT JavaScript Labs Nov 1, 2023 Nov 13, 2024 SD-JWT Rust Labs Nov 15, 2023 Nov 27, 2024 Credo Growth Nov 29, 2023 Dec 11, 2024 SD-JWT .NET Labs Nov 29, 2023 Dec 11, 2024"},{"location":"projects/reviews/2025/","title":"2025 Project Annual Reviews","text":"
Projects must provide an annual review to the TAC to ensure that the project is still active and in the correct lifecycle stage. The following calendar provides the timing for when these reviews are required to be presented to the TAC:
Project Stage Date Accepted 2025 Review Multiformat VC for iOS Labs Jan 24, 2024 Feb 5, 2025 Bifold Growth Feb 21, 2024 Mar 5, 2025 EUDI Wallet Kit React Native Labs Apr 17, 2024 Apr 30, 2025 Trust Spanning Protocol Labs May 15, 2024 May 14, 2025 Tuvali Labs May 15, 2024 May 14, 2025 Credhub Labs May 29, 2024 May 28, 2025 SD-JWT Python Labs May 27, 2023 SD-JWT Kotlin Labs May 27, 2023 Farmworker Wallet OS Labs Aug 9, 2023 VC-API Labs Sep 28, 2023 Wallet Framework .NET Labs Oct 4, 2023 Android Identity Library Labs Oct 18, 2023 SD-JWT JavaScript Labs Nov 1, 2023 SD-JWT Rust Labs Nov 15, 2023 Credo Growth Nov 29, 2023 SD-JWT .NET Labs Nov 29, 2023"},{"location":"task-forces/","title":"Task Forces","text":"
A task force is a group that is focused on a task with limited scope and fixed time to complete. Unlike a special interest group, a task force will have a specific set of deliverables or work products that it will create and be limited in time to completion. A task force can be created by anyone in the OpenWallet Foundation community and must be proposed to and approved by the TAC.
Tip
If you would like to propose a Task Force, please see the task force proposal process.
"},{"location":"task-forces/OID4VC-due-diligence/","title":"OID4VC Due Diligence Task Force","text":"
Currently, the OID4VC components for implementing decentralized identities such as OID4VCI and OID4VP are gaining traction, especially in Europe. These specifications are required by the European digital identity Architectural Reference Framework but also getting significant attention outside of Europe.
This task force will investigate the specifications belonging to the OID4VC family thoroughly, check the existing implementations, and start the preliminary work for potentially creating/hosting a reference implementation or a framework that can be used by a wider community for application implementations.
This task force was accepted by the TAC on May 31, 2023. See OID4VC Due Diligence Task Force Proposal for more details.
This task force is an open group. Anyone in the OpenWallet Foundation community can join and participate. There is no formal sign up process. Just show up and participate.
If you are interested in participating, please join the OpenWallet Foundation Discord and participate in the discussion in the #oid4vc-due-diligence-tf channel.
"}]}
\ No newline at end of file
diff --git a/sitemap.xml b/sitemap.xml
new file mode 100644
index 00000000..0f8724ef
--- /dev/null
+++ b/sitemap.xml
@@ -0,0 +1,3 @@
+
+
+
\ No newline at end of file
diff --git a/sitemap.xml.gz b/sitemap.xml.gz
new file mode 100644
index 00000000..f7300c4e
Binary files /dev/null and b/sitemap.xml.gz differ
diff --git a/task-forces/OID4VC-due-diligence/index.html b/task-forces/OID4VC-due-diligence/index.html
new file mode 100644
index 00000000..a0dd986c
--- /dev/null
+++ b/task-forces/OID4VC-due-diligence/index.html
@@ -0,0 +1,4204 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ OID4VC Due Diligence - Technical Advisory Council
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Currently, the OID4VC components for implementing decentralized identities such as OID4VCI and OID4VP are gaining traction, especially in Europe. These specifications are required by the European digital identity Architectural Reference Framework but also getting significant attention outside of Europe.
+
This task force will investigate the specifications belonging to the OID4VC family thoroughly, check the existing implementations, and start the preliminary work for potentially creating/hosting a reference implementation or a framework that can be used by a wider community for application implementations.
This task force is an open group. Anyone in the OpenWallet Foundation community can join and participate. There is no formal sign up process. Just show up and participate.
A task force is a group that is focused on a task with limited scope and fixed time to complete. Unlike a special interest group, a task force will have a specific set of deliverables or work products that it will create and be limited in time to completion. A task force can be created by anyone in the OpenWallet Foundation community and must be proposed to and approved by the TAC.