Code That Shapes the Global Web
The SOCBB Project welcomes Open Source Engineering Firms and Independent Contractors to bid on SOCBB engineering contracts and deliver funded project work across the Chromium codebase.
Open RFP: FedCM IdP Registration API DevTrial Implementation for Chromium
Proposals due: November 16th, 2026
Questions and submissions: proposals@socbb.org
SOCBB invites proposals from qualified open source engineering firms and independent contractors to implement the Identity Provider (IdP) Registration API in Chromium as an extension of the Federated Credential Management (FedCM) API. The objective is a desktop DevTrial-quality implementation behind a feature flag, including the browser user experience and the JS and HTTP API changes needed to support the agreed specification and mockups.
The API is intended to support open-world federation, where identity providers cannot be enumerated in advance, including ecosystems such as AT Protocol, ActivityPub, Solid, and academic identity federations. This project will also broaden the community of contributors with sustained implementation expertise in FedCM.
The following public materials form the initial technical baseline:
In Scope
Implement the agreed desktop flows and supporting API behavior in upstream Chromium; integrate an appropriate feature flag; follow Chromium conventions for code quality, security, privacy, accessibility, localization, and maintainability; add suitable unit, browser, UI, integration, and web-platform tests; and provide DevTrial enablement instructions, a demonstration, known-issues documentation, and maintainer handoff.
Out of Scope
An Origin Trial, Intent to Ship, unflagged production launch, implementation in non-Chromium engines, formal browser or W3C approvals, and production telemetry. Any follow-on work to reach Origin Trial or shipping readiness will be procured separately based on DevTrial feedback. SOCBB expects the project to be completed within approximately two quarters. Proposals must include a milestone schedule, staffing assumptions, dependencies, and critical path.
Milestones and acceptance
| Milestone | Expected result | Acceptance |
|---|---|---|
| 1. Kickoff, design, and proof of concept | At kickoff, confirm the contractual specification and mockups, affected Chromium components and reviewers, delivery sequence, tests, dependencies, and risks. Then produce the technical design and exercise the highest-risk paths with prototypes or draft changes. | SOCBB approves the scope baseline, delivery sequence, test plan, and documented risks; the design covers all requirements; major architectural risks have been exercised. |
| 2. API foundation | Implement the required browser and renderer plumbing, validation, state handling, failure behavior, feature control, tests, and related specification feedback. | Changes build and pass applicable tests, remain disabled by default, and are merged or review-ready with all vendor-controlled feedback resolved. |
| 3. Desktop experience | Implement the agreed desktop UI and connect it to the API foundation, including success, cancellation, denial, invalid-state, and recovery paths. | Every baseline flow works end to end in a supported desktop build; required tests pass; accessibility and localization expectations are addressed; deviations are documented and approved. |
| 4. DevTrial readiness | Complete review, integration, stabilization, documentation, demo materials, known issues, and readiness review. | Required code is merged behind the flag; a qualified developer can reproduce the DevTrial. |
| 5. Evaluation and handoff | Support initial evaluation, correct vendor-attributable acceptance defects, transfer knowledge, and report feasibility findings and recommended next steps. | Final report, code and issue inventory, prioritized follow-on backlog, handoff session, and included [60/90]-day stabilization plan are accepted. |
Milestone payments will be tied to verified delivery and code-review progress. Upstream outcomes may depend on independent Chromium reviewers; acceptance will not be withheld solely for an external delay or decision when the vendor has resolved all feedback within its control and documented the blocker.
Delivery expectations
- Work upstream-first in public Chromium, W3C, and associated project systems whenever permitted; do not rely on a long-lived private fork.
- Submit changes in reviewable increments with appropriate tests and documentation. Additional party to perform in-house reviews for CLs preferred (where a project-specific OWNERS is possible).
- Meet remotely over video conferencing weekly with the current OWNERS of FedCM and provide bi-weekly written reports covering completed work, upcoming work, review status, risks, decisions, and schedule health.
- Raise material technical or timeline blockers promptly and reflect observable-behavior changes in the relevant public specification or issue.
- Contribute deliverables under licenses and contribution terms accepted by the upstream projects.
- Use a written change request for any material scope, schedule, or price change.
Proposal requirements
Proposals should be concise and include:
- The proposed technical approach, implementation sequence, test strategy, upstreaming plan, schedule, and key risks.
- A milestone-by-milestone staffing and fixed-fee or not-to-exceed price, plus separate pricing for optional Android work and maintenance.
- Named personnel, availability, and relevant experience in C++, browser architecture, Chromium, committer status, OWNER-ship status, Blink, V8, web platform APIs, browser UI, or federated identity.
- Links to profiles / posts that show familiarity and engagement with open and decentralized social networks such as AtProto/BlueSky, ActivityPub/Mastodon/Threads and Solid/LWS isn’t a strict requirement but is appreciated.
- Links to at least three comparable upstream contributions or projects, identifying the respondent’s role and outcome.
- Project management, reviewer-engagement, continuity, security, privacy, accessibility, and defect-management practices.
- Required sponsor inputs, assumptions, exclusions, subcontractors, conflicts, and proposed exceptions.
- Two client or open-source maintainer references and the period for which pricing and staffing remain valid.
Evaluation
Submissions will be evaluated by the SOCBB Steering Committee based on architectural merit, long-term codebase impact, execution feasibility, team qualifications, and value. SOCBB may request clarification, interviews, references, or a best-and-final offer.
Submission
Send one searchable PDF to proposals@socbb.org by November 16th, 2026 at 11:59pm EST with the subject “Proposal: FedCM IdP Registration API DevTrial.” Questions and material answers may be shared with all prospective respondents. The selected respondent will contract using the standard Linux Foundation paper with the statement of work and payment schedule added as an addendum.
Submit your Proposal
RFP Guidelines
To maintain a vendor-neutral, fair, and transparent procurement process under Linux Foundation governance, all applicants must meet the following criteria:
- Technical pre-qualification: Proposals must demonstrate verified experience in C++, system architecture, or direct upstream code contributions to Chromium, Blink, V8, or related engines.
- Open source compliance: All deliverables funded by SOCBB must be contributed back to the upstream Chromium project under compliant open-source licensing.
- Milestone-based procurement: Contracts are strictly performance-driven. Capital is allocated and disbursed upon the successful verification and code-review approval of agreed-upon technical milestones.
- Objective governance evaluation: Submissions are evaluated anonymously by the SOCBB Steering Committee based on architectural merit, codebase longevity impact, and execution feasibility.
How to Submit
Before submitting your proposal, please review all RFP Guidelines.
Submissions should be sent to: proposals@socbb.org.
Common Questions
Contracting
What happens if my bid is accepted?
You will receive an email upon bid acceptance containing a form for required contract information. Please allow 7–10 business days for the contract to be sent for signature once information is submitted.
What are the Terms and Conditions?
Contracts are written using the Standard Linux Foundation Paper, with the SOW and payment schedule added as an addendum. Contract language is not negotiable, as the Linux Foundation manages the contracting and payment processing
Execution
How will the project be managed?
The WG will manage the contractor’s progress and technical alignment. You will be required to produce bi-weekly reports to ensure constant visibility into the project’s health. Any technical or timeline challenges must be addressed promptly with the Steering Committee.
Invoicing
How do I invoice?
Please include the PO# listed on your signed agreement and a short description of the work covered. Invoice submissions should include links to your mandatory weekly reporting or a high-level outline of completed tasks. Please DO NOT send invoices directly to Linux Foundation AP; this will delay the approval process
Concluding the work
How will the project conclude?
The WG will monitor you until all tasks are complete per the SOW. The WG will then formally conclude your engagement. All final invoices must be approved by the WG prior to payment.
Keep up-to-date on the RFP Program
Get Notified
Join the RFP notifications mailing list to receive emails as new RFPs open for bidding.
Review in-progress RFP reporting and progress
Visit SoCBB Github to learn about ongoing RFPs and the status of those projects.
Closed RFPs
Interoperability
Scope: Improving standards compliance and resolving interoperability issues across CSS features.
Web Tests Cleanup
Scope: The main objective is to improve the state of web tests in Chromium-based browsers. Test failures: Reducing the approximately 7,400 tests currently annotated in the TestExpectations file that are failing, timing out, crashing, or are flaky. Work includes analyzing the current situation, fixing code in the Chromium codebase, or fixing the tests themselves. Internal tests: Reducing the around 32,919 internal Blink tests (excluding external/ and wpt_internal/ subfolders) by migrating them to Web Platform Tests (WPT) or removing them if they are redundant. Work involves identifying areas for analysis, modifying useful tests to follow
WPT rules and exporting them, and removing tests already covered by WPT.
WPT Infra
Scope: Analyzing, triaging, and fixing infrastructure issues in the Web Platform Tests (WPT) repository to enhance cross-platform testing for Chromium features.
Coverage of Browser Implementation Status Metadata
Scope: Code and data changes related to browser implementation status metadata in web-features (tracking all shipped and in-flight features), browser-compat-data (providing the underlying compatibility data) and Chromium.
Tasks: Updates to web-features or browser-compat-data to accurately reflect the implementation status of web features in browser metadata for browsers and WebViews. Fixing issues related to code infrastructure supporting web-features and browser-compat-data proposed by Chromium contributors and approved by the SOCBB Steering Committee.