-
Notifications
You must be signed in to change notification settings - Fork 46
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
* Add agenda 2024-08-21 * Update agenda 2024-08-21 * Apply suggestions from code review Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com> --------- Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
- Loading branch information
1 parent
a10fba0
commit 80f85cc
Showing
1 changed file
with
99 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,99 @@ | ||
| # W3C Solid Community Group: Weekly | ||
|
|
||
| * Date: 2024-08-21T14: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 | ||
|
|
||
|
|
||
| ## Present | ||
| * [Virginia Balseiro](https://virginiabalseiro.com/#me) | ||
| * [elf Pavlik](https://elf-pavlik.hackers4peace.net) | ||
| * [Sarven Capadisli](https://csarven.ca/#i) | ||
| * [Rahul Gupta](https://cxres.pages.dev/profile#i) | ||
| * Rui Zhao | ||
| * [Pierre-Antoine Champin](https://champin.net/#pa) | ||
| * Hadrian Zbarcea | ||
|
|
||
| --- | ||
|
|
||
| ## 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 Conduct](https://www.w3.org/policies/code-of-conduct/) | ||
| * 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 | ||
| * RZ: Post-doc at Oxford Univ. Working on ethical web and data architectures. Read about Solid quite a few years ago. I was invited last time by eP for work on Data Terms of Use. Related to authorization and access control in Solid. Here I am. \o/ | ||
|
|
||
|
|
||
| --- | ||
|
|
||
| ## Topics | ||
|
|
||
| ### Solid Community AU follow-up | ||
|
|
||
| * VB: STM to follow up on specific topics on August 27th or September 3rd (12:00 UTC). | ||
| * VB: Related to encryption and authorization. | ||
| * eP: Discovery. | ||
| * SC: Message payload being encrypted? Storage encryption? | ||
| * eP: I understood it as resource being encrypted. | ||
|
|
||
| ### Rui Zhao's work | ||
|
|
||
| * eP: invited Rui to present his work | ||
| * paper: https://dl.acm.org/doi/10.1145/3589334.3645631 | ||
| * draft: https://renyuneyun.github.io/solid-dtou/dtou-spec.html | ||
| * mentioned in https://github.com/solid/security-considerations/issues/12#issuecomment-2191897863 | ||
| * RZ: slides: https://docs.google.com/presentation/d/1Ax7Vjo0FkmguhhnHRbhj_iQ5ivQzZjs_urqHhixqu1o/edit | ||
| * RZ: We don't like the "biggest lie on the Internet" but their contents are important. | ||
| * RZ: Are we at a better position in Solid? Actually no. Problems are more serious. We expect more apps; user to make decision on data usage (autonomy). DToU may be a way out. | ||
| * RZ: DTOU research targets: encoding user preferences (for data usage) and/or apps promises/behaviours (of data usage); supporting interoperability in decentralized context; check compliance and/or other policy semantics (e.g., obligations); support continuous policy checking. | ||
| * RZ: Perennial. | ||
| * RZ: Users encode data policy and associate with documents; app policy to be sent by the app to Solid service; protocol to perform reasoning tasks and facilitate use. | ||
| * RZ: Some advantages (compare to normal access control) to for users and apps. | ||
| * RZ: There are policy sets. We want to how input data/policy should generate output. | ||
| * RZ: Needs policy authoring — user needs to be able to write data policies with helper tools, users need to write access rules, apps need to write app policies. Needs to go beyond document/container-level policy. | ||
| * RZ: Need some helpers: ML/NLP/LLMe, e.g., privacy policy to app policy, user behaviour observation agent. Better semantic coverage (unifying tags, extended activation condition, time constraints). Align with, e.g., ODRL. Establish "contract", provenance, and auditing tools. | ||
| * eP: I've read your paper. You also have the spec but haven't read yet. Seems comprehensive. | ||
| * eP: Are you familiar with some existing efforts? — noting SC's mentions | ||
| * eP: https://tosdr.org/ | ||
| * RZ: Right, found that in the early days of the work. I wasn't focusing on that, because that was still relying on natural language policies (c. 2018/2019). The only way is to use formal encodings, and that's where my research is heading. | ||
| * eP: Goals are similar although tech is different. I understand that you worked with Solid Labs? And also UMA? | ||
| * RZ: I've talked with Blake (???) last year. | ||
| * eP: I think they prepared a demo for the Solid Symposium 2024. See also https://github.com/SolidLabResearch/user-managed-access/ and https://github.com/woutslabbinck/ucp-enforcement | ||
| * eP: Now to the question. I really like "data owner" of resource policies. For my current understanding, I find it similar to how we do it in SAI. We have policies on the resource, different access/data grants, and access needs. I think it is more basic and no reasoning. There are different sides matching those. I think this is really important. I haven't seen much in Solid — SC had an example (see below). | ||
| * eP: In SAI, there is an org that owns data, and gives access to members, and then I want to access it with application. If, say, Solid CG gives me access, then I can give access to the app. Have you worked with delegations? | ||
| * RZ: What is possible at the moment is because data/app policy describing what criteria needs to be satisfying. Not particular to a data consumer. If possible for all these people to have the same criteria, we can set one. But if we need different policies for different persons, then that is not covered. | ||
| * eP: If I think about access control, for different agents, there are different permissions. Is there equivalent? | ||
| * RZ: ??? Roughly equivalen to Role-BAC. | ||
| * SC: Thanks for the presentation. Good to see your work reached some of the same conclusions that we have in Solid. | ||
| * SC: Some prior work (e.g., using ODRL/DPV) in Solid (2019) related to the things mentioned in the presentation: | ||
| * [ODRL in Solid](https://github.com/solid/authorization-panel/issues/55) | ||
| * [Implementation of an application — dokieli — making use of user's preferred policy against a storage's policy](https://github.com/solid/specification/issues/355#issuecomment-1140508784) — Open digital rights contrasting [storage description and personal policies](https://dokie.li/media/video/dokieli-odrl-storage-description.webm), [agreements and actions between people](https://dokie.li/media/video/dokieli-odrl.webm). | ||
| * [Expressing preferred policies or templates](https://github.com/w3c/odrl/issues/21) | ||
| * [Expressing preferred policies or templates](https://github.com/w3c/dpv/issues/36) | ||
| * [Discovery of an ODRL resource](https://github.com/w3c/odrl/issues/12) | ||
| * [Towards an authorization framework for the Solid ecosystem](https://github.com/solid/authorization-panel/issues/121) | ||
| * RZ: Thanks. I know some of those resources but not all. Speaking of ODRL, I do collaborate with Beatriz. She has a background in ODRL, access control in Solid. | ||
| * SC: BE presented their work at some point in Solid CG on that. | ||
| * eP: How are we following up on that? I understand that it is not Solid specific. Compare different UCs? | ||
| * SC: I'm interested in understanding the standards gap. Which are not addressing the use cases. Minor example: when I was doing the implementation above, the gap was how to express the idea that I prefer these policies. If we can break down the parts of the use cases or requirements, we can identify the extent to which the standards are covering those things, and which things we need to add. ODRL and DPV are in separate community groups. I presume they cover a lot of the considerations, and Solid did quite a bit of work too. Are there specific things when mixing and matching these that are not covered? Then that needs an issue. | ||
| * RZ: I think a lot of things are missing. Speaking of how to move forward: what additional things we need. What I'd imagine is write down a few use cases with current access control mechanisms. | ||
| * SC: Wrt to authorization, we have: https://solid.github.io/authorization-panel/authorization-ucr/ | ||
| * SC: Need to check assumptions all around re use cases and the solutions. |