PROPOSED Federated Identity Working Group Charter
The mission of the Federated Identity Working Group is to develop specifications that enable users to authenticate an identity or present a credential or set of claims, in a way that is compatible with other protocols and is supportive of user security, privacy and agency.
This draft charter is available on GitHub. Feel free to raise issues or see the ones that are open.
| Charter Status | See the group status page and detailed change history. |
|---|---|
| Start date | TBD |
| End date | TBD + 2 years |
| Chairs |
Heather Flanagan (Spherical Cow Consulting)
Wendy Seltzer (Invited Expert) |
| Team Contacts | Simone Onofri (0.25 FTE) |
| Meeting Schedule |
Teleconferences: topic-specific calls may be held
Face-to-face: we will meet during the W3C's annual Technical Plenary week; additional face-to-face meetings may be scheduled by consent of the participants, usually no more than 1 per year. |
Motivation and Background
Identity on the Web is critical to online interaction, with implications for privacy, security, and user sovereignty.
Safely enabling these identity-related interactions requires new mechanisms mediated by the user agent that allow individuals to select identity information relevant to a given interaction, such as assertions, credentials, or specific attributes.
These mechanisms must also be viable for issuers, identity providers, verifiers, and relying parties to exchange information as securely and privately as possible, while supporting an open ecosystem.
While protocols and formats are being developed elsewhere (e.g., ISO, IETF, OIDF, and other W3C Groups), the Web platform layer must also be standardized to provide a secure and privacy-preserving API framework that is agnostic to and compatible with different identity request/response protocols and formats.
Scope
The Federated Identity Working Group defines Web Platform features that enable user agents to support secure and privacy-preserving interactions related to digital identities or digital credentials. These features will help users present the identity they want in each context they are in.
These features are intended to support different interaction flows (e.g., authentication, authorization, requesting and presenting identities or credentials, and issuance) in a 'traditional' federated identity model - with Identity Providers (IdPs) and Relying Parties (RPs) - and in a digital wallet 'decentralized' model - with Issuers, Holders, and Verifiers.
This group develops new mechanisms that define how information is passed by the user agent between the different entities to facilitate federated and digital identities:
- Enabling a Federated Identity Model while adhering to privacy principles despite the deprecation of third-party cookies, a cornerstone of such operations.
- Enabling a Decentralized Identity Model by invoking a wallet, without custom schemes or privacy-invasive alternative identity and attribute verification systems.
Out of Scope
The following topics are out of scope, and will not be addressed by this Working group.
- Designing new authentication methods.
- Designing individual credential and assertion formats
- Performing any security or confidence assessment (e.g. checking signatures, audience, encoding, etc) of the token that encodes the identity assertions.
- Ad-tech tools or APIs specifically focused on advertising as opposed to authentication.
Deliverables
The updated document status is available on the group publication status page.
Draft state indicates the state of the deliverable at the time of the charter approval. Expected completion indicates when the deliverable is projected to become a Recommendation, or otherwise reach a stable state.
Normative Specifications
The Working Group will deliver the following W3C normative specifications:
- Federated Credential Management (FedCM) API
-
This specification defines an API that allows users to login to websites with their federated accounts in a privacy-preserving manner.
Draft state: Adopted from the Federated Identity Community Group
Expected completion: CR in Q2 2025
- Login Status API
-
This specification defines an API to inform the Web Application of their user's login status, so that other Web APIs can operate with this additional signal. Currently, it is a separate chapter in the FedCM specification, and the goal is to publish it as a separate deliverable to be used by FedCM.
Draft state: Adopted from the Federated Identity Community Group
Expected completion: CR in Q2 2025
Tentative Deliverables
Depending on the incubation progress, interest from multiple implementers, and the consensus of the Group participants, the Group may also produce Recommendation-track specifications for the following document:
- Digital Credentials API
-
This specification defines an API that enables user agents to mediate access to and presentation of Digital Credentials in a format-agnostic (e.g., W3C Verifiable Credentials, ISO mDoc, credential formats produced by the IETF, etc.) and protocol-agnostic fashion (e.g. OpenID4VC, W3C Verifiable Credentials API, etc.), enabling different use cases such as - but not limited to - government-issued documents, academic credentials, IoT and Supply Chain related identities.
Draft state: Draft in the Web Incubator Community Group
Other Deliverables
Other non-normative documents will be created, including:
- A test suite, available from web-platform-tests, will be created for each normative specification.
- A Threat Model of Digital Credentials-related technologies concerning security, privacy, and human rights. These findings will be used as input for any of the group's Digital Credentials deliverables. This will be developed in collaboration with W3C's Technical Architecture Group (TAG), Privacy Interest Group (PING), Verifiable Credentials Working Group (VCWG) and other relevant groups.
Other non-normative documents may be created such as:
- Use case and requirement documents.
- Implementation report for the specification.
- Primer or Best Practice documents to support web developers when designing applications.
Timeline
- Q4 2024: FPWD for Federated Credential Management API
- Q1 2025: CR for Federated Credential Management API
Success Criteria
In order to advance beyond Candidate Recommendation, each normative specification is expected to have at least two independent interoperable implementations of every feature defined in the specification, where interoperability can be verified by passing open test suites, and two or more implementations (distinct browser engines) interoperating with each other.
In order to advance to Proposed Recommendation, each normative specification must have an open test suite of every feature defined in the specification.
In order for the Digital Credential API to advance to Candidate Recommendation, the relevant portions of the corresponding joint deliverable on threats and mitigations must also be published. In order for the Digital Credential API to advance to Proposed Recommendation, the relevant portions of the corresponding joint deliverable on threats and mitigations must have completed a wide review and addressed issues raised by the community.
In order to advance to Proposed Recommendation, the Digital Credential API must demonstrate support for at least two formats, for example those via OpenID4VP. (e.g., W3C Verifiable Credentials, ISO mDoc).
Each specification should have testing plans, starting from the earliest drafts.
To promote interoperability, all changes made to specifications in Candidate Recommendation or to features that have deployed implementations should have tests. Testing efforts should be conducted via the Web Platform Tests project. If any mechanisms developed to support authentication and authorization flows would cause breaking changes for existing protocols, work on that mechanism must include a well-documented transition period.
Each specification will contain a Security Considerations section - that includes a Threat Model with threats, attacks, mitigations, and residual risks - and a Privacy Consideration section - that must contain an analysis of privacy aspects such as Unlinkability, Minimization and Tracking - as specified in Self-Review Questionnaire: Security and Privacy, RFC 3552, and RFC 6973, detailing all known security and privacy implications for implementers, Web authors, and end users.
Each specification should contain a section on accessibility that describes the benefits and impacts, including ways specification features can be used to address them and recommendations for maximizing accessibility in implementations.
This Working Group expects to follow the TAG Web Platform Design Principles, Ethical Web Principles, and Privacy Principles.
Coordination
For all specifications, this Working Group will seek horizontal review for accessibility, internationalization, privacy, and security with the relevant Working and Interest Groups, and with the TAG. Invitation for review must be issued during each major standards-track document transition, including FPWD. The Working Group is encouraged to do a self-review and then engage collaboratively with the horizontal review groups throughout development of each specification. The Working Group is advised to seek a review at least 3 months before first entering CR and is encouraged to proactively notify the horizontal review groups when major changes occur in a specification following a review.
Additional technical coordination with the following Groups will be made, per the W3C Process Document:
W3C Groups
- Accessible Platform Architectures Working Group
- The Accessible Platform Architectures Working Group seeks to ensure that accessibility is kept front of mind, as authentication timing and the reliance on short term memory are known and thorny topics for people with disabilities. Our group is expected to regularly coordinate with them for accessibility-related issues.
- Decentralized Identifier Working Group
- The Decentralized Identifier Working Group is the maintainer of Decentralized Identifiers, one of the core building blocks of Digital Identities. Our group is expected to communicate with them for Digital Identities related issues.
- Federated Identity Community Group
- The Federated Identity Community Group is to provide a forum focused on incubating web features that will both support federated identity and prevent untransparent, uncontrollable tracking of users across the web. Our group is expected to regularly coordinate with them to put in the standardization track incubated proposals.
- Privacy Community Group
- The Privacy Community Group is to incubate privacy-focused web features and APIs to improve user privacy on the web through enhanced browser behavior. Our group is expected to regularly coordinate with them for privacy-related issues.
- Privacy Interest Group
- The Privacy Community Interest Group monitors ongoing privacy issues that affect the Web, investigates potential areas for new privacy work, and provides guidelines and advice for addressing privacy in standards development, including privacy considerations in specifications. Our group is expected to coordinate with them regularly on privacy-related issues.
- Social Web Community Group
- The Social Web Community Group maintains errata for any specs published by the Social Web Working Group. Our group should coordinate with them for identity related topics that may overlap with the IndieAuth spec.
- Web Application Security Working Group
- The Web Application Security Working Group develops mechanisms and best practices that improve the security of Web Applications. Our group is expected to coordinate with them for security-related issues.
- Verifiable Credentials Working Group
- The Verifiable Credentials Working Group is the venue for standardizing the Data Model for Verifiable Credentials. Our group is expected to coordinate with them for format and protocol-related issues.
- Web Authentication Working Group
- The Web Authentication Working Group is to define a client-side API that provides strong authentication functionality to web applications. While we are not developing an authentication mechanism, our group is expected to coordinate with them to provide feedback on authentication-related issues.
External Organizations
- IETF
- Coordinate with the IETF research groups and working groups, such as OAuth, for protocol components on which authentication and authorization features depend and credential formats.
- OIDF
- Coordinate with the OpenID Foundation (OIDF) for authorization and credentials flows (i.e., OIDC, OpenID4VC).
- OASIS
- Coordinate with OASIS for authentication flows (i.e., SAML).
- REFEDS
- Coordinate with REFEDS for multi-lateral federation best practices and a representative of the complex use cases of the research and education communities worldwide.
- European Telecommunications Standards Institute - Electronic Signatures and Infrastructure Technical Committee
- Coordinate with ETSI for eIDAS, which can use the deliverables of the Group.
- National Institute of Standards and Technology, U.S. Department of Commerce
- Coordinate with NIST for their guidelines on digital identity and implementations.
- ISO/IEC JTC 1 SC17 WG4 and WG10
- Coordinate with ISO for their work on interfaces and protocols for security devices, vehicle driver licenses, and related digital identities (i.e., mdoc).
- OpenWallet Foundation
- Coordinate with OpenWallet Foundation for their work on the Open Wallet Ecosystem.
Participation
To be successful, this Working Group should have participation from Identity Provider (IdP) operators and issuers of digital credentials, Relying Parties (RPs) and verifiers of digital credentials, wallet providers, federation operators, user advocates and experts in human rights, and browser vendors. In addition, there must be active Editors and Test Leads for each specification. The Chairs, specification Editors, and Test Leads are expected to contribute half of a working day per week towards the Working Group. There is no minimum requirement for other Participants.
The group encourages questions, comments and issues on its public mailing lists and document repositories, as described in Communication.
The group also welcomes non-Members to contribute technical submissions for consideration upon their agreement to the terms of the W3C Patent Policy.
Participants in the group are required (by the W3C Process) to follow the W3C Code of Conduct.
Communication
Technical discussions for this Working Group are conducted in public: the meeting minutes from teleconference and face-to-face meetings will be archived for public review, and technical discussions and issue tracking will be conducted in a manner that can be both read and written to by the general public. Working Drafts and Editor's Drafts of specifications will be developed in public repositories and may permit direct public contribution requests. The meetings themselves are not open to public participation, however.
Information about the group (including details about deliverables, issues, actions, status, participants, and meetings) will be available from the Federated Identity Working Group home page.
Most Federated Identity Working Group teleconferences will focus on discussion of particular specifications, and will be conducted on an as-needed basis.
This group primarily conducts its technical work on GitHub issues. The public is invited to review, discuss and contribute to this work.
The group may use a Member-confidential mailing list for administrative purposes and, at the discretion of the Chairs and members of the group, for member-only discussions in special cases when a participant requests such a discussion.
Decision Policy
This group will seek to make decisions through consensus and due process, per the W3C Process Document (section 5.2.1, Consensus). Typically, an editor or other participant makes an initial proposal, which is then refined in discussion with members of the group and other reviewers, and consensus emerges with little formal voting being required.
However, if a decision is necessary for timely progress and consensus is not achieved after careful consideration of the range of views presented, the Chairs may call for a group vote and record a decision along with any objections.
To afford asynchronous decisions and organizational deliberation, any resolution (including publication decisions) taken in a face-to-face meeting or teleconference will be considered provisional. A call for consensus (CfC) will be issued for all resolutions (for example, via email, GitHub issue or web-based survey), with a response period from one week to 10 working days, depending on the chair's evaluation of the group consensus on the issue. If no objections are raised by the end of the response period, the resolution will be considered to have consensus as a resolution of the Working Group.
All decisions made by the group should be considered resolved unless and until new information becomes available or unless reopened at the discretion of the Chairs.
This charter is written in accordance with the W3C Process Document (Section 5.2.3, Deciding by Vote) and includes no voting procedures beyond what the Process Document requires.
Patent Policy
This Working Group operates under the W3C Patent Policy (Version of 15 September 2020). To promote the widest adoption of Web standards, W3C seeks to issue Web specifications that can be implemented, according to this policy, on a Royalty-Free basis. For more information about disclosure obligations for this group, please see the licensing information.
Licensing
This Working Group will use the W3C Software and Document license for all its deliverables.
About this Charter
This charter has been created according to section 3.4 of the Process Document. In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence.
Charter History
The following table lists details of all changes from the initial charter, per the W3C Process Document (section 4.3, Advisory Committee Review of a Charter):
| Charter Period | Start Date | End Date | Changes |
|---|---|---|---|
| Initial Charter | 28 March 2024 | 28 March 2026 | (initial) |
| Rechartered | TBD |
Revised movitation/scope/success-criteria added deliverables: Digital Credentials API, Threat Model |
Change log
Changes to this document are documented in this section.