13:56:40 <RRSAgent> RRSAgent has joined #lws
13:56:44 <RRSAgent> logging to https://www.w3.org/2025/05/05-lws-irc
13:56:44 <Zakim> RRSAgent, make logs Public
13:56:45 <Zakim> please title this meeting ("meeting: ..."), laurens
13:56:56 <laurens> Meeting: LWS WG Meeting - May 5th, 2025
13:57:02 <laurens> agenda: https://www.w3.org/events/meetings/a19ab7dc-1753-433d-bac5-64e3ad8c0a43/20250505T100000/
13:57:03 <agendabot> clear agenda
13:57:03 <agendabot> agenda+ Introductions and announcements
13:57:03 <agendabot> agenda+ Action Items
13:57:03 <agendabot> agenda+ Use cases and requirements: presentation and Q&A
13:57:03 <agendabot> agenda+ Discussion: server-to-server authentication
13:57:06 <laurens> chair: laurens
13:57:23 <gibsonf1> gibsonf1 has joined #lws
13:57:29 <acoburn> acoburn has joined #lws
13:57:39 <uvdsl> uvdsl has joined #lws
13:59:25 <acoburn> agenda?
13:59:37 <eBremer> eBremer has joined #lws
13:59:44 <acoburn> present+
13:59:49 <uvdsl> present+
13:59:51 <laurens> present+
14:00:04 <eBremer> present+
14:00:55 <pchampin> present+
14:01:08 <uvdsl> scribe+
14:01:37 <acoburn> RRSAgent, make minutes
14:01:38 <RRSAgent> I have made the request to generate https://www.w3.org/2025/05/05-lws-minutes.html acoburn
14:02:21 <gibsonf1> present+
14:02:36 <hadrian> hadrian has joined #lws
14:02:52 <hadrian> present+
14:02:59 <csarven> present+
14:03:00 <laurens> next agendum
14:03:10 <uvdsl> laurens: 4 Topics - lets start with introducations
14:03:33 <uvdsl> bart: Bart Beulens, from VITO, Belgium
14:03:42 <uvdsl> ... involved with Solid since 2019
14:03:59 <uvdsl> ... involved in a project as setting us up as a Solid Pod provider in Flanders
14:04:10 <jeswr> jeswr has joined #lws
14:04:11 <uvdsl> ... organized the 2nd Solid Symposium in Leuven
14:04:21 <jeswr> present+
14:04:30 <uvdsl> ... we have a lot of work going on in the Solid-related domains, so we joined!
14:04:41 <uvdsl> laurens: Any announcements?
14:04:50 <laurens> q?
14:04:54 <ryey> ryey has joined #lws
14:04:58 <ryey> present+
14:05:01 <laurens> next agendum
14:05:01 <uvdsl> ... if not, we can move on to the next agenda item
14:05:14 <uvdsl> laurens: Action Items!
14:05:17 <bartb> bartb has joined #lws
14:05:20 <gibsonf1> gibsonf1 has joined #lws
14:05:37 <uvdsl> ... overview of closed issues? Any update hadrian?
14:05:48 <gibsonf1> gibsonf1 has joined #lws
14:05:52 <uvdsl> hadrian: there is! #1 was closed as duplicate
14:05:52 <laurens> https://github.com/w3c/lws-ucs/pull/149
14:05:53 <gb> https://github.com/w3c/lws-protocol/issues/1 -> CLOSED Action 1 reach out on LWS mailing list (on acoburn) due 2024-11-25
14:05:53 <gb> https://github.com/w3c/lws-ucs/pull/149 -> Pull Request 149 UC for portable storage and basic sharing (by hzbarcea)
14:06:10 <uvdsl> ... I did not want to close @@@ issues before the PR is merged
14:06:36 <uvdsl> laurens: any further action items?
14:06:41 <laurens> next agendum
14:06:44 <uvdsl> ... lets move on
14:07:07 <uvdsl> ... @hardian, do you have a more extensive announcement here? e.g. about the note?
14:07:07 <gb> https://github.com/hardian -> @hardian
14:07:09 <bendm> bendm has joined #lws
14:07:35 <uvdsl> ... I reviewed the issues and opened a PR on local data
14:08:18 <uvdsl> hadrian: @@@1 discussion on algorithms that run in the server / close to the data
14:08:47 <uvdsl> ... many services, e.g. query, run close to the server - these may require to access data directly
14:09:07 <uvdsl> ... and in that case these services need to recognise ACLs etc
14:09:19 <uvdsl> ... I believe this is out of scope for the WG
14:09:34 <uvdsl> ... but this is relevant for the discussion around portability
14:09:57 <gibsonf1> +q About how to handle query access control - triple-level uri's
14:10:05 <uvdsl> ... we had some previous conversations on running algorithms close to the data
14:10:15 <laurens> q+
14:10:17 <laurens> q?
14:10:24 <gibsonf1> +q to  mention about how to handle query access control - triple-level uri's
14:10:39 <uvdsl> ... when I finish my PRs most of the related issues can be closed
14:10:54 <uvdsl> ... also related: Identity / identifier
14:11:07 <acoburn> gibsonf1: be sure to use q plus (rather than plus q) to add yourself to the queue
14:11:19 <laurens> ack laurens
14:11:30 <uvdsl> laurens: to summarise, you have been working on @@@2, and you raise question to direct access to data ...
14:11:49 <gibsonf1> q+ to talk about Linked Data as an approach and query security - triple-level resources
14:11:50 <uvdsl> ... do we see a requirement on a query mechanism, e.g. SPARQL queries?
14:12:03 <uvdsl> hadrian: yes, this fits into this category
14:12:34 <laurens> q?
14:12:36 <uvdsl> laurens: there I think we should make a distinction between MUST and SHOULD - to distinguish between core elements and extensibility
14:12:51 <uvdsl> hadrian: I could make an argument that nothing is really required (??)
14:12:54 <laurens> q?
14:12:58 <laurens> ack gibsonf
14:12:58 <Zakim> gibsonf, you wanted to mention about how to handle query access control - triple-level uri's and to talk about Linked Data as an approach and query security - triple-level
14:13:01 <Zakim> ... resources
14:13:17 <uvdsl> gibsonf1: On the whole issue, how do you do access control with a query/algorithm.
14:13:37 <uvdsl> ... a though: are we doing actually Linked Data or only documents with triples as ACRs?
14:13:47 <uvdsl> ... if we do LD, then we need access control on a triple-level
14:14:19 <uvdsl> ... since its not a particular easy thing to do, triple-level access control, we maybe need two types of LWS, one for docs and one for LD.
14:14:29 <acoburn> q+ to talk about how we start with use cases, then requirements, and then solutions
14:14:56 <uvdsl> ... The thing I fear, if it is just files, you cannot do alot with the files at the end of the day compared to LD.
14:15:10 <uvdsl> ... what do you think about the idea of having both types?
14:15:12 <laurens> q?
14:15:33 <AZ> AZ has joined #lws
14:15:37 <AZ> present+
14:16:06 <uvdsl> hadrian: I can give my personal opinion: At same point, in your graph you will link videos or files. By necessity, there needs to be some form of a file/raw data storage.
14:16:18 <uvdsl> ... I'd argue that you can do a lot already with that
14:17:07 <uvdsl> ... what I see in industry, if you have data in database, you somehow have to make it accessible to other parties (including semantics), so I'd say that using LD is also a necessity
14:17:56 <ryey> q+ about trust, permission and offline interactions, for "compute with data"
14:18:26 <uvdsl> gibsonf1: So, one clarification on why would a necessary to use SQL database, when other technologies already solve the problems that these introduce
14:18:30 <laurens> q?
14:18:43 <uvdsl> hadrian: The databases exist, and are massively adopted.
14:19:15 <uvdsl> ... at scale, when sharing data, the semantics of the stored data needs to be shared as well
14:19:26 <uvdsl> ... so, LD will be a necessity, I think
14:19:28 <TallTed> TallTed has joined #lws
14:19:41 <jeswr> jeswr has joined #lws
14:19:55 <uvdsl> ... I don't think that we would avoid LD
14:20:01 <ericP> ericP has joined #lws
14:20:11 <laurens> ack acoburn
14:20:11 <Zakim> acoburn, you wanted to talk about how we start with use cases, then requirements, and then solutions
14:20:19 <ericP> present+
14:20:42 <uvdsl> acoburn: I just wanted to mention that it is maybe not a binary question, and there is a lot of room between an S3 bucket and a full triple store
14:21:20 <uvdsl> ... what we need is not a discussion around the implementation details but about the use cases, requirements and what to do with that
14:21:31 <ryey> q?
14:21:34 <ryey> q+
14:21:45 <laurens> ack ryey
14:21:45 <uvdsl> laurens: I'd be interested in a use case for triple-level access control, so please add that
14:22:10 <TallTed> present+
14:22:31 <uvdsl> ryey: I am slightly confused: Is the question about any compute close to the data, or only about LD queries?
14:22:34 <acoburn> rrsagent, make minutes
14:22:35 <RRSAgent> I have made the request to generate https://www.w3.org/2025/05/05-lws-minutes.html acoburn
14:22:41 <uvdsl> laurens: more general, I guess
14:22:59 <dmitriz> dmitriz has joined #lws
14:23:20 <RRSAgent> I have made the request to generate https://www.w3.org/2025/05/05-lws-minutes.html TallTed
14:23:48 <uvdsl> ryey: I do have an issue open for something other than query, which could be implemented as an agent running on the data - but the agent is necessary for our usecase, and the question is where the agent runs (also in terms of trust where the agent runs)
14:23:49 <laurens> q?
14:24:08 <gibsonf1> https://github.com/w3c/lws-ucs/issues/148
14:24:09 <gb> https://github.com/w3c/lws-ucs/issues/148 -> Issue 148 [UC] Triple Level Resource (State) (by gibsonf1) [triage] [usecase]
14:24:22 <TallTed> previous meeting: https://www.w3.org/2025/04/28-lws-minutes.html
14:24:24 <TallTed> next meeting: https://www.w3.org/2025/05/12-lws-minutes.html
14:24:50 <uvdsl> hadrian: Interesting topic, there is also an issue by csarven, to serve @@@3 from a Pod
14:25:08 <uvdsl> ... the Solid Server itself is an algorithm that sits next to the data to serve it
14:25:15 <uvdsl> ... question is: Is it the only one?
14:25:34 <laurens> q+
14:25:39 <uvdsl> ... do we want to consider plugins?
14:26:04 <uvdsl> ... I can see some Solid Servers that allow customers to configure plugins like in WordPress
14:26:25 <uvdsl> ... but that is maybe rather a feature of an implementation
14:26:32 <uvdsl> ... instead of to be demanded by spec
14:26:40 <gibsonf1> q+ to say - maybe instead of plugins, we consider server capabilities where various capabilities have an interoperable protocol
14:27:02 <csarven> q+
14:27:11 <laurens> ack laurens
14:27:21 <uvdsl> ... I agree that there is a spectrum
14:27:33 <uvdsl> laurens: I like the idea of plugins
14:27:41 <uvdsl> ... I am unsure about this in the spec
14:27:52 <uvdsl> ... but we would need a discovery mechnism for that
14:28:10 <uvdsl> ... in the spec if we want to go for that extensible model
14:28:11 <ryey> +1
14:28:16 <laurens> q?
14:29:07 <uvdsl> hadrian: discovery, yes, but again portability!
14:29:25 <laurens> q?
14:29:35 <laurens> ack gibsonf
14:29:35 <Zakim> gibsonf, you wanted to say - maybe instead of plugins, we consider server capabilities where various capabilities have an interoperable protocol
14:29:57 <uvdsl> gibsonf1: If I am understanding that a plugin is that is code that someone runs on a server?
14:30:10 <uvdsl> ... if so, then I am 100% against it
14:30:31 <uvdsl> ... I could not imagine someone writing code and then putting it into a secure server
14:31:03 <uvdsl> ... I dont understand how this would work
14:31:40 <uvdsl> hadrian: It is a Pod that can give you data in the form that you want (content-negotiation), which could be a plugin
14:31:49 <laurens> q?
14:31:49 <uvdsl> ... it is related to capability discovery
14:31:53 <laurens> ack csarven
14:31:56 <uvdsl> ... it is more a terminology issue at this point
14:33:00 <uvdsl> csarven: I dont follow the discussion: Look at the charter, we are supposed to come up with a protocol (or something like that) but that is not requiring to define the storing mechanisms and such
14:33:17 <uvdsl> ... we are to define the interfaces / interaction protocol
14:34:19 <uvdsl> ... if something is not going to be in particular relevant to the interaction between to entities to qualify as interoperable, then it is not to be defined by us
14:34:48 <uvdsl> ... I think we should focus the discussion around things that are measurable to be defined.
14:34:58 <uvdsl> ... example: should data at rest be encrypted?
14:35:22 <acoburn> q+ to clarify measurability in terms of testability
14:35:47 <uvdsl> ... if we can answer this question, then we would know if this is inscope of the charter
14:36:15 <hadrian> q+
14:36:23 <laurens> ack acoburn
14:36:23 <Zakim> acoburn, you wanted to clarify measurability in terms of testability
14:36:24 <uvdsl> laurens: we should only look at verifiable/testable things as a MUST
14:36:33 <uvdsl> csarven: yes
14:36:39 <hadrian> q-
14:36:57 <uvdsl> acoburn: Yes, I'd agree, we need to think about what goes into the test suite
14:37:00 <TallTed> q+
14:37:13 <uvdsl> ... something that we cannot test, is out of scope (e.g. encryption at rest)
14:37:14 <laurens> q?
14:37:17 <laurens> ack TallTed
14:37:55 <uvdsl> tallted: It is actually not a requirement for a spec that something is testable. Some things, specs just mandate.
14:38:13 <uvdsl> ... that aside, encryption at rest can be tested in a various ways
14:38:34 <uvdsl> ... if we are really defining a protocol, if we do that at all - not sure about that yet
14:38:56 <uvdsl> ... you could have a test suite that runs on the server, and see what happens on the storage/device
14:39:16 <uvdsl> ... so you can detect if the system/server really uses encryption rest
14:39:29 <laurens> q?
14:39:30 <csarven> q+
14:39:36 <laurens> ack csarven
14:39:43 <uvdsl> ... it is important to note that we do not have to test everything that is in scope
14:39:57 <uvdsl> csarven: Agreed, this is a more precise statement.
14:40:13 <uvdsl> ... that said, we cannot get away with that all the time
14:40:36 <uvdsl> ... at least there needs to be sufficient number of measurable / testable things to show that they are interop'ing
14:41:06 <acoburn> +1 to what csarven said
14:41:12 <laurens> q?
14:41:14 <uvdsl> ... I think we should be careful here
14:41:47 <laurens> next agendum
14:42:09 <uvdsl> laurens: last week, we discussed around authentication in the browser
14:42:22 <TallTed> s/uses encryption rest/uses encryption-at-rest (EAR) /
14:42:45 <uvdsl> ... currently, if we look at the Solid OIDC, there is no real server-to-server mechanisms
14:42:49 <acoburn> -> https://swicg.github.io/activitypub-http-signature/ ActivityPub and HTTP Signatures
14:42:54 <uvdsl> .. and there are other mechanisms
14:43:08 <uvdsl> ... so I'd be interested in the groups opinions
14:43:14 <RRSAgent> I have made the request to generate https://www.w3.org/2025/05/05-lws-minutes.html TallTed
14:43:20 <laurens> q?
14:43:40 <uvdsl> acoburn: as a note: this link is a CG draft, it does show prior art. It is referencing a previous version of HTTP sigs
14:43:45 <bendm> q+ to say CSS implemented clientside credentials out of (research) project necessity
14:43:49 <uvdsl> ... it will give you an idea about the possiblities
14:43:53 <laurens> ack bendm
14:43:53 <Zakim> bendm, you wanted to say CSS implemented clientside credentials out of (research) project necessity
14:43:55 <uvdsl> q+
14:43:59 <gibsonf1> q+ to say what is being used now (TrinPod)
14:44:22 <bendm> CSS implemented clientside credentials out of (research) project necessity
14:44:24 <uvdsl> bendm: CSS implements clientside credentials
14:44:31 <uvdsl> ... just FYI
14:44:46 <laurens> q?
14:44:48 <acoburn> q+ to mention client credentials impl experience
14:44:56 <laurens> ack uvdsl
14:45:05 <laurens> uvdsl: In our internal systems we use WebID+TLS
14:45:13 <laurens> ... which was one of the first authn mechanisms for Solid
14:45:24 <laurens> ... basically mTLS authentication without using the certificate chain
14:45:33 <laurens> ... but based on the WebID profile document for validation.
14:45:41 <bendm> CSS reference: https://communitysolidserver.github.io/CommunitySolidServer/latest/usage/client-credentials/
14:45:58 <laurens> acoburn: You are not validating the certificate chain. Are you using some root CA with that?
14:46:09 <laurens> uvdsl: We do not and have not considered that.
14:46:31 <laurens> ... as far as I remember we have disabled the validation of the chain in Tomcat and introduced our own validation logic
14:47:13 <laurens> acoburn: An alternative could be JWK as the serialization of your public key, you can use the x5c property to add a certificate chain
14:47:18 <laurens> s?
14:47:21 <laurens> q?
14:47:25 <laurens> ack gibsonf
14:47:25 <Zakim> gibsonf, you wanted to say what is being used now (TrinPod)
14:48:07 <dmitriz> (fwiw, I think HTTP Signatures RFC solves the server-to-server auth use case nicely)
14:48:17 <uvdsl> gibsonf1: We have a strange approach: our servers ip address, serial number, encryption - all servers use the same encryption library
14:48:17 <laurens> q?
14:48:17 <laurens> ack acoburn
14:48:17 <Zakim> acoburn, you wanted to mention client credentials impl experience
14:49:04 <laurens> q+
14:49:05 <uvdsl> acoburn: At Inrupt, we also implemented client credentials - it definitely works but it is cumbersome as it requires an additional pre-registration step
14:49:17 <laurens> ack laurens
14:49:29 <csarven> q+ to ask about UCs re S2S
14:49:50 <uvdsl> laurens: from our perspective is also that we were not happy with client credentials as a solution
14:49:59 <uvdsl> q+
14:50:13 <dmitriz> the other nice thing about HTTP Sig is that it plays nicely with DIDs
14:50:15 <uvdsl> ... I'd be intersted in a keypair based solution
14:50:21 <laurens> q?
14:50:25 <laurens> ack csarven
14:50:25 <Zakim> csarven, you wanted to ask about UCs re S2S
14:50:42 <uvdsl> csarven: HTTP sigs are interesting
14:51:02 <laurens> q?
14:51:04 <gibsonf1> q+ to say why server to server
14:51:12 <uvdsl> ... I am interested in the actual use cases, that hint at why we need S2S authentication
14:51:26 <uvdsl> ... activityPub is one example, and it makes since there
14:51:36 <uvdsl> ... but it is not specified how that works
14:51:50 <uvdsl> ... it is more ad-hoc in reality
14:51:56 <laurens> q?
14:52:11 <uvdsl> ... but again, I am more interested in the use cases that really demand this
14:52:13 <laurens> ack uvdsl
14:52:18 <dmitriz> @csarven -- you can think of Backup as a general S2S use case
14:52:18 <gb> https://github.com/csarven -> @csarven
14:52:29 <laurens> uvdsl: I am not familiar with HttpSig as an authentication mechanism
14:52:41 <laurens> ... I would be interested to hear what it offers over mTLS
14:52:46 <dmitriz> q+
14:52:49 <csarven> dmitriz: good example. then again, client can back up too =)
14:52:50 <dmitriz> q-
14:53:01 <uvdsl> acoburn: mTLS is a transport layer protocol
14:53:01 <laurens> acoburn: mTLS is a protocol that happens at transport layer
14:53:04 <dmitriz> @csarven - not really, not in batch/unattended mode
14:53:28 <uvdsl> ... HTTP sigs will happen at the application layer
14:53:32 <dmitriz> q+
14:53:36 <uvdsl> ... the two can happen at tandem
14:53:46 <uvdsl> ... but they are fundamentally at different layers
14:53:57 <dmitriz> q-
14:54:24 <laurens> q?
14:54:46 <laurens> uvdsl: Both do authentication one at transport and one at application level?
14:54:54 <csarven> dmitriz: Well, client can ask a backup to be created and send a notification to another server to go grab it. Not saying that S2S shouldn't happen in that case but if it demands that approach then I'd like ot hear something stronger.
14:55:10 <uvdsl> acoburn: because mTLS validates the particular server endpoint
14:55:15 <laurens> q+
14:55:19 <uvdsl> ... with HTTP sigs you validate the message
14:55:43 <dmitriz> @csarven -- well so lets follow that use case. 'a client can send a notification to another server to go grab it' -- and how would the server grab it? It needs to authenticate itself, right. hence the need for S2S auth
14:55:43 <gb> https://github.com/csarven -> @csarven
14:55:49 <uvdsl> ... and you exchange public keys and certificates
14:55:59 <laurens> q?
14:56:03 <laurens> ack gibsonf
14:56:03 <Zakim> gibsonf, you wanted to say why server to server
14:56:07 <uvdsl> ... and not
14:56:24 <csarven> dmitriz: but that server that needs to grab it, is not acting as a "server"! It is acting as a "client"
14:56:32 <uvdsl> gibsonf1: We have all our servers, and they syncronise
14:56:36 <acoburn> -> https://github.com/w3c/lws-ucs/issues/39 server-to-server use case
14:56:36 <gb> https://github.com/w3c/lws-ucs/issues/39 -> Issue 39 [UC] Server Side authentication and Data Access (by jeswr) [triage] [usecase]
14:56:41 <laurens> ack laurens
14:56:54 <uvdsl> ... that is, re server-to-server use cases
14:57:00 <dmitriz> @csarven - ah, i see the confusion. we're mixing two different meanings of 'client'
14:57:37 <dmitriz> @csarven - feel free to substitute in your mind S2S auth -> "auth that does not involve a browser url redirect"
14:57:37 <hadrian> q+ to ask pchampin if the draft ucs is published on a regular basis, so that I could use links to <dfn>s in the draft in issues
14:57:40 <uvdsl> laurens: what we have seen as a use case: sometimes an entity wants to access some data (e.g. an organisation accessing a user's Solid Pod) and that is while the user is offline.
14:57:44 <laurens> q?
14:57:48 <laurens> ack hadrian
14:57:48 <Zakim> hadrian, you wanted to ask pchampin if the draft ucs is published on a regular basis, so that I could use links to <dfn>s in the draft in issues
14:58:21 <uvdsl> hadrian: is the draft ucs is published regularly, so we could use links?
14:58:36 <uvdsl> pchampin: I do not think we have a decision
14:58:45 <uvdsl> hadrian: I'd like to link to definitions
14:58:55 <laurens> q?
14:58:56 <uvdsl> laurens: lets put the resolution of that on the agenda of the next meeting
14:59:17 <acoburn> RRSAgent, draft minutes
14:59:18 <RRSAgent> I have made the request to generate https://www.w3.org/2025/05/05-lws-minutes.html acoburn
14:59:24 <uvdsl> ... thanks for joining, see you next week
14:59:30 <gibsonf1> +1
14:59:48 <pchampin> RRSAgent, make minutes
14:59:50 <RRSAgent> I have made the request to generate https://www.w3.org/2025/05/05-lws-minutes.html pchampin
15:05:12 <acoburn> acoburn has left #lws
15:43:12 <timbl> timbl has joined #lws
15:48:51 <timbl> timbl has joined #lws
16:33:35 <timbl> timbl has joined #lws
18:02:28 <timbl> timbl has joined #lws
18:38:01 <timbl> timbl has joined #lws
20:30:10 <timbl> timbl has joined #lws
23:19:03 <timbl> timbl has joined #lws
<pchampin> i/lets start with introducations/topic: Introductions and announcements
<pchampin> s/introducations/introductions
<pchampin> i/Action Items!/topic: Action Items
<pchampin> i/any further action items?/topic: Use cases and requirements: presentation and Q&A
<pchampin> i/last week, we discussed around authentication in the browser/topic: Discussion: server-to-server authentication