|
| 1 | +# W3C Solid Community Group: Weekly |
| 2 | + |
| 3 | +* Date: 2025-05-07T14:00:00Z |
| 4 | +* Call: https://meet.jit.si/solid-cg |
| 5 | +* Chat: https://matrix.to/#/#solid_specification:gitter.im |
| 6 | +* Repository: https://github.com/solid/specification |
| 7 | +* Status: Agenda |
| 8 | + |
| 9 | + |
| 10 | +## Present |
| 11 | +* [Michiel de Jong](https://michielbdejong.com) |
| 12 | +* [Christoph Braun / uvdsl](https://github.com/uvdsl/) |
| 13 | +* [TallTed // Ted Thibodeau Jr](https://github.com/TallTed) (he/him) ([OpenLink Software](https://openlinksw.com/)) |
| 14 | +* [Pierre-Antoine Champin](https://champin.net/#pa) |
| 15 | + |
| 16 | + |
| 17 | +## Announcements |
| 18 | +* https://github.com/solid/contacts/issues/8 was finally resolved! :) See https://www.w3.org/2006/vcard/ns |
| 19 | + |
| 20 | +### Meeting Guidelines |
| 21 | +* [W3C Solid Community Group Calendar](https://www.w3.org/groups/cg/solid/calendar). |
| 22 | +* [W3C Solid Community Group Meeting Guidelines](https://github.com/w3c-cg/solid/blob/main/meetings/README.md). |
| 23 | +* 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. |
| 24 | +* Join queue to talk. |
| 25 | +* 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. |
| 26 | + |
| 27 | +### Participation and Code of Conduct |
| 28 | +* [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/). |
| 29 | +* [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/) |
| 30 | +* 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. |
| 31 | +* If this is your first time, welcome! please introduce yourself. |
| 32 | + |
| 33 | + |
| 34 | +### Scribes |
| 35 | +* Michiel |
| 36 | + |
| 37 | + |
| 38 | +## Topics |
| 39 | + |
| 40 | +### Solid-OIDC session management |
| 41 | + |
| 42 | +* MdJ: Best practices for handling token-refresh / silent authentication in dynamically registered Solid apps (in the "old" version of Solid, i.e., DPoP-on-storage) |
| 43 | +* CB: I had multiple questions, parts of those are answered. The questions about why CSS provides DPoP-bound access instead of identity tokens. The practices about how the tokens are handled are mostly documented in the repo [README](https://github.com/uvdsl/solid-oidc-client-browser?tab=readme-ov-file#security-considerations) issues, but there is no one doc about it. There is OAuth best current practices for [browser-based apps](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps). |
| 44 | +* eP: Is it specific to dynreg? |
| 45 | +* CB: No, it also applies to clientid documents. It is rather a question on what security measures an IdP takes: In particular, regarding refresh token rotation (and enforcing it), and ability to revoke sessions, and not supporting (truly) silent authentication using iFrames or Popus (as CSS/Pivot currently do with their session cookies being `SameSite=None`). Such silent authentication poses a greater security issue than storing refresh tokens and a non-extractable DPoP keypair in an IndexedDB. See also [uvdsl/solid-oidc-client-browser/issues/3](https://github.com/uvdsl/solid-oidc-client-browser/issues/3) and [uvdsl/solid-oidc-client-browser/issues/6](https://github.com/uvdsl/solid-oidc-client-browser/issues/6). |
| 46 | + |
| 47 | +### Switch to UMA |
| 48 | + |
| 49 | +* eP: Thanks, Christoph, for digging into this, I'll start following up. I believe the Java client works with the UMA flow. For CSS, Wouter has been working on the UMA extension. |
| 50 | +* CB: I did not play too much with UMA, more looking at the spec and seeing most servers don't implement it yet. |
| 51 | +* CB: It's not necessarily an access token per resource, it can be per scope. All quite unclear. |
| 52 | +* eP: This week I'm going to read https://solidlab.be/wp-content/uploads/2024/11/User-Managed-Access-Whitepaper.pdf |
| 53 | +* HZ: UMA is implemented in ESS, but refer to Aaron for the details. |
| 54 | +* CB: I looked at the ESS access grants, and it sounded as going to an authorization endpoint, get the access grant, present that to the resource token which is a JWT. |
| 55 | +* MdJ: I think the client exchanges the DPoP token for an UMA token. |
| 56 | +* eP: I did a quick search and found https://docs.inrupt.com/developer-tools/java/client-libraries/introduction/#underlying-apis-internal-use. |
| 57 | + |
| 58 | +### Client Credentials |
| 59 | + |
| 60 | +* MdJ: I used https://www.npmjs.com/package/css-authn#usage with CSS this week and it worked well. |
| 61 | +* CB: It looks like you need to put in your password. Alternative is to use the CSS GUI to get the token. |
| 62 | + |
| 63 | +### AI scribing |
| 64 | + |
| 65 | +* eP: Let's use the permanent HackMD in the future: https://hackmd.io/@solid/cg-weekly |
| 66 | +* MdJ: OK! |
| 67 | +* TallTed: Note that this "friendly" link doesn't support going straight to `?edit` or `?both` |
| 68 | + |
| 69 | +### AI scribing |
| 70 | + |
| 71 | +* MdJ: does anybody object to trying out AI scribing in this call? |
| 72 | +* Jesse: OK, I'll set it up |
| 73 | + |
| 74 | + |
| 75 | +### Discover container containing given resource |
| 76 | + |
| 77 | + |
| 78 | +https://github.com/solid/data-interoperability-panel/issues/326 |
| 79 | + |
| 80 | +* eP: Issue above is specific to SAI Data Registration but could be generalized to a Solid Container. We consider a simple relation in the `Link` header. For the context https://activitypods.org/ dosn't plan to implement proposed `/` semantics. In https://sai.js.org, I currently support it, but would prefer to keep it as fallback mechanism and make something like discussed `Link` header relation the primary mechanism. |
| 81 | +* eP: Knowing this topic can be contentious, it could also be an interesting example for trying to approach it in systematic way and identifying how different proposals satisfy (or don't satisfy) different requirements. |
| 82 | +* PAC: Could you be specific about what you mean by slash semantics? |
| 83 | +* eP: If you have, e.g., `/calendar/event1` as the URL, from that one can infer that it is contained in `/calendar/`. So if ActivityPod wants to use, for instance, `/uuid/` and not give it slash semantics, it could expose its containment through an `ldp:contains` Link header. |
| 84 | +* PAC: I get it, but what's the benefit? |
| 85 | +* eP: If you work with data grants, you want to know which container contains a resource. Also open-with functionality might require it? |
| 86 | +* MdJ: Do you want to avoid slash semantics because you want a resource to be in multiple containers? |
| 87 | +* eP: If you want to rearrange groupings of resources, then slash semantics can be cumbersome. |
| 88 | +* HZ: There are other reasons, like security: leaking info through the URL. Or organizing data differently for different audiences. However, slash semantics is very useful to the owner of the data. I think Ruben had a very good post about views a while ago. |
| 89 | +* PAC: I don't want to turn this into a deep-in-the-weeds discussion, but to quickly react to Hadrian; that's not how I see it. HTTP IRIs have slash semantics. You can do `..` relative IRIs, no matter how the server works. What Solid says is that it has to be reflected as a hierarchy of resources, so if you do `..`, you end up at a container. I think the issue raised by eP about reorganising data, organisation can happen in many other ways using RDF and links. So using primary containers for logical organisation is not a great idea for that reason. Another point is mapping it to access control, which is probably too restrictive. But for me, those issues don't necessarily question the ability of going `..`. |
| 90 | +* CB: I 100% agree with PAC and would like to add about organising data in multiple different ways, supporting that, I would like to say that just because storage is container structured, the data catalogs, etc., don't need to follow that. So, I'd like to separate organising data from storing data. |
| 91 | +* eP: https://github.com/w3c/lws-ucs/issues/17 also assumes the data is organised semantically. We might want to work more with use cases and requirements. I don't know if all use cases can be satisfied by slash-semantics-based Solid servers. We can consider different approaches and evaluate them against the requirements, and use it as an example. I agree with PAC that the opacity issue is not black-and-white. Let's see 2 or 3 different solutions. |
| 92 | +* HZ: Two things: 1) what I mean is we need to separate resource identities from addresses. 2) we are pretty much all in agreement, so we might have an issue with the verbiage, with the terminology of how we describe things. We should put some emphasis on the way we describe things. |
| 93 | +* MdJ: Is someone going to implement this in CSS and provide an upgrade path for it for solidcommunity.net? |
| 94 | +* eP: I would be the person doing that. A client could try SAI and then fall back to slash semantics for instance. |
| 95 | +* MdJ: Do you think a server could do both WAC+type-indexes and SAI at the same time? |
| 96 | +* eP: I don't think it will be necessary to reconcile them in a generic Solid server. |
| 97 | +* CB: I would like to be part of this work, we're already doing similar things. Allowing different apps to write into WAC ACLs doesn't work well. but there is a middle ground about combining the ideas that solve the use cases. I would be interested in exploring that. |
| 98 | +* HZ: Commenting on what eP said, I like having multiple solutions. We could possibly have providers specify which protocols they support. If you want to port a pod from one to another, you have to make sure that they support the protocol you were using at the other one. |
| 99 | +* MdJ: So maybe now is the time to say there is not ***one*** Solid protocol? |
| 100 | +* eP: Solid is a work in progress and a moving target. Rahul was talking about microtypes. To come back to what CB said, yes please participate, and I like your proxy approach that I think you presented at Solid World. You can hide the origin of the data. I would like to understand those differences better, for instance for big files. |
| 101 | +* CB: sure, best way would be to put it on an agenda somewhere and ping me so I have that meeting in my calendar. |
| 102 | + |
| 103 | +### Shapes for calendars and events |
| 104 | + |
| 105 | +- https://icalendar.org/ |
| 106 | +- https://www.w3.org/TR/rdfcal/ |
| 107 | +- https://welcometomyplace.org/ |
| 108 | +- https://github.com/timbot1789/solid-calendar | [video](https://drive.google.com/file/d/1UikYqx-UDboml9aJFzK2glwd2rjjWbjl/view) |
| 109 | +- https://github.com/janeirodigital/sai-js/tree/main/examples/plenary |
| 110 | +- https://www.w3.org/groups/cg/solid/calendar/ |
| 111 | +- https://rallly.co/ | [doodle](https://doodle.com/) | https://apps.nextcloud.com/apps/appointments |
| 112 | +- https://github.com/SolidOS/meeting-pane | https://www.youtube.com/watch?v=anSkgFhua4M |
| 113 | + |
| 114 | +* eP: following up on last week's conversation on very common data domain |
| 115 | +* eP: there are vertical domains such a healthcare and horizontal ones such as contacts, calendar, etc. |
| 116 | +* MdJ: I'm also interested in that. In solid data-modules we try to have reusable code for that. We don't explicitly have calendars and events. |
| 117 | +* eP: it's also a good base as a use case for instance about authorization for LWS WG. Is anyone else here interested in exploring this domain? |
| 118 | +* HZ: yes |
0 commit comments