This SIG is focused on conversations related to the architecture of digital wallet engines.
+This SIG was accepted by the TAC on April 5, 2023.
+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.
+ + + + + + + +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 was accepted by the TAC on May 31, 2023. See Credential Format Comparison 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 #credential-format-comparison-sig channel.
+ + + + + + + +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.
+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
+The LF Europe Antitrust Policy listed at http://lfeurope.be/policies will apply for all Collaborators in the Project.
+ + + + + + + +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.
+ + + + + + + +Exhibit B
+The OpenWallet Foundation Charter
+Linux Foundation Europe
+Effective January 15, 2023
+ +Mission and Scope of the OpenWallet Foundation.
+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:
+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.
+Governing Board
+The Governing Board voting members will consist of:
+The Governing Board will also include nonvoting members consisting of the GAC Representative (defined in Section 4) and Associate Representative.
+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.
+Conduct of Meetings
+Officers
+The Governing Board will be responsible for overall oversight of the OWF, including:
+Government Advisory Council
+The role of the TAC is to facilitate communication and collaboration among the Technical Projects. The TAC will be responsible for:
+The voting members of the TAC consist of:
+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.
+Voting
+Subsidiaries and Related Companies
+Definitions:
+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.
+Good Standing
+Trademarks
+Antitrust Guidelines
+Budget
+General & Administrative Expenses
+General Rules and Operations.
+The OWF activities must:
+Amendments
+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.
+Info
+All code within the OpenWallet Foundation should be licensed under Apache 2.0. Exceptions can be made by the OpenWallet Foundation Governing Board.
+SECURITY.mdRepositories 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: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.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 2SPDX-License-Identifier: Apache-2.0 as part of the header. package.json fileGemfile filepom.xml, an Apache Ant build.xml, or a Gralde build.gradlesetup.py and requirements.txt filesgo.mod and optionally go.sum cargo.toml fileMakefile or executable build.sh scriptTesting 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.
+Repositories MUST NOT have these files
+.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.
+ + + + + + + +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’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.
+Implied from the OWF Charter
+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.
+Voting occurs by a time-limited Helios Voting ballot.
+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.
+Nominations
+Nominees should outline their qualifications and provide a statement explaining why they would be a good choice for the seat.
+Should the TAC Chair seat become vacant, the vacancy will be filled by the vice chair who will serve the remainder of the original term.
+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 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.
+ + + + + + + +The following are the governing documents used by the OpenWallet Foundation's Technical Advisory Council.
+Note
+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.
+This document is based on the Hyperledger Foundation's Inactivity policy
+ + + + + + + +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 following shows the suggested format for the information:
+Example
+Active Maintainers
+| Maintainer | +GitHub ID | +LFID | +Chat ID | +Company Affiliation | +Scope | +|
|---|---|---|---|---|---|---|
| + | + | + | + | + | + | + |
Emeritus Maintainers
+| Maintainer | +GitHub ID | +LFID | +Chat ID | +Company Affiliation | +Scope | +|
|---|---|---|---|---|---|---|
| + | + | + | + | + | + | + |
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:
MAINTAINERS file to make this proposalThe 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:
MAINTAINERS fileThis document is based on the Hyperledger Foundation's MAINTAINERS guideline.
+ + + + + + + +The TAC will undertake an annual review of all OpenWallet Foundation projects. This annual review will include an assessment as to whether:
+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.
+<year>-<project name>-annual.md (e.g., 2024-amazingproj-annual.md) with the contents described belowIf 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:
+Annual reviews are performed in order to check in with projects, ascertain their progress, and address any outstanding questions.
+The outcome of the annual review is either:
+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.
+Ideas were taken from CNCF's Sandbox Annual Review Process.
+ + + + + + + +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:
+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.
+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 Definition
+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
+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:
+Labs.Definition
+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
+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:
+Definition
+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
+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:
+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).ADOPTERS.md or logos on the project website).Definition
+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
+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.
+Each project will undergo an annual review process to determine whether projects are in the stage that accurately reflects their needs and goals.
+ + + + + + + +Note
+This policy is not about exiting project stages.
+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:
+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.
+ + + + + + + +The OpenWallet Foundation charter states that the TAC is responsible for:
+Quote
+TAC members are expected to:
+The TAC chair has the following additional responsibilities:
+The TAC vice chair has the following additional responsibilities:
+The OpenWallet Foundation's Vulnerability Management Team (VMT) is responsible for managing vulnerability reports for the OWF's projects.
+The VMT has the following responsibilities:
+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.
+Thank you,
+your name
+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.
+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.
+ + + + + + + +Welcome to the OpenWallet Foundation's (OWF) Technical Advisory Council (TAC) website. Here you will find:
+Learn more about the Technical Advisory Council's role, responsibilities, and voting members
+Review the OpenWallet Foundation TAC Governing Documents
+See meeting invite details and meeting notes from past meetings
+OpenWallet Foundation Projects
+OpenWallet Foundation Special Interest Groups (SIGs)
+OpenWallet Foundation Task Forces
+Reminder
+These meetings are covered by the Antitrust Policy and the Code of Conduct.
+Reminder
+These meetings are covered by the Antitrust Policy and the Code of Conduct.
+Reminder
+These meetings are covered by the Antitrust Policy and the Code of Conduct.
+Reminder
+These meetings are covered by the Antitrust Policy and the Code of Conduct.
+Reminder
+These meetings are covered by the Antitrust Policy and the Code of Conduct.
+Review action items from last meeting
+Welcome new TAC member
+Task Force Proposal
+Assessment Framework
+Next steps
+Reminder
+These meetings are covered by the Antitrust Policy and the Code of Conduct.
+Review action items from last meeting
+ +New lab proposals
+Special Interest Group process proposal
+OID4VCI and OID4VP Due Diligence Task Force
+Next steps
+Reminder
+These meetings are covered by the Antitrust Policy and the Code of Conduct.
+OID4VC Due Diligence Task Force
+Credential Format Comparison SIG
+Review action items from last meeting
+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
+Credential Format Comparison SIG
+Next steps
+Reminder
+These meetings are covered by the Antitrust Policy and the Code of Conduct.
+Credential Format Comparison SIG
+Announcements
+Review action items from last meeting
+OID4VC Due Diligence Task Force -- completed
+Credential Format Comparison SIG -- in progress
+TAC Alternates Policy
+Call for code from the community
+Open discussion and next steps
+Reminder
+These meetings are covered by the Antitrust Policy and the Code of Conduct.
+Announcements
+Review action items from last meeting
+Vice chair seat and responsibilities
+Wallets and personal data stores
+ +Call for code from the community
+Open discussion and next steps
+Reminder
+These meetings are covered by the Antitrust Policy and the Code of Conduct.
+Announcements
+Review action items from last meeting
+Vice Chair
+Farmworker Wallet OS project proposal
+Call for code from the community
+Open discussion and next steps
+Reminder
+These meetings are covered by the Antitrust Policy and the Code of Conduct.
+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.
+Projects in the OpenWallet Foundation follow the project lifecycle. This page lists the active projects within the OpenWallet Foundation and their current lifecycle stage.
+| Approval Date | +Project Name | +Lifecycle Stage | +
|---|---|---|
| 2023-May-17 | +SD-JWT Kotlin Library | +Lab | +
| 2023-May-17 | +SD-JWT Python Reference Implementation | +Lab | +
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
OpenWallet Foundation Projects
Special Interest Groups
OpenWallet Foundation Special Interest Groups (SIGs)
Task Forces
OpenWallet Foundation Task Forces
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 Library Lab 2023-May-17 SD-JWT Python Reference Implementation Lab"},{"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.
"},{"location":"SIGs/#active-sigs","title":"Active SIGs","text":"This SIG is focused on conversations related to the architecture of digital wallet engines.
This SIG was accepted by the TAC on April 5, 2023.
"},{"location":"SIGs/architecture/#participating","title":"Participating","text":"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.
"},{"location":"SIGs/architecture/#meetings","title":"Meetings","text":"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.
"},{"location":"SIGs/architecture/#discord","title":"Discord","text":"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 was accepted by the TAC on May 31, 2023. See Credential Format Comparison SIG Proposal for more details.
"},{"location":"SIGs/credential-format-comparison/#participating","title":"Participating","text":"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":"governance/","title":"Governing Documents","text":"The following are the governing documents used by the OpenWallet Foundation's Technical Advisory Council.
"},{"location":"governance/#code-of-conduct","title":"Code of Conduct","text":"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
The LF Europe Antitrust Policy listed at http://lfeurope.be/policies will apply for all Collaborators in the Project.
"},{"location":"governance/archiving-inactive-repositories/","title":"Archiving Inactive Repositories","text":"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 January 15, 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:
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.
Governing Board
The Governing Board voting members will consist of:
The Governing Board will also include nonvoting members consisting of the GAC Representative (defined in Section 4) and Associate Representative.
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.
Conduct of Meetings
Officers
The Governing Board will be responsible for overall oversight of the OWF, including:
Government Advisory Council
Technical Advisory Council
The role of the TAC is to facilitate communication and collaboration among the Technical Projects. The TAC will be responsible for:
The voting members of the TAC consist of:
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.
Voting
Subsidiaries and Related Companies
Definitions:
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.
Good Standing
Trademarks
Antitrust Guidelines
Budget
General & Administrative Expenses
General Rules and Operations.
The OWF activities must:
Amendments
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.
"},{"location":"governance/common-repository-structure/","title":"Common Repository Structure","text":"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.mdRepositories 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: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.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 2SPDX-License-Identifier: Apache-2.0 as part of the header. package.json fileGemfile filepom.xml, an Apache Ant build.xml, or a Gralde build.gradlesetup.py and requirements.txt filesgo.mod and optionally go.sum cargo.toml fileMakefile or executable build.sh scriptTesting 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.
Repositories MUST NOT have these files
.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.
"},{"location":"governance/elections/#electing-at-large-representatives","title":"Electing \"At Large\" Representatives","text":"Implied from the OWF Charter
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.
"},{"location":"governance/elections/#voting-process","title":"Voting Process","text":""},{"location":"governance/elections/#voting-tool","title":"Voting Tool","text":"Voting occurs by a time-limited Helios Voting ballot.
"},{"location":"governance/elections/#voting-schedule","title":"Voting Schedule","text":"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.
Nominations
Nominees should outline their qualifications and provide a statement explaining why they would be a good choice for the seat.
"},{"location":"governance/elections/#vacancies","title":"Vacancies","text":""},{"location":"governance/elections/#tac-chair-vacancy","title":"TAC Chair Vacancy","text":"Should the TAC Chair seat become vacant, the vacancy will be filled by the vice chair who will serve the remainder of the original term.
"},{"location":"governance/elections/#tac-vice-chair-vacancy","title":"TAC Vice Chair Vacancy","text":"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.
"},{"location":"governance/elections/#tac-at-large-representative-vacancy","title":"TAC \"At Large\" Representative Vacancy","text":"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.
"},{"location":"governance/elections/#tac-project-representative-vacancy","title":"TAC Project Representative Vacancy","text":"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.
"},{"location":"governance/maintainer-inactivity/","title":"Maintainer Inactivity Policy","text":"Note
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.
"},{"location":"governance/maintainer-inactivity/#credits","title":"Credits","text":"This document is based on the Hyperledger Foundation's Inactivity policy
"},{"location":"governance/maintainers-file-content/","title":"MAINTAINERS.md File Contents","text":"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 following shows the suggested format for the information:
Example
Active Maintainers
Maintainer GitHub ID LFID Email Chat ID Company Affiliation ScopeEmeritus 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).
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:
MAINTAINERS file to make this proposalThe 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:
MAINTAINERS fileThis document is based on the Hyperledger Foundation's MAINTAINERS guideline.
"},{"location":"governance/project-annual-review-process/","title":"Project Annual Review Process","text":""},{"location":"governance/project-annual-review-process/#overview","title":"Overview","text":"The TAC will undertake an annual review of all OpenWallet Foundation projects. This annual review will include an assessment as to whether:
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.
<year>-<project name>-annual.md (e.g., 2024-amazingproj-annual.md) with the contents described belowIf 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.
"},{"location":"governance/project-annual-review-process/#annual-review-contents","title":"Annual Review Contents","text":"Your annual review should answer the following questions:
Annual reviews are performed in order to check in with projects, ascertain their progress, and address any outstanding questions.
The outcome of the annual review is either:
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.
Ideas were taken from CNCF's Sandbox Annual Review Process.
"},{"location":"governance/project-lifecycle/","title":"Project Lifecycle","text":""},{"location":"governance/project-lifecycle/#overview","title":"Overview","text":"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.
"},{"location":"governance/project-lifecycle/#project-proposal-process","title":"Project Proposal Process","text":""},{"location":"governance/project-lifecycle/#introduction","title":"Introduction","text":"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.
"},{"location":"governance/project-lifecycle/#project-proposal-requirements","title":"Project Proposal Requirements","text":"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:
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.
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 Definition
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
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:
Labs.Definition
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
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:
Definition
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
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:
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).ADOPTERS.md or logos on the project website).Definition
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
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.
"},{"location":"governance/project-lifecycle/#annual-review-process","title":"Annual Review Process","text":"Each project will undergo an annual review process to determine whether projects are in the stage that accurately reflects their needs and goals.
"},{"location":"governance/release-taxonomy/","title":"Release Taxonomy","text":"Note
This policy is not about exiting project stages.
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:
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.
"},{"location":"governance/release-taxonomy/#alpha","title":"alpha","text":"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.
"},{"location":"governance/release-taxonomy/#beta","title":"beta","text":"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.
"},{"location":"governance/release-taxonomy/#rcn","title":"rcN","text":"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.
"},{"location":"governance/release-taxonomy/#credits","title":"Credits","text":"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
TAC members are expected to:
The TAC chair has the following additional responsibilities:
The TAC vice chair has the following additional responsibilities:
The OpenWallet Foundation's Vulnerability Management Team (VMT) is responsible for managing vulnerability reports for the OWF's projects.
"},{"location":"governance/security/#team-members","title":"Team Members","text":"The VMT has the following responsibilities:
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.
Thank you,
your name
"},{"location":"governance/security/#security-markdown","title":"Security Markdown","text":"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.\nA 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/task-force-process/","title":"Task Force","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.
"},{"location":"meetings/","title":"TAC Meetings","text":"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.
Reminder
These meetings are covered by the Antitrust Policy and the Code of Conduct.
"},{"location":"meetings/2023-03-08/#agenda","title":"Agenda","text":"Reminder
These meetings are covered by the Antitrust Policy and the Code of Conduct.
"},{"location":"meetings/2023-03-22/#agenda","title":"Agenda","text":"Reminder
These meetings are covered by the Antitrust Policy and the Code of Conduct.
"},{"location":"meetings/2023-04-05/#2023-04-05","title":"2023-04-05","text":""},{"location":"meetings/2023-04-05/#agenda","title":"Agenda","text":"Reminder
These meetings are covered by the Antitrust Policy and the Code of Conduct.
"},{"location":"meetings/2023-04-19/#2023-04-19","title":"2023-04-19","text":""},{"location":"meetings/2023-04-19/#agenda","title":"Agenda","text":"Reminder
These meetings are covered by the Antitrust Policy and the Code of Conduct.
"},{"location":"meetings/2023-05-03/#2023-05-03","title":"2023-05-03","text":""},{"location":"meetings/2023-05-03/#agenda","title":"Agenda","text":"Review action items from last meeting
Welcome new TAC member
Task Force Proposal
Assessment Framework
Call for code from the community
Next steps
Reminder
These meetings are covered by the Antitrust Policy and the Code of Conduct.
"},{"location":"meetings/2023-05-17/#2023-05-17","title":"2023-05-17","text":""},{"location":"meetings/2023-05-17/#agenda","title":"Agenda","text":"Review action items from last meeting
New lab proposals
Special Interest Group process proposal
OID4VCI and OID4VP Due Diligence Task Force
Call for code from the community
Next steps
Reminder
These meetings are covered by the Antitrust Policy and the Code of Conduct.
"},{"location":"meetings/2023-05-31/#2023-05-31","title":"2023-05-31","text":""},{"location":"meetings/2023-05-31/#agenda","title":"Agenda","text":"OID4VC Due Diligence Task Force
Credential Format Comparison SIG
Review action items from last meeting
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
Credential Format Comparison SIG
Call for code from the community
Next steps
Reminder
These meetings are covered by the Antitrust Policy and the Code of Conduct.
"},{"location":"meetings/2023-06-14/#2023-06-14","title":"2023-06-14","text":""},{"location":"meetings/2023-06-14/#agenda","title":"Agenda","text":"Credential Format Comparison SIG
Announcements
Review action items from last meeting
OID4VC Due Diligence Task Force -- completed
Credential Format Comparison SIG -- in progress
TAC Alternates Policy
Call for code from the community
Open discussion and next steps
Reminder
These meetings are covered by the Antitrust Policy and the Code of Conduct.
"},{"location":"meetings/2023-06-28/#2023-06-28","title":"2023-06-28","text":""},{"location":"meetings/2023-06-28/#agenda","title":"Agenda","text":"Announcements
Review action items from last meeting
Vice chair seat and responsibilities
Wallets and personal data stores
Call for code from the community
Open discussion and next steps
Reminder
These meetings are covered by the Antitrust Policy and the Code of Conduct.
"},{"location":"meetings/2023-07-12/#2023-07-12","title":"2023-07-12","text":""},{"location":"meetings/2023-07-12/#agenda","title":"Agenda","text":"Announcements
Review action items from last meeting
Vice Chair
Farmworker Wallet OS project proposal
Call for code from the community
Open discussion and next steps
Reminder
These meetings are covered by the Antitrust Policy and the Code of Conduct.
"},{"location":"meetings/YYYY-mm-dd/#yyyy-mm-dd","title":"YYYY-mm-dd","text":""},{"location":"meetings/YYYY-mm-dd/#agenda","title":"Agenda","text":"A task force is a group that is focused on a task with limited scope and fixed time to complete. Unlike a special interest group, a task force will have a specific set of deliverables or work products that it will create and be limited in time to completion. A task force can be created by anyone in the OpenWallet Foundation community and must be proposed to and approved by the TAC.
Tip
If you would like to propose a Task Force, please see the task force proposal process.
"},{"location":"task-forces/#active-task-forces","title":"Active Task Forces","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.
"},{"location":"task-forces/OID4VC-due-diligence/#participating","title":"Participating","text":"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 @@ + +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.
+ + + + + + + +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.
+