Below is a listing of Solid Panels. Solid Panels are groups of individuals focused on a specific problem or domain relevant to Solid, with an aim to propose changes to the Solid Specification, Solid Roadmap, and/or Supporting Documentation. Anyone may join a panel or suggest a new panel.
Anyone can create a Solid Panel by submitting a request to the Solid W3C community group mailing list, or by making a pull request directly to this document.
This listing helps people find panels in which they may want to participate, and helps editors find panels to consult as part of the editorial process.
This is an example that people can use as a template for submitting their own panels. A description of the panel, including its focus and goal, should go here.
- Link to join mailing list goes here
- Link to public chat goes here
- Any other public communication link goes here
- [Panelist Name](link to github profile) <[email protected]> (@github handle)
- [Panelist Name](link to github profile) <[email protected]> (@github handle)
Candidate Proposals to the Solid Specification produced by this panel are likely to be associated with the Editorial Assignment Name, and will be principally reviewed by any editors assigned to it.
All Panels can be reached on [email protected]
There is a weekly W3C Solid Community Group call to review all panels on Thursdays alternating between 1000CEST and 1600CEST on https://zoom.us/j/121552099. See here to read the minutes of previous calls, find out the agenda and exact time of the next call, or to add an item to the next agenda.
You can also read weekly updates of all panels on This Week in Solid.
How various agents and authorized to access resources.
- Wednesdays at 10AM Eastern at https://hangouts.google.com/call/vsPFdfBxsTgfHcjKbmcXAEEE
- app authorization repository
- app authorization gitter channel
- Dmitri Zagidulin <[email protected]> (@dmitrizagidulin)
- Michael Thornburgh <[email protected]> (@zenomt)
- Justin Bingham <[email protected]> (@justinwb)
- Jackson Morgan <[email protected]> (@jaxoncreed)
- Sarven Capadisli <https://csarven.ca/#i> (@csarven)
- Henry Story <[email protected]> (@bblfish)
- Jamie Fiedler <[email protected]> (@jamiefiedler)
Candidate Proposals to the Solid Specification produced by this panel are likely to be associated with the Authorization editorial topic, and will be principally reviewed by any editors assigned to it.
Discussion and specs relating to Authentication and Auth Delegation protocols, including:
- WebID-OIDC auth delegation protocol
- WebID-TLS auth delegation protocol
- Username + password recommendations for local authentication
- WebAuthentication (proposed future integration)
- DID Authentication (proposed future integration)
- HTTP Signatures (proposed future integration)
- Mondays at 10AM Eastern at https://hangouts.google.com/call/3k5z3gBVKm-58m8Xgm2YAEEE
- dedicated forum thread
- authentication panel repository
- Dmitri Zagidulin <[email protected]> (@dmitrizagidulin)
- Paul Worrall <[email protected]> (@pjworrall)
- Michael Thornburgh <[email protected]> (@zenomt)
- Justin Bingham <[email protected]> (@justinwb)
- Jackson Morgan <[email protected]> (@jaxoncreed)
- Aaron Coburn <[email protected]> (@acoburn)
- Matthias Evering <[email protected]> (@ewingson)
- Henry Story <[email protected]> (@bblfish)
- Jamie Fiedler <[email protected]> (@jamiefiedler)
Candidate Proposals to the Solid Specification produced by this panel are likely to be associated with the Authentication editorial topic, and will be principally reviewed by any editors assigned to it.
Ensuring the interoperability of data as it is read and written by different users and/or applications. Topics of discussion will include vocabularies, shapes, shape trees, and the mechanisms through which these work together to provide consistent and safe access and manipulation of data in a pod by different agents and/or users.
- Dmitri Zagidulin <[email protected]> (@dmitrizagidulin)
- Justin Bingham <[email protected]> (@justinwb)
- Eric Prud'hommeaux <[email protected]> (@ericprud)
- Max Dor <[email protected]> (@maxidorius)
- James Schoening <[email protected]> (@jimschoening)
- Jose Emilio Labra Gayo <[email protected]> (@labra)
- Ruben Verborgh <[email protected]>(@RubenVerborgh)
- Kjetil Kjernsmo <[email protected]> (@kjetilk)
- Jason Reynolds <[email protected]> (@JKReynolds)
- Simon Shapiro <[email protected]> (@SimonShapiro)
- Sarven Capadisli <https://csarven.ca/#i> (@csarven)
- Arne Hassel <[email protected]> <@megoth_twitter>
- Aaron Coburn <[email protected]> (@acoburn)
- Jamie Fiedler <[email protected]> (@jamiefiedler)
- Elf Pavlik (@elf-pavlik)
Candidate Proposals to the Solid Specification produced by this panel are likely to be associated with the Data Interoperability and Portability editorial topic, and will be principally reviewed by any editors assigned to it.
This panel is responsible for establishing the test suite for Solid, and maintaining it over time as the specification evolves.
- Establish test suite requirements
- Propose test suite stack / framework
- Help server implementers run our test suites in their CI (GitHub PRs, Gitter support).
- Initiative per test suite:
- https://gitter.im/solid/test-suite
- https://github.com/solid/test-suite
- https://github.com/solid/webid-provider-tests
- https://github.com/solid/solid-crud-tests
- https://github.com/solid/web-access-control-tests
- Sarven Capadisli <https://csarven.ca/#i> (@csarven)
- Michiel de Jong <[email protected]> (@michielbdejong)
- Yvo Brevoort (@ylebre)
- Pete Edwards
- Alain Bourgeois
Development of mechanisms to shape and exchange notifications. See Charter.
The test suite should never contradict the Solid specification. When implementations and specification disagree, the test suite can help bring them closer together, but should not itself act as a voice in the discussion. It should help pod server implementations comply with the specification. It should help pod server implementations be compatible with one another. It doesn't necessarily have to test every possible combination of situations as long as it is useful to pod server implementers, and the reports its produces are a reliable source of information.