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.
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.
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
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/project-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 a link to your project’s LFX Insights page. 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. 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
+
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 (Apache 2.0 by default)
+
source control (GitHub by default)
+
issue tracker (GitHub by default)
+
external dependencies (including licenses)
+
release methodology and mechanics
+
names of initial maintainers, if different from those submitting proposal
+
briefly describe the project's leadership team and decision-making process
Projects are required to present their proposal at a TAC meeting.
+
+
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.
+
+
+
+
Projects are accepted via a two-thirds supermajority vote 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.
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:
+
+
Submit a project proposal with a Preferred Maturity Level of Labs.
+
Document an intellectual property policy that leverages the Apache 2.0 license or an open license that has been approved by the OpenWallet Foundation's Governing Board.
+
In the case of existing projects, 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.
+
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’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.
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.
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.
+
+
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
48 working hours to respond to reporter acknowledging the report.
+
1 week to triage, report, and coordinate with the affected project maintainers to plan the fix of the bug.
+
90 days to fix and release a fix or disclose the security bug.
+
Any "critical" errors shall be assigned a CVE number and disclosed through the formal CVE system.
+
+
+
Example Acknowledgment Response
+
Dear hacker,
+
Thank you for your recent report of a security bug. I am emailing to let you know that we are in the process of investigating your report and will reply to you again when we have determined the validity of your report. We may have further questions that come up as part of our investigation. We appreciate your contribution to project name.
+
Thank you,
+
your name
+
+
+
Example Update
+
Dear hacker,
+
I'm emailing to let you know that we have confirmed your bug report as a valid security concern and have filed a bug in our system. We will keep you informed of the status of the bug.
Each project must have the following information included in the SECURITY.md file at the root of the project:
+
# How to Report a Security Bug
+To report a security issue, please email
+[security@lists.openwallet.foundation](mailto:security@lists.openwallet.foundation)
+with a description of the issue, the steps you took to create the issue,
+affected versions, and if known, mitigations for the issue. Our vulnerability
+management team will acknowledge receiving your email within 2 working days.
+This project follows a 90 day disclosure timeline.
+
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 arrange a time with the TAC chair to present the activities of the SIG at a TAC meeting. This can be accomplished by sending an email to the TAC mailing list at tac@lists.openwallet.foundation. This will ensure that the SIG is still active and that there is still value in hosting the special interest group.
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](./special-interest-group-process.md), 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.
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.
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.
Projects in the OpenWallet Foundation follow the project lifecycle. This page lists the active projects within the OpenWallet Foundation and their current lifecycle stage.
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.
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..3079fa71
--- /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.
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 is based on the Hyperledger Foundation's Common Respository Structure guideline.
"},{"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
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/project-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 a link to your project\u2019s LFX Insights page. 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)?
"},{"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. 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
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 (Apache 2.0 by default)
source control (GitHub by default)
issue tracker (GitHub by default)
external dependencies (including licenses)
release methodology and mechanics
names of initial maintainers, if different from those submitting proposal
briefly describe the project's leadership team and decision-making process
link to any documented governance practices
preferred maturity level (see stages below)
list of project's official communication channels (slack, irc, mailing lists)
Projects are required to present their proposal at a TAC meeting.
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.
Projects are accepted via a two-thirds supermajority vote 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.
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:
Submit a project proposal with a Preferred Maturity Level of Labs.
Document an intellectual property policy that leverages the Apache 2.0 license or an open license that has been approved by the OpenWallet Foundation's Governing Board.
In the case of existing projects, 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.
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.
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.
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.
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
48 working hours to respond to reporter acknowledging the report.
1 week to triage, report, and coordinate with the affected project maintainers to plan the fix of the bug.
90 days to fix and release a fix or disclose the security bug.
Any \"critical\" errors shall be assigned a CVE number and disclosed through the formal CVE system.
Example Acknowledgment Response
Dear hacker,
Thank you for your recent report of a security bug. I am emailing to let you know that we are in the process of investigating your report and will reply to you again when we have determined the validity of your report. We may have further questions that come up as part of our investigation. We appreciate your contribution to project name.
Thank you,
your name
Example Update
Dear hacker,
I'm emailing to let you know that we have confirmed your bug report as a valid security concern and have filed a bug in our system. We will keep you informed of the status of the bug.
Each project must have the following information included in the SECURITY.md file at the root of the project:
# How to Report a Security Bug\nTo report a security issue, please email\n[security@lists.openwallet.foundation](mailto:security@lists.openwallet.foundation)\nwith a description of the issue, the steps you took to create the issue,\naffected versions, and if known, mitigations for the issue. Our vulnerability\nmanagement team will acknowledge receiving your email within 2 working days.\nThis project follows a 90 day disclosure timeline.\n
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 arrange a time with the TAC chair to present the activities of the SIG at a TAC meeting. This can be accomplished by sending an email to the TAC mailing list at tac@lists.openwallet.foundation. This will ensure that the SIG is still active and that there is still value in hosting the special interest group.
"},{"location":"governance/tac/","title":"Open Wallet Foundation TAC composition","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](./special-interest-group-process.md), 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.us/j/92638265993?pwd=REErdEF1QjVWYWFNU3BrRDgwckp2Zz09
Location: https://zoom.us/j/92638265993
Meeting ID: 926 3826 5993
Passcode: 565874
Find your local number: https://zoom.us/u/ad1obgPfpf
"},{"location":"meetings/YYYY-mm-dd/","title":"YYYY mm dd","text":"
Reminder
These meetings are covered by the Antitrust Policy and the Code of Conduct.
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.
Projects in the OpenWallet Foundation follow the project lifecycle. This page lists the active projects within the OpenWallet Foundation and their current lifecycle stage.
"},{"location":"projects/#active-projects","title":"Active Projects","text":"Approval Date Project Name Lifecycle Stage 2023-May-17 SD-JWT Kotlin Lab 2023-May-17 SD-JWT Python Lab 2023-Aug-09 Farmworker Wallet OS Lab 2023-Oct-05 Wallet Framework .NET Lab"},{"location":"projects/fwos/","title":"Farmworker Wallet OS","text":""},{"location":"projects/fwos/#project-description","title":"Project Description","text":"
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).
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.
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.
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..5f32c44b
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..e4e91e8b
--- /dev/null
+++ b/task-forces/OID4VC-due-diligence/index.html
@@ -0,0 +1,1773 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ 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.