Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Minutes from CG plenary 2024-02-28 #630

Merged
merged 6 commits into from
Mar 6, 2024
Merged

Minutes from CG plenary 2024-02-28 #630

Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
ffb249b
Create 2024-02-28.md
michielbdejong Feb 28, 2024
5b3948c
Update meetings/2024-02-28.md
michielbdejong Mar 1, 2024
1f656d9
Update meetings/2024-02-28.md
michielbdejong Mar 1, 2024
c8732ed
Update meetings/2024-02-28.md
michielbdejong Mar 1, 2024
84b2563
Update meetings/2024-02-28.md
michielbdejong Mar 1, 2024
685193a
Update meetings/2024-02-28.md
michielbdejong Mar 1, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
144 changes: 144 additions & 0 deletions meetings/2024-02-28.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,144 @@
# W3C Solid Community Group: 28 Feb 2024 plenary

* Date: 2024-02-28T14:00:00Z
* Call: https://meet.jit.si/solid-cg
* Chat: https://matrix.to/#/#solid_specification:gitter.im
* Repository: https://github.com/solid/specification
Status: Published

michielbdejong marked this conversation as resolved.
Show resolved Hide resolved
## Present
* [Michiel de Jong](https://michielbdejong.com)
* [elf Pavlik](https://elf-pavlik.hackers4peace.net)
* <a href="https://csarven.ca/#i" rel="schema:attendee">Sarven Capadisli</a>
* Maxime Lecoq
* Jesse Wright
* [Ted Thibodeau](https://github.com/TallTed) (he/him) ([OpenLink Software](https://www.openlinksw.com/))
* Tim Berners-Lee
* Hadrian Zbarcea

michielbdejong marked this conversation as resolved.
Show resolved Hide resolved

---

## Announcements

### Meeting Guidelines
* [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar).
* [W3C Solid Community Group Meeting Guidelines](https://github.com/w3c-cg/solid/blob/main/meetings/README.md).
* 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
* [Join the W3C Solid Community Group](https://www.w3.org/community/solid/join), [W3C Account Request](http://www.w3.org/accounts/request), [W3C Community Contributor License Agreement](https://www.w3.org/community/about/agreements/cla/)
* [Solid Code of Conduct](https://github.com/solid/process/blob/main/code-of-conduct.md), [Positive Work Environment at W3C: Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/)
* Operating principle for effective participation is to allow access across disabilities, across country borders, and across time. Feedback on tooling and meeting timing is welcome.
* If this is your first time, welcome! please introduce yourself.


### Scribes
* Sarven Capadisli


### Introductions
* JW: In Solid for ~5 years. Worked at Inrupt for the last year and a half; now again doing research in SW/Ethical Web ??? at U. of Oxford.

---

## Topics

### NDNComm panel announcement
URL: https://www.nist.gov/news-events/events/ndncomm2024

RG: Prof Lixia Zhang (UCLA) is organizing NDNComm at [NIST](https://www.nist.gov) with a panel titled "From local-first to fully-decentralized applications"
RG: Description: There exist many ongoing efforts aiming to steer Internet applications towards decentralized realizations; one such work was presented at last IETF — "Local-first software, resilient and secure collaboration". This panel will showcase examples of decentralized designs; articulate their commonalities and differences; share experience from the different efforts; and identify remaining challenges in building secure, resilient, and easy to use and deploy codebase with well defined API to facilitate new generations of decentralized apps.
RG: Would anyone in this meeting be interested in, or know someone who would be interested in, speaking about Solid and, especially, Linked Data, at this Panel? Please get in touch with me over chat.
RG: Everyone is invited to join as participants.


### Demo on indexing within Solid
Proposed by Maxime Lecoq (INRIA/Startin'Blox)

* ML: We will show an integration of indexes querying into the Startin'Blox framework over a federation of 32 live Hubl instances.
* eP: Where is the original source, and where is it indexed? Only for open public data, or takes access control into account?
* ML: Public but plan to support authenticated data.
* ML: Generated by federation server. In the future, the data is modified on an instance, and notifies to federation to regenerate.
* eP: Could it be done using a notification channel?
* ML: Yes.
* eP: Requirements on the source of the data?
* ML: Profiles of users?
* eP: Yes.
* ML: It's RDF. There are not WebID profiles yet.
* eP: How does adding to the index work?
* ML: We index everyone. In the future, don't know. Need to consult. Perhaps consent.
* MdJ: Can you summarise the conclusion on what practitioners need from specs?
* ML: See video from the [presentation on Solid practitioners](https://github.com/solid-contrib/practitioners/blob/main/meetings/2024-02-19.md). Federated or distributed.
* MdJ: Do you think we need to add this to the Solid spec?
* ML: I don't know. We are in the client-client domain. TypeIndex type of thing, which is not in the Protocol. It can be an addition.
* MdJ: If you want different servers together, then they need to communicate.
* ML: In the client-client standard we say we use this kind of index.
* TBL: Data serialization of client-client should be in different spec.
* eP: How do you <abbr title="Follow Your Nose">FYN</abbr>?
* ML: We're making SPARQL queries with Comunica. Fetch metadata index, then know where to go for, e.g., skills, cities. Then from the skill index, then continue to find the appropriate index with defined `ex:forProperty`, `ex:forValue`. Trying to make generic vocab for indexing. And also `rdfs:seeAlso`.
michielbdejong marked this conversation as resolved.
Show resolved Hide resolved
* eP: But to create the indexes, do you crawl the data?
* ML: For the demo, indexes have been created manually with scripts. In the future, we could crawl the data on the different instances with some kind of agent that creates the indexes automatically. Or we could define some client-client protocol rules, so that when a user is modified, the client can send a notification to the federation instance, which will then update its indexes.
* MdJ: You could write down what you've shown. How to add/remove self from the server.
* ML: Client-client for one application or domain. There can be other ones.
* MdJ: Do you want to take lead on that for search indexes?
* eP: I don't think it is client-client for search indexes. It is profile for interpreters, as I understand it.
* MdJ: Separate issue. I'm asking ML if he wants to write the spec for across all verticals.
* ML: Maybe to have a work item.
* MdJ: Find people to work on it. Start with STM.
* eP: How is provenance of data kept?
* TBL: Suppose I find that the info in the app is wrong; can I go back and change it, for example?
* SC: Sounds like "Oh yeah?" and updating: https://www.w3.org/DesignIssues/UI#OhYeah
* ML: The app displays information coming from the user profiles. So if a user sees a mistake in the displayed information, they could update their profile on their instance. Then, on the next search the information will be fixed.


### Fitting Solid into OAuth
* MdJ: For instance, see how SAI data needs can be interpreted as (dynamic) OAuth scopes, and benefit from integration with existing work and best practices, and for instance UMA.
* MdJ: Also touches on authn/z. In Solid, we say it in ACLs, and SAI moves away from that. We try to define scopes. In NSS, asking whether to authorize, but attached to OIDC. Even if you use SAI or multi app. As soon as sharing data with others, with ACL design, need to add your own app to that. Client to fit into OAuth could benefit Solid?
* TBL: Is that like to switch in DIDs?
* MdJ: Could use DIDs and VC instead of DPOP. Still doing authn. "Am I on the guest list for this resource?" The answer is in the ACL sitting next to the resource. SAI doesn't do it that way. It uses the Data Needs or Access Grants. UMA scopes are types of data. Clunky but works.
* eP: Re OAuth, it is all about delegation framework. Resource owner delegates to an authorized client. The end user can authorize the client. The user can delegate a subset of requirements. Also possible to delegate to another person or further in the chain.
* MdJ: With the ACL design, there is no good way for delegation. If you think of multi-app Solid without delegation, it sounds we need to shift to something like OAuth.
* eP: related issue https://github.com/solid/specification/issues/517
* SC: as I understood, the things we need in Solid are just different use cases. Some are not particularly well covered by a single mechanism, so we're open to integrate different mechanisms as time goes by. It's difficult to say "let's move into one in particular".
* MdJ: Yeah, needs to be something we can cover as well. Could be scary to have specs that don't (or do?) stack up. I'm already concerned about several solutions. Need to choose one direction.
* eP: Re multi-apps or -agents: in SAI, we focus on both. Any of the users can have multiple storages. Authn is hard problem. It is safer to not innovate in a way where it is not as well reviewed or tested.
* MdJ: TBL, how do you feel about ACLs and SAI approach?
* TBL: None of my code uses SAI. SolidOS uses WAC ACLs. I could imagine changing but the SAI way to use an app where it has an endpoint. So, need to have something on the Web. Mixing the page with the app. The world of trusted apps you do a lot of stuff like MS Word, Excel on the desktop where you give access. That's what people/consumers are used to. Collaborating with county members and doctors. If you build an app which I want to constrain to small amounts of things, that's reasonable. The whole process for running authentication agents gets unfortunately complicated. For example with bots, I got bots which do not need SAI. Like TimBLBot. I can give access to it using WAC or ACP. SAI to me looks complicated in the SolidOS world. Hackers? need Solid apps.
* MdJ: Need to keep developing both ACL and Data grant based. Maybe up to the WG to decide in the end, which authn/z it likes.
* TBL: What I like about consent is tracking the reasons why someone is given access to something.
* eP: With SAI, we pay attention to privacy. So, authz first before discovery. So, another app or peer in the network, they are not able to discover the kind of information. To address privacy requirements, we need to do authz first.
* MdJ: For example, in FB, everything is linked to your profile. Now, if you look at requirements for identity systems, it says don't leak global identity. Maybe want to use an app to give an access to bookmarks, but don't want to tell it my WebID.
* SC: Henry Story was also touching on this quite a bit, presenting only the kind of credential that's needed to access something. Selective disclosure. This had to do with readable ACLs, extending WAC so the Controller can make the ACL readable without making it writable.
* SC: And about reusing existing specs (such as OAuth), Solid in itself is not the most adequate place to solve those hard authentication/authorization problems for the web. Try to reuse and extend minimally.
* eP: In some contexts, you don't want to use certain identifiers. In others, need to establish global identity. Many people use same name; they want to establish this kind of name/identity. So be relatable. Both directions are valid for different situations. Applicable to different use cases.
* eP: prior work https://kushaldas.in/posts/solid-project-webid-and-privacy.html
* TBL: Agree. Need to make sure the Solid community understands. People designing stuff for nuclear warheads.. ??? or someone linked to their online profiles. CC would give a token number, where it would work only once. Could that with WebID. Go to restaurant, happy to authn as me, but also come up with my phone and have it generate a ephemeral ID where I'd only give my address. For whistleblowers, for example, where they dump some information.
* MdJ: Using ephemeral IDs in combination with ACLs is almost a contradiction.
* TBL: Need to have a class of things. Prove that you are a restaurant. So they can know about my allergies or something.
* MdK: If I'm using my restaurant app with different restaurants, then I'm authn with 20 IDs. If I have a different one for every restaurant, then I need to manage them.
* TBL: You don't. Ephemeral.
* MdJ: Then don't get entered into ACLs?
* TBL: ???


---

* MdJ: Leaving these topics for the next meeting:

### Update on ecosystem tests work
URL: https://github.com/solid-contrib/ecosystem-tests

* MdJ: We're starting ecosystem tests with headless browsers. Making progress on switch from launcher-exploration to SAI.


### ACP Tooling
URL: https://www.inrupt.com/blog/podbrowser-sunset

* MdJ: Does podbrowser sunset create a gap that needs filling?


### Meeting recording and publication
URL: https://github.com/w3c-cg/solid/issues/18