- Date: 2020-04-24
- Duration: 90 minutes
- Purpose: Meeting on Solid specifications; status, editorial
- Call: https://global.gotomeeting.com/join/934529805
- Chat: https://gitter.im/solid/specification
- Justin Bingham
- Sarven Capadisli
- Ruben Verborgh
- Dmitri Zagidulin
- Tim Berners-Lee
- Sarven Capadisli
- Status update on work in progress eg. https://github.com/solid/specification/projects/1
- Approach for WAC
- Websockets / Notifications
-
SC: Commits in #157 reflect criteria that had rough consensus on it. Text may not be perfect but it covers what we've agreed on already.
-
JB: We are okay to merge things into master as long as issues are identified inline
- RV: +1
- DZ: +1
-
JB: #156
- SC: Where should WAC live long-term? How should it evolve?
- DZ: Pull it into the main solid repository. Solid-specific flavor of WAC.
- TBL: Most important is that we have something up to date, works with tests. Should be only one WAC spec. Community does not need fragmentation.
- RV: Which one are we talking about? There is a document in w3c space and people have complained.
- DZ: There are three - original task for community note and wiki page, our github repo, OpenLink Software's
- SC: Can the core vocab be carried with the solid project? Key point is that we only have one core WAC. Look for common terms shared across these versions. Have consensus on how we bring these together into ACL vocab.
- SC: Can we create WAC document to solid/specification repo and then have pointers to the one in solid/specification?
- TBL +1
- JB +1
- DZ +1
- SC: We should go through issues and PRs in WAC first and close them out or transfer them into document
- TBL: We have Basic WAC for conformance and Extended WAC with more advanced features
- JB +1
- SC: We need to consolidate as much as possible
-
SC: Have categorized issues in the project board - https://github.com/solid/specification/issues?q=is%3Aissue+is%3Aopen+label%3A%22topic%3A+events+and+notifications%22
-
SC: Is the focus to get a stable version out, and then deal with the extended version later, with the exception of authentication?
- JB: Stable vs. Extended?
- SC: Stable: All new features but authentication should be put off for later
- RV: Now that we have a version number included it will help with backward compatibility
- TBL: Need to have more explanation of what is implied by version numbering scheme
- RV: Don't want people to misinterpret insecure version as intent::
- TBL: Explain that in the specification, not the protocol
- RV: Use 0.1 as current state, and go to major version with secure protocol.
-
SC: Alternative approaches for Notifications
- SC: WebSocket, Websub, Push Notifications, LDN, etc - people are raising them for different use cases
- JB: Websockets are a medium for delivering notifications, but we should also eventually support others, and should have a way that we determine what notifications are delivered.
- TBL: Need to get the standard websocket support prioritized and working. Notifications are a different cycle. If I @mention you (for example), that should then be able to use another notification system to send you a ping.
- JB: If we ultimately focus on two categories - what kind of things are of interest and how to notify people when things of interest happen
- DZ: Should we have an overall definition of terms used for Solid. Example - authentication spec explains terms for clients. Example - data owner vs. data controller.
- SC: In ecosystem spec we have a definition section. Can we use that?
- JB: +1
- SC: +1
- DZ: +1
- SC: In ecosystem spec we have a definition section. Can we use that?
-
#114 - Rename WebID-OIDC to Solid-OIDC
- RV: Felt that Solid was too narrow, but open to an approach that encompasses other things like DID
- JB: Can we agree that in writing the Solid Protocol spec we ensure that we don't forbid other identity systems that satisfy base requirements (i.e. DID)
- SC: +1
-
#89 - Update LICENSE.md
- JB: Who should we put for the copyright? Can we attribute to W3C community group
- TBL: Look into attributing to W3C
- SC: Will follow-up with someone at W3C to determine
- SC: Consider CC0
- JB: Can we create an issue and track this
- Effects some of the standard work we're doing
- Specifically deals with encrypted data storage
- Specification specifically says authn and authz should be configurable and pluggable
- We can make a good case that updated WAC approaches is valid as a supported mechanism
- Solid is specifically mentioned in the charter of the working group