W3C Solid Community Group: Weekly

Present


Announcements

Meeting Guidelines

  • W3C Solid Community Group Calendar.
  • W3C Solid Community Group Meeting Guidelines.
  • No audio or video recording, or automated transcripts without consent. Meetings are transcribed and made public. If consent is withheld by anyone, recording/retention must not occur.
  • Join queue to talk.
  • Topics can be proposed at the bottom of the agenda to be discussed as time allows. Make it known if a topic is urgent or cannot be postponed.

Participation and Code of Conduct

Scribes

  • elf Pavlik

Introductions

  • David Stenglein: Have been working with semantic web since early 2000. I want to find out more about solid.

Topics

Solid World

  • on track for 2024/02/27
  • Jeff Zucker put the event together
  • eP: is there a link?
  • HZ: not yet, should be available tomorrow.

fedcm demo

  • Th: I have few slideds.
  • Th: Similar to the article
    https://www.liquid.surf/2024/2/7/Can-FedCM-improve-Solid-login-flow#what-is-fedcm
  • Th: New draft spec for web browser, started by Google and developed in Federated Identity CG. Comparing with and without FedCM. The goal is to have the browser as the middlware. Web browser pops window for user to select IdP; all the flow happens in the background.
  • Th: showing live demo
  • Th: Issues, the API is developed that the website is providing a list of IdPs, usually only the most famous ones are included. FedCM is developed to match the current status. We want to allow a new IdP to register itself with the browser. This way it can be selected when visiting any website.
  • Th: Current status is that Google believes that this is the way CM should be implemented. We want to show them use cases for how it should really be implemented.
  • eP: You mentioned access token, does it build on top of OAuth2?
  • SB: Where can I understand trust issues with distributed identity? When facebook was hacked, they became an unreliable identity provider. How do you know that you are being provided with the site that you trust as your identity provider?
  • Th: We are discussing use of trusted providers, so you can trust all the IdPs from the list of providers.
  • SB: I understand some kind of bootstrap step. Can you point me to more resources to read up about all the trust and identity issues.
  • Th: There is one github issue. ( link ??? )
  • AC: To a certain degree, FedCM is not trying to address the trust issue head-on. For what you are describing, you might take a look at OIDC Federation. This lets you get around the large allow lists.
  • AC: In the flow that you have showed, it looked like authorization code flow. The site needs to re-run through the same flow when session expires. Is the flow different when you want to refresh expiry token?
  • Th: RP can do it directly without the browser refreshing.
  • AC: The use of cookies throws everyone off. Is use of cookies part of FedCM or is it orthogonal? Does 3rd party cookie go away? Is the IdP cookie only going to be available when there is a redirect from the same domain?
  • SB: Is it happening as redirect or is the browser acting as the broker?
  • Th: The browser acts as the broker.
  • Th: FedCM can be a good improvement for Solid and Fediverse.
  • HZ: How about non browser apps.
  • Th: When you do it with OIDC you still get browser view to redirect.
  • HZ: It is for the case when you have GUI, for the script you usually get tokens
  • Th: It is focus on the web browser.
  • AC: OIDC is browser-based login, client_credentials is not OIDC.

Co-chairs Rotation Schedule

URL: https://github.com/solid/specification/discussions/618

Special Topic Meetings

URL: https://github.com/orgs/solid/projects/16/views/1

  • eP: We could dive deeper into FedCM next week. I will followup on matrix chat.
  • HZ: Should we also have a meeting about solid notifications?
  • eP: I'm open to having one. I know that Rahul is also working on it. Would need more people to express interst.

WIP Implementation Feedback

WG Charter Update

Add guidance for maintaining clean git history with squash

URL: https://github.com/w3c-cg/solid/pull/15
(TODO: VB: needs adding guidelines. Requires squashing, there are a few comments, needs more attention. I'd like to hear more opinions on this. If you have some time please review this PR.)

Add security consideration for serving user-created files

URL: https://github.com/solid/specification/pull/598

  • eP: If we cannot agree on a solution, we should at least agree on, and document, the problem. Security issues should be higher priority.
  • eP: PROPOSAL: create one place to track security issues, attack vectors.
  • HZ: the trade off is how many documents are there

ACTION: eP to make PR with security threat use cases and capture one discussed in the PR

  • AC: OAuth has a "Security Best Practices" document. Perhaps we could do something similar

Clarify requests with N3 document in server-representation-turtle-jsonld

URL: https://github.com/solid/specification/pull/608

  • eP: Bring it back next week when Sarven will present

Quick Notifications

URL: https://github.com/solid/notifications/pull/192

RG: (Announcement Only) Request for reviews!

Release 0.11.0 Milestone issues

URL: https://github.com/solid/specification/milestone/7

  • HZ: If we close all listed issues, are we going to release 0.11?
  • AC: We can make progress on clarity on WebIDs and ClientIDs. We could do it without interfering with anything that will come with WG. Container Description and Storage Description look like bigger changes.
  • HZ: My question is about WG creation, and if 0.11 milestone would impact it as well.
  • AC: To my understanding, the WG will take it as an input document. It could be confusing if there is later rollback on the features.
  • HZ: I mostly ask if this would delay creatin of WG.

Specify container description

URL: https://github.com/solid/specification/issues/227

  • eP: also https://github.com/solid/specification/issues/525
  • AC: The biggest issue is that we are going around in circles. I recall Tim weighing in. We need some clear direction.
  • HZ: This brings a question on the process. I know that people are reluctant to vote one way or another.
  • eP: Proposal to document the status and close it with no-change, leaving the decision to the WG.
  • HZ: I think this may apply to the server description.

Server Description

URL: https://github.com/solid/specification/issues/355

  • AC: From implementatione experience, the problems come to the composite nature of the containers. It gets complicated with conditional requsts using etags. Server Description seems like a simpler case.
  • HZ: Do you think we can make a decision?
  • AC: I think we can outline situation and have some proposals ready. Here is the issue, and here are possible paths forward.
  • HZ: Can we use a special topic meeting?
  • AC: I'm usually double booked at this time
  • eP: we could find another time for STM for such an important topic.

Should Solid (storage) servers support "RDF documents" containing multiple subjects (or quads)?

URL: https://github.com/solid/specification/issues/610

  • Proposed by SC.
  • SC: Chairs, can you use "status" labels, e.g., "waiting for commenter".
  • SC: I think this issue can be closed but if there is anything outstanding, it should be broken up into specific questions/issues to follow up. I'd like to hear from ML on what needs further clarification or request
Select a repo