How RSCP is Governed
RSCP is developed through an open, transparent governance model that balances efficiency with community participation.
AutoviaTest.com
AutoviaTest.com builds and maintains the RSCP protocol, providing infrastructure for road safety credentials. It:
- Holds intellectual property (Apache 2.0 licensed)
- Manages the Trusted Issuer Registry
- Provides neutral infrastructure
- Coordinates with standards bodies (W3C, IETF)
Technical Steering Committee (TSC)
The TSC is the primary technical decision-making body. It consists of 5-9 members elected annually by maintainers.
- • Set technical direction and roadmap
- • Approve major specification changes
- • Resolve disputes between working groups
- • Approve new committers and maintainers
Monthly, first Monday 15:00 UTC. Open to observers.
Working Groups
Working groups are the primary venue for collaborative work on RSCP. Each group focuses on a specific aspect of the protocol.
Core Protocol WG
Specification, schemas, and cryptographic standards
- Maintain the RSCP specification document
- Define credential and presentation schemas
- Evaluate and approve cryptographic primitives
- Coordinate with W3C and IETF standards bodies
Implementation WG
SDKs, reference implementations, and tools
- Develop and maintain reference SDKs
- Create test vectors and conformance suite
- Review and merge community contributions
- Publish release notes and migration guides
Compliance WG
Regulations, regional adaptations, and legal
- Monitor regulatory developments globally
- Create regional compliance guides
- Engage with government agencies
- Review privacy impact assessments
Decision Making Process
Lazy Consensus
Most decisions use lazy consensus. A proposal is considered accepted if no objections are raised within 72 hours.
- • Bug fixes
- • Documentation updates
- • Minor clarifications
Majority Vote
When consensus cannot be reached, decisions go to a vote. 2/3 majority of TSC members required.
- • Disputed features
- • Breaking changes
- • New committer approval
RFC Process
Significant changes require a formal Request for Comments (RFC) with public review period.
- • New cryptographic primitives
- • Schema major versions
- • Governance changes
RFC Process
- 1Draft
Author opens PR with RFC document using the template
- 2Review Period
Minimum 2-week public comment period. Working group discusses.
- 3Final Comment Period
1-week FCP after addressing feedback. Last call for objections.
- 4TSC Vote
TSC votes to accept, reject, or request revision
Contributor Ladder
We recognize contributions at multiple levels. Here's how you can grow your involvement in the RSCP community.
Member
Anyone participating in the community
- Subscribe to mailing list or join discussions
- Participate in discussions
- Submit issues
- Comment on RFCs
Contributor
Active code or documentation contributor
- Have 2+ merged pull requests
- Active for 2+ months
- Sign Contributor License Agreement
- Listed in CONTRIBUTORS file
- Vote on non-binding polls
- Nominate new contributors
Committer
Trusted contributor with merge rights
- Sustained contributions over 6+ months
- Demonstrated expertise in their area
- Nominated by existing committer
- Approved by TSC majority vote
- Merge pull requests
- Close issues
- Participate in release decisions
Maintainer
Working group lead or core team member
- Outstanding contributions
- Deep protocol expertise
- Leadership in their area
- TSC supermajority approval
- Set working group direction
- Vote on technical decisions
- Represent RSCP externally