07:16:38 RRSAgent has joined #lws 07:16:42 logging to https://www.w3.org/2025/10/08-lws-irc 07:16:42 RRSAgent, make logs Public 07:16:43 please title this meeting ("meeting: ..."), laurens 07:16:47 Meeting: LWS WG Face-to-Face Meeting (Day 1) 07:16:54 agenda: https://www.w3.org/events/meetings/fa24a556-f73b-42ad-9bb0-a3b2cc7678a5/ 07:16:54 clear agenda 07:16:54 agenda+ Welcome & Introductions (10:00) 07:16:55 agenda+ Discussion of agenda and priorities (10:30) 07:16:55 agenda+ Lunch break (12:30) 07:16:55 agenda+ Defining core operations of the LWS protocol (13:30) 07:16:57 agenda+ Scope of Query in LWS (16:00) 07:16:59 agenda+ End of day 1 (17:00) 08:04:46 acoburn has joined #lws 08:04:57 eBremer has joined #lws 08:04:58 wonsuk has joined #lws 08:10:42 acoburn has changed the topic to: Linked Web Storage - Face-to-Face Meeting (day 1): https://www.w3.org/events/meetings/fa24a556-f73b-42ad-9bb0-a3b2cc7678a5/ 08:10:57 RRSAgent, make minutes 08:10:59 I have made the request to generate https://www.w3.org/2025/10/08-lws-minutes.html acoburn 08:18:59 present+ 08:19:06 present+ 08:19:46 present+ 08:24:07 Wonsuk7 has joined #lws 08:25:32 jeswr has joined #lws 08:25:57 ryey has joined #lws 08:26:16 ericP has joined #lws 08:26:23 present+ 08:27:16 [laurens presents site logistics] 08:27:28 bartb has joined #lws 08:27:34 Beau has joined #lws 08:27:53 bendm has joined #lws 08:27:59 laurens: scribing on IRC. everyone should do about an hour 08:28:31 starl3n has joined #lws 08:28:49 ... I'll put the scribe-related stuff into a shared folder on Google Drive 08:30:32 [social event logistics] 08:31:25 laurens: goal over the next few days is to deveop spec from our UC&R 08:31:44 ... WG is 1 year old 08:32:04 ... which gives us one year to get to REC 08:33:07 topic: Introductions 08:33:27 laurens has joined #Lws 08:33:32 acoburn: Aaron Coburn (Inrupt) 08:33:35 present+ 08:33:44 present+ 08:33:50 present+ 08:33:53 ... I've implemented three or four LDP servers so I know it well 08:34:05 present+ 08:34:09 present+ 08:34:19 ... I've been involved with Solid around six years so I know the pain points 08:34:43 ... I'm most interested in simple/clear ways of authenticating access to storage 08:34:58 ... there will be a lot around that, but that's the core for me. 08:36:00 jeswr: Working on Solid for ODI. Ozzie 08:37:17 ... I'd like to see maximal deployment of Solid and I want to enable an LLM to find stuff for me. 08:38:00 laurens: I've been involved with Solid ~ seven years. I've encountered a feww frustrations: 08:38:27 ... e.g. a standard way to request access to resources 08:39:32 bendm: My colleagues and I have been doing SemWeb integration for 15 years. 08:39:59 ... Most important UC is security/access for closed data 08:41:04 bartb: working on a dtasharing platform using solid. built on ESS 08:41:23 ... we have collaborations with health data sharing initiatives 08:41:39 ... main challenge: sharing same data with different parties 08:42:08 beau 08:42:19 Beau 08:43:01 Beau: working on a project based on ESS also on health use cases 08:43:24 ... hope to extend Solid to authenticate access inside resources 08:43:50 ... background in commerce. data integration for two years prior to Vito 08:44:35 ryey: coeditor for Onogology for Media Resources and API for same 08:45:02 s/ryey: coeditor/wonsuk: coeditor/ 08:45:19 wonsuk: proposed ontology to integrate most of metadata formats 08:45:50 ... from 2015 I've been Automotive WG for intra-car comms 08:46:02 laurens has joined #Lws 08:46:52 ... last year i've been working on personal data and phishing UCs (big prob in South Korea) 08:47:06 ... funded by govornment 08:47:33 ryey: post-doc at Oxford U (with Jesse) 08:47:46 ... research on data access control 08:48:02 ... want to work on aaa and data usage control 08:48:31 ... personal experience in distributed technologies. see Solid as the only choice 08:48:48 ... i watch out for security and privacy 08:49:39 Stevent De Costa: Ozzie. Working in Cambra 08:50:11 ... I wasn't expecting Solid to be so well represented as it is 08:50:36 ... I'm interested in verifiable agreements 08:51:42 s/Stevent De Costa: Ozzie. Working in Cambra/starl3n: Stevent De Costa: Ozzie. Working in Cambra/ 08:52:38 ericP: Eric Prud'hommeaux, mostly interested in formal methods 08:53:35 ... patient control over data, as implemented in an NHS project 08:53:39 s/want to work on aaa and data usage control/want to work on data authorization and data usage control/ 08:54:11 s/research on data access control/research on data usage control and privacy-preserving computation/ 08:54:34 eBremer: Erich Bremer (Stonybrook U) 08:54:41 s/personal experience in distributed technologies/personal experience in decentralized technologies/ 08:54:56 ... working on software to manage lifecycle of digital pathology imaging 08:55:27 ... want to grease the rails of collabortive research, specifically federated learning 08:56:22 Frederik Byl: making health data exchangable/interoperable 08:57:38 laurens: we have a year. we can ask to extend but we need to have a plan 08:58:25 acoburn: reallistically, we need to get to CR well before the 1-year mark. need: 08:58:25 ... .. spec text 08:58:25 ... .. test suite 08:58:25 ... .. implementations 08:59:10 ... want to leave here with basic consensus on what the spec will look like, i think we can construct it over the next couple months 08:59:36 laurens: back-of-napkin sketch of what the protocol looks like 08:59:57 acoburn: are there areas where we have profound disagreements 09:00:14 ... and can we bridge them or defer them for later 09:00:30 ... we don't want to get bogged down in unfinishable tasks 09:00:50 jeswr: would be good to have a timeline for deliverables 09:01:40 laurens: i've been implementing apps on top of servers 09:02:10 ... challenges: can't give fine-grained access 09:03:00 bendm has joined #lws 09:03:10 ... apps impersonate me rather than being subject to finer access control 09:03:59 [delegation discussion expected tomorrow] 09:04:52 laurens: aspects of our protocol are complicated by e.g. controling access by non-authenticated principles 09:05:45 [slide: Things that bother me...] 09:07:08 laurens: we have some ideas for how to solve these problems. want to gather those over the next few days 09:07:32 ... what are the remaining blind spots? 09:08:20 bendm: server processes are focused around your POD 09:08:42 ... identity bottleneck is a hurdle. 09:08:52 ... would be nice not to have to create new accounts all the time 09:09:04 ... discovery would also be nice 09:09:27 acoburn: we call this the bootstrapping prob: 09:09:44 ... we have a new app or user and the setup is cumbersone 09:10:05 ... making that simpler would improve developer experience 09:11:00 bendm: our research focuses around integrating existing identiy infrastructure into Solid 09:11:56 ryey: we have attempted difference apps on Solid using e.g. MPC 09:12:08 ... or calendar or recommendation services 09:12:37 ... have comments on specs and toolkits 09:13:18 ... i've i'm developing an app and i need to store shared data as well as app configuration. where do i store it? 09:13:45 ... what if data changes, how do I respond to that? 09:14:23 ... suppose i want to store in one format and other apps want to consume it in another? 09:14:31 ... data interop focuses on that 09:14:48 ... what should we consider as part of the knowledge graph 09:15:11 ... how do we advertise the existence of e.g. identiy services 09:15:49 Frederik Byl: +1 to ryey 09:16:19 ... fine-grained access 09:16:44 ... imposing a hierarchical structure on a graph leads to incompatiblilies 09:16:57 bendm: +1, but... 09:17:10 ... it's not entirely the protocol's problem 09:17:40 ... we can have different views of the data. but maybe not on V1 09:19:34 Beau: [sparql access over ACL-controled data] 09:20:45 s/Beau: [sparql access over ACL-controled data]/bartb: [sparql access over ACL-controled data] 09:21:16 jeswr: should be possible to perform ACL-controlled SPARQL 09:21:30 acoburn: possible but very expensive 09:21:59 bartb: question of what you want to afford at the protocol level 09:22:21 laurens: trade-off of the expense of the protocol 09:23:04 Beau: Q of what should be required in spec 09:23:41 ... at the moment, hard to search and uniform access 09:24:03 ... spec aims to enable decentralized identity and storage 09:24:48 [slide: ...and how to solve them.] 09:25:36 RRSAgent, make minutes 09:25:38 I have made the request to generate https://www.w3.org/2025/10/08-lws-minutes.html acoburn 09:40:23 scribe+ bendm 09:41:27 laurens: agenda 09:41:37 ...: afternoon: core operations (storage protocol) 09:41:56 ... auxiliary resources, metadata handling, discovery 09:42:05 ... (of data and capabilities) 09:42:16 ... outcome I would expect: initial scope for the core operations 09:42:37 (all auxiliary files are at https://drive.google.com/drive/folders/1-zoqp1qwEHo0YgXN8c8Ld7NqvbPBdjc2) 09:42:56 ... other outcome: refined and prioritized list of core operations 09:43:12 laurens: 2nd topic (at 16:00): scope of query in LWS 09:43:27 ... what do actually want query to do in LWS? what are the blind spots? what do want for v1? 09:43:46 bartb: could the issue be data discovery iso query? 09:43:51 laurens: could indeed be 09:44:08 ... so we might want to rename this slot to discovery 09:44:28 ... it's not like we have a fully agreed opinion on this already 09:44:36 acoburn: this session is only 1h 09:44:46 ... scope is really important here 09:44:57 ... what kinds of questions do we want to ask to a Solid storage? 09:45:03 ... what is realistic for us as a group? 09:45:23 ... let's set us up for in-depth conversations on the other side of this meeting 09:45:41 laurens: core and discovery feels like a natural fit 09:46:02 ... at 19pm: dinner at otomat 09:46:36 ... for tomorrow: most of our morning will be about authorization 09:46:43 ... afternoon is about authentication: should we flip that around? 09:47:23 ... concerning authorization: pain points: granularity of authz, serverside client, delegated access for clientside clients 09:48:13 acoburn: authz is more complex than authn, so good to give most time to authz 09:48:28 ... tackling them both in one day is a good idea 09:48:46 ... from our charter: we are not going to invent an authn mechanism 09:48:57 ... we may talk about how LWS integrates with existing authn mechanisms 09:49:16 .... eg here's how you authenticate on the Web, not via a browser, etc... it's more about integration 09:50:15 bendm: also: seeing which authz mechanisms work for which use cases, and maybe we need a more flexible system 09:50:36 laurens: yes, you might want a more abstract interface to the authz server, but that gives complexities wrt interop 09:50:55 ... feel free to add more topics at https://docs.google.com/document/d/1ZgQ3BjODHYhQ_PJEaTzRxIhXXDCl_ivDGScYI9nUwWw/edit?usp=drive_link 09:51:07 ... we can continue authz discussion in the afternoon 09:51:32 ... for authn: let's talk about use cases, and which authn mechanisms are in use today 09:52:02 acoburn: I'd like to start today with clarifying the conceptual entities 09:52:10 ... you'll need those for authn/authz 09:52:21 ... eg external server, user, user using application on the browser, etc 09:53:01 ryey: we probably need to discuss how entities will interact 09:53:19 laurens: we'll also bump into identity of users and applications 09:53:32 ... i.e. what we need in terms of identity 09:54:05 ... (I'm updating the agenda on the go) 09:54:44 ... when discussing authn, we also need to discuss the complexities we introduce, we need to lower complexity for uptake 09:55:27 jeswr: I'd like to discuss between conceptual model for authz, and the protocol/flows used for that model 09:55:39 ... eg model is WAC, flow is UMA to get the tokens 09:56:08 laurens: in that model, you have different levels, eg RBAC, ABAC, etc 09:56:15 ... how you materialize that, could be via WAC or ACP 09:56:25 ... how you map that to an authz protocol 09:56:50 ... so 3 levels (conceptually, how do you materialize that, what interactions you need) 09:57:00 acoburn: and 4: what are the governing rules 09:57:14 ... "the rules governing enforcement" 09:57:45 ... e.g. you have ABAC, with attributes (user identity, app identity, time/space) 09:57:59 ... you need a way: how do those attribute come together in a policy language 09:58:28 laurens: e.g. in Solid, we don't have, in ACL, a DELETE mode 09:59:12 ryey: are we only talking about access control, or also usage control? 09:59:24 laurens: also important: how do you request and grant access 09:59:29 ... i.e., what comes before 09:59:41 ... also ties into data discovery 10:00:01 ryey: should we then move interaction patters sooner? 10:00:10 ... (interaction patterns discussion I mean) 10:00:17 laurens: I guess it'll get discussed 10:00:37 jeswr: also, the trust model: what can you consider authoritative data 10:00:49 ... right now, typically 'what are your trusted IDPs' 10:00:56 ... more generally, what is your root of trust? 10:01:11 laurens: i.e., what are your trusted entities in your network 10:01:54 acoburn: so, what is the model for understand how trust is delegated? 10:02:06 ... with webid, you say, here are the IdPs I trust 10:02:11 ... currently, it's not a chain 10:02:27 ... the way delegation generally gets handled, is via chains to a root of trust 10:02:50 ... idp lists got mentioned, but they don't scale 10:02:59 ... we need to think beyond that 10:04:01 laurens: (also social dinner at day 2 at 7pm Patrick Foleys) 10:04:11 ... day 3: start with notifications 10:04:22 ... some level of support is requested from the community 10:04:39 ... to be discussed: how much we want to support: resource changes vs inbox 10:05:19 acoburn: also, to be seen whether access requests are related to noticiations 10:05:38 ... historically, there has been websockets emphasis in Solid, there are a lot of problems with websockets 10:05:56 laurens: also, works well for clientside app, but not for serverside 10:06:35 ... good stuff in the notifications spec to look into 10:06:43 acoburn: and everything interrelates with everything 10:06:59 ... eg solid notifications: protocols have insufficiently defined authn/authz model 10:07:13 ... let's keep in mind how authn/authz works for notifications 10:07:27 laurens: also on Friday: test suite and multiple implementations 10:09:08 acoburn: we need two independent implementations (i.e. not from same organizations, not using same codebase), for each feature, everything else is marked 'at risk' after CR and gets droppen 10:09:58 ... so we need to be conscious what would be put 'at risk' 10:10:35 ericP: a good test suite will balance between 'working for generic implementation' and 'cater to specific parts' 10:10:48 ... eg 'here is a known user in the system' 10:11:31 ... so make clear that it's easy for implementers to implement a specific class to do a specific functionality 10:11:39 ... good idea is having facets in tests 10:12:07 ... so make sure that a test links to a specific facet, so that you know which test tests which feature 10:12:33 ... so, some shared state, some structured manifest, and facets in the manifest 10:12:49 laurens: we have some buffer on Friday 10:14:06 ... let's discuss roadmap and responsibilities at the end of each day 10:14:36 bartb: is the discussed priorities of last week taken into account? 10:14:54 laurens: indeed, we took that into account for blocking time for topics 10:15:04 ... and we need to circle back to each during each focus discussion 10:15:20 acoburn: the requirements document today is in a much better shape, but still needs a lot of work 10:15:30 ... let's give that appropriate attention as well 10:17:30 starl3n: there's a CKAN extension compatible with Solid 10:17:48 ... CKAN file storage 10:18:10 q+ to ask how the CKAN extension changed the implementation 10:18:39 https://github.com/DataShades/ckanext-files 10:19:22 ericP: to ask how the CKAN extension changed the implementation 10:19:45 ... that's going to influence our discussion, when we're figuring out what kind of API or model we need to support that extension 10:20:13 starl3n: there's no direct implementation with Solid for CKAN 10:20:34 ... CKAN is a rather basic implementation, but over time, companies got more interested in granular access control 10:21:42 ... people that have a public data catalogue, might have the actual data internally, and via AWS, so the model is decentralized 10:21:54 ... it has the kind of hooks to create that kind of affordances 10:22:28 ... I see a world where CKAN data integrates with personal data 10:22:51 Beau: notifications seem more complementary than data validation and data shapes 10:23:06 ... shapes also relate to querying 10:23:37 ack ericP 10:23:37 ericP, you wanted to ask how the CKAN extension changed the implementation 10:23:56 laurens: let's break for lunch, reconvene at 13:30 CEST 10:28:10 the note I was adding re reference implementation ideas is here: https://docs.google.com/document/d/1YapaCMiwSdqY1uHc5XfB6d_YvIkNwhP982sXbIY0BnM/edit?usp=sharing 11:37:42 acoburn has joined #lws 11:43:15 jeswr has joined #lws 11:43:39 acoburn: We want to see how all of the conceptual entites that we are working with relate 11:43:55 laurens has joined #lws 11:43:58 present+ 11:44:05 ... if 2 different types of entities we have posesss similar properties then they may be the same conceptual entity 11:44:13 bendm has joined #lws 11:44:13 wonsuk has joined #lws 11:44:13 ... first list catalog the entities we are interested in 11:44:34 rrsagent, draft minutes 11:44:35 I have made the request to generate https://www.w3.org/2025/10/08-lws-minutes.html laurens 11:45:01 Wonsuk6 has joined #lws 11:46:09 ... The conceptual entites we have are: Data resources (RDF and non-RDF), Containers, Metadata Resources and Access Control Rules 11:46:42 ... Data resources: These could be XML, a movie, RDF, JSON. Data in some format with some media type. 11:46:57 bendm: Do you link this to the endpoint where you get this from. 11:47:19 acoburn: We will get to that, in-short yes, we will want to define the HTTP operations to obtain these 11:47:48 ... Containers: These are collections of resources and other containers 11:48:13 ... Metadata: Information that is not part of a resource or container itself, but instead describes it 11:48:44 ... In Solid today the RDF resources are largely self describing. For other binary files like an image we don't have a good way of describing properties of those files 11:48:57 ... I am thinking of a metadata resource to describe properties of this resource 11:49:42 bendm: Could this be a data resource which has another type of link within another type of data resource. This would enable metadata on metadata resources. 11:50:14 acoburn: Potentially. I want to distinguish between data resources and metadata because you can then bind their lifecycles together 11:50:38 ... Then you also automatically have a location where you manage metadata about given resources 11:51:17 ... The semantics of data resources and metadata resources will be different. You want to ensure, e.g., that metadata resources cannot be deleted. Just actual resources. 11:52:23 ... We could imagine a metadata resource specific to a data resource, container or storage. Whether each of these metadata resources have different semantics depending on which of these 3 things they are describing is to be determined 11:52:45 ... Access Control Rules (ACL) are kind of like metadata resources, but I expect them to have different semantics. 11:53:22 ... Credentials: Unlike the first 4, these are not necessarily addressable. These are the kinds of things that you use to obtain access to the first 4 types of resources. 11:53:59 ... Validation / Key Material: These may be part of certain kinds of metadata. 11:54:43 ... Services: This is a very broad category, but a placeholder to say "maybe you have a way of doing query" or "maybe you have a way of doing validation" 11:55:48 bendm: The storage server itself should be its own conceptual entity. Then depending on how much we want to go into personal data, a Pod within that server. 11:56:11 jeswr: Please elaborate more on Validation / Key Material 11:57:20 acoburn: One example. You have a token issued by an openID provider. They give you public keys that are used to get access to a server. Another example is a validation that the data you put into a system is the same data that you get out of it. Another example is using HTTP Headers to prevent tamper protection. 11:57:39 bendm: Is this key material for both identity and signing the data itself 11:57:46 RazaN has joined #lws 11:57:49 acoburn: Yes, both 11:58:06 laurens: What about profiles 11:58:27 acoburn: This somewhat falls under validation / key material 11:59:31 beau: When you ask about metadata, could it also be data that exists within the resource? 12:00:15 acoburn: I am thinking of something similar to an rdf:Type that could go into the link header of the payload response on the data resource. This gives a hint of what it is. 12:00:42 bendm: But the distinction is that the metadata is in the data resource. The assumption is that if you delete the original resource then the metadata resource also gets deleted. 12:01:29 acoburn: Yes, also the possibility that you have put the metadata resource in there, and now you want to edit those metadata labels. There may be constraints around what you want to do and how you want to do it. You should be able to do this without needing to re-upload your resource 12:02:14 bendm: There may be a case that you have so much metadata that it becomes a resource in itself. Or that the metadata becomes more important, and that you want to delete an image and keep its resource 12:02:46 wonsuk: What about IDP servers 12:02:53 acoburn: We are not putting IDPs in this list right now, because we can cover this when we get to the AuthN section 12:03:19 bendm: Note that ACL rules aren't part of the resource server at this stage 12:03:47 acoburn: Ultimately the resource server needs to accept access tokens that need to be validated against something. 12:03:55 ryey has joined #lws 12:04:04 ... there may be some rules that need to be handled by an authorisation server or many layers of authorisation servers 12:04:41 bendm: Validation is both on data level and on token level, does it make sense to keep both Validation and Key Materials as the same thing. These feel like 2 different concepts. 12:05:20 acoburn: They could be split apart. My thinking on this a little hazy. In order to validate tokens and other types of credentials we will need some kind of key material 12:06:13 laurens: We are in a decentralised setting, so your trust model is most likely based on public keys. To me the key material is fairly related to PKI. 12:06:29 bendm: This feels like it gets into Verifiable Credential territory as well 12:07:02 laurens: They use similar infrastructure. Public keys and trust list, but this is more something that is happening on the client side for verification rather than the server side for verification. 12:07:11 bendm: We could have VC or wallet services that do this 12:07:37 wonsuk: When we use WebIDs or DIDs we need to use the WebID or DID document right? Could the WebID document be considered one of the resources. 12:07:55 acoburn: I would describe this as part of the key material part - this is why laurens similarly mentioned profile documents. 12:08:11 laurens: Yes, the profile resolves to the key material 12:08:30 acoburn: I am also thinking specifically about Controlled Identifer Documents which have a JWT keyID 12:09:26 ryey: Does this also include validating that the data. 12:09:44 acoburn: I am thinking about the content of a data resource as a black box. 12:10:00 ... I am not thinking of constraining in any way what you say inside the resource. 12:10:37 ryey: If we are thinking about authentication or identity this may be an issue if we want extensibility between documents. E.g. saying profileA sameAs profileB 12:11:16 acoburn: If we want to say that AgentA is the same as AgentB, then we just need the Authorisation system to recognise that they are the same, then you just need to produce a token that says these agents are the same thing. 12:11:42 laurens: An interesting question you could ask here is if ACL rules are managed and stored by the storage server or a separate service 12:12:16 ... You could in thery have a simple interface which splits out the ACL to a different server. Though this can introduce performance issues. 12:12:43 acoburn: These ACL rules are part of an AuthZ server which is conceptually different from the resource server, even though many implementations put them together in practise. 12:13:24 ... I wanted to highlight these as a conceptual entity because we have historically used the acl link relation in Solid. So we would need some concept of an ACL resource which we are linking to 12:13:39 laurens: Then how many types of metadata resource do we want to have 12:14:20 acoburn: In theory we could have arbitrarily many, in practise - I want to say there is 1 kind of metadata source, it has this semantic, and it acts like this. implementors can choose to add more. 12:14:49 bendm: Are you talking about really having 2. One ACL and one non ACL metadata. 12:15:08 bartb: Why do we need this? Data discoverability? 12:15:45 acoburn: The reason will become clear when we get to data discovery and query. If we have a common set of metadata, there are certain types of query structures and data discovery structures that we can enforce or require to make this easier. 12:16:12 ... if you have a metadata resource and a particular way of descibing its type. then you can create a type index and use that across the pod and every resource acts the same way. 12:16:48 ... in contrast if the type is going to apply differently between RDF and non-RDF resource, then you may need to have different ways of doing it for things that are not RDF 12:17:06 laurens: Data discovery is very important to the Authorization problem as well. 12:17:47 ... One thing I still wonder about is why we have both resources and containers if we already have resources. Could containment of resources not just be metadata? 12:18:05 bartb: This goes back to the question of are we basing this on LDP or not. LDP is very heavily container based. 12:18:23 laurens: Containers are somewhat a stop-gap to supporting authorisation over many resources 12:19:37 q+ to describe ShapeTrees approach to establishing where to place new stuff 12:19:38 acoburn: Here is a potential answer - I want to share data with an entity for everything that is in a particular container heirarchy. Now I want to create a new resource within that container heriarchy. An easy way to do that is if the container is itself a resource and we can post to the resource. If we can't do that because the container resource 12:19:38 is entierly virtual, then what we will end up from an HTTP perspective is something that is very flat. 12:19:52 ... the question of which container goes into is ... I worry about the developer experience. 12:20:13 q? 12:20:19 ... do we say here is an existing container and you get the developer to post there 12:20:35 ericP: I want to talk about stuff we did with shapetrees and SAI 12:20:37 ack ericP 12:20:37 ericP, you wanted to describe ShapeTrees approach to establishing where to place new stuff 12:20:56 ... in that space we replaced the notion of type indedxes with ShapeTrees that say regardless of the type 12:21:18 ... we want to find ???. In order to provide a somewhat managable service in which applications that didin't know about each other could coordinate 12:21:48 ... we got shapetrees and registries whcih way "for this container, everything in here conforms to this shape" 12:22:09 ... what Aaron said is if you have a particular endpoint and evertyhing you put in here is ??? these resources 12:22:46 ... This doesn't manage multiple containership, so you can't say that this thing is both a recipe and a desert topping. But it does provide an app surface where people can store pictures, X-rays etc. 12:23:30 acoburn: One thing to keep in mind on the container discussion is that we want to be careful about not diverging too far from Solid. If we have 2 ways of doing something that are equivalent, then we should try and go with the Solid way. 12:24:13 bendm: In GDrive you can post to a container, and then also put it in 17 other containers - do we want similar properties. 12:25:13 acoburn: Oh absolutely. If you look at what they do, whenever you get a resource it has a top-level URL. When you move that resource between containers; the URL of the resource does not change. 12:26:22 ... With slash semantics you hit issues e.g. if you give someone access to a resource then if you move between containers then the URL of that resource changes and people with access to individual resources can lose it. 12:26:30 ... If you drop slash semantics we don't have this issue 12:26:50 laurens: Part of the issue is also developers applying implicit semantics to slash semantics that they shouldn't be 12:27:29 ... if you look it from an more abstract level then you could also think of all containers and resources as UUIDs with metadata 12:28:08 bendm: yes this is what gdrive does right. ShapeTrees metadata could be put on the containers here 12:28:36 laurens: You could also have schema metadata attributes on resources which are used to e.g. enforce validation on write of resources. 12:28:48 ... the question here is what semantic restrictions can the metadata impose 12:29:20 bendm: If in v1 we focus on anything like shape validation, VC validation etc. is an optional service - but something that we could add after v1 - then this would be a sound approach 12:29:30 ... another question, should containers have metadata. 12:30:30 laurens: Yes, but this raises an issue. Containers are a special kind of server resources. They contain certain information that must be managed by the server (e.g. containment), users may also desire to add their own user information on the server. 12:30:43 -> https://shapetrees.org/TR/primer/#structure image in ShpaeTrees Primer which gives some intuition 12:31:07 acoburn: Today in Solid a container resource has both a server managed, and user mangaed information. 12:31:25 ... this make it a composite resource. This makes use of e-Tags, and concurrent operations with PUT and POST complicated. 12:32:05 ... Consider a container which has 5 child objects and a dc:title field. If you want to change the dc:title field, and someone else adds a new child object at the same time. 12:32:29 laurens: ESS and CSS both have complex logic to support this 12:32:48 bendm: Can't you have 2 files (server managed and client managed) for write, and a composite one for read 12:33:55 laurens: Yes. But we don't want to semantically mix the two (have a composite) for write operations. 12:34:28 bendm: It seems difficult to have different authorisation rules *within* a resource. So lets not try and have a composite write. 12:34:51 laurens: The finest level of granularity that we should manage access controls on are the resource level. 12:35:00 scribe+ 12:35:31 acoburn: Suppose you only want to give access to certain parts of a resource, it would make sense to split this resource. 12:35:44 ryey: For containers we're not thinking about transitive things? 12:36:32 ... for example container A contains container B which contains resource C. 12:36:50 ... does A then also contain C. 12:37:03 acoburn: Might be simpler to see that as a projection/view on the data. 12:37:08 rssagent, draft minutes 12:37:20 s/rssagent, draft minutes// 12:37:35 rrsagent, draft minutes 12:37:36 I have made the request to generate https://www.w3.org/2025/10/08-lws-minutes.html laurens 12:38:04 bendm: In UMA you have this notion of scopes. You could have authorization rules to apply to certain scopes (groups of resources). 12:38:17 acoburn: Flexibility might make things harder. 12:38:33 ... I would probably have every resource point to some ACL resource. 12:38:52 ... Implementers could choose to have multiple resources point to the same ACL. 12:39:08 ... I wouldn't prohibit that. In general that might hinder extensibility. 12:39:27 ... The simple approach might be the most logical, and other approaches may be allowed. 12:39:42 bendm: If a resource can be part of multiple containers, that might also resolve this. 12:40:01 acoburn: If the container information is part of the metadata of the resource 12:40:28 ... imagine in the simplest server a resource is only part of a single container and you get an error when you change that metadata. 12:40:43 ... In the more complex implementation you could move the data between containers. 12:40:58 ... Even more complicated would be to have multiple contains relations in the metadata. 12:41:09 ... This would open the door without requiring implementers to support this. 12:41:53 acoburn: Let's move to HTTP operations on these conceptual entities. 12:42:06 ... For some we might not care because they are not addressable (e.g. credentials). 12:42:18 ... So how do we approach that for each of these conceptual entities. 12:42:33 ... Let's start with the data resources, these are the simplest. 12:43:51 laurens: Some discussion I still want to have is whether we want to have different protocol bindings (e.g. GraphQL, ...), but let's keep to REST for now. 12:44:36 acoburn: There is this rough structure in the protocol right now, where we might start with these conceptual entities and operations. And then provide a binding to a REST API, other bindings could then potentially follow. 12:46:23 acoburn: For data resources GET (read), DELETE (delete) and PUT (update) might makes sense. 12:46:30 laurens: What about PATCH for updates? 12:47:36 acoburn: I wouldn't prohibit it, but it brings complexity. 12:48:15 laurens: It does again entail additional restrictions on the syntax and semantics of the data contained in the resource. 12:48:28 eBremer: Why don't we at least support a binary patch? 12:49:05 acoburn: We could rely on standard HTTP for this, e.g. the Accept-PATCH header (https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Accept-Patch) 12:54:49 laurens: Atomic updates may be a good use case for the patch operation. But this could be resolved by ETags and the If-None-Match HTTP header on a PUT (https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/If-None-Match) 12:55:09 acoburn: There's three ways to create a resource in Solid, PUT, PATCH or POST. 12:55:18 ... I think we should define one method to do that. 12:57:34 laurens: (chair hat off) We probably should not be imposing anything normative on the contents of data resources. 12:57:53 ryey: But then what about the Linked part in "Linked Web Storage"? 12:58:12 acoburn: This will probably shine in the metadata resources. 12:58:39 ... What about POST for creating resources? 12:59:04 ericP: What about creating a resources in a certain place (PUT) vs letting the server define the location (POST)? 12:59:17 acoburn: What if the server does not allow the user to choose the location? 12:59:54 ericP: PUT is usually lower level than POST. POST delegates that authority to the server. 13:00:51 bendm: If we limit the writer's decision power to put a resource in a certain location, that might be very restrictive. But then we should allow alias creation for flexibility. 13:02:21 acoburn: PUT typically tells the server you must create a resource at a location. POST is more suggestive, it asks the server if it would create a resource at a specific location (which could not happen, and a different location may be chosen by the server). 13:02:29 rrsagent, draft minutes 13:02:30 I have made the request to generate https://www.w3.org/2025/10/08-lws-minutes.html laurens 13:03:15 s/laurens: let's break for lunch, reconvene at 13:30 CEST/topic: Defining core operations of the LWS protocol/ 13:03:22 rrsagent, draft minutes 13:03:23 I have made the request to generate https://www.w3.org/2025/10/08-lws-minutes.html laurens 13:05:48 acoburn: If containment is a metadata property. Imagine you had resources that looked more like google drive, where everything is an opaque string. And the resource containment is (potentially mutable) metadata. You could create a resource in a container (e.g. POST into that container) or at a global location of the storage (and then add metadata 13:05:48 as a request header of where that resource should go). 13:06:07 ... Theoretically they are the same, one of them looks more like what Solid currently is. 13:06:29 ... If we want to do something different from Solid, we should have a good reason. 13:06:40 present+ gibsonf 13:06:59 gibsonf: Suppose writing a resource to a storage is like writing to a named graph. 13:07:16 ... In this case we would have no containers. 13:07:35 acoburn: There's no reason you couldn't do that with what is being discussed. 13:08:27 ... There's a strong set of use cases to group resources in a certain way. 13:08:43 ... The solution to this has historically been containment, and this should likely continue to be possible. 13:11:11 laurens: I think you should indeed try to retain compatibility with Solid, but you should put the authority on resource naming with the server allowing the user to make suggestions (e.g. through a Slug header). This way you can retain compatibility but also have clearer authority of resource identifications with the server. 13:11:37 acoburn: The target resource of a POST would be a container. The target resource of a PUT would be a data resource. 13:12:01 ryey: I cannot thus choose the location of data but just suggest it. 13:12:53 acoburn: This way you could also still support resources that have been created under slash semantics. 13:13:08 eBremer: Does the resource then have to exist? 13:13:15 acoburn: I wouldn't mandate this. 13:15:43 acoburn: Let's move on to containers. 13:16:19 bendm: Have we concluded whether a PUT can create a resource or not? 13:17:04 acoburn: Do we agree that a POST on a container can be used to create a resource. 13:17:07 laurens: I think so. 13:19:07 ... I don't think we should grandfather in slash semantics on new resources. 13:21:51 gibsonf: TrinPod does not have a filesystem. We have a triple which has the path information. 13:23:00 bendm: Then I do think you need an affordance for moving resources. 13:23:43 acoburn: On large file uploads, eBremer has looked into aspects of this. 13:24:07 ... that could be layered on top of this approach in LWS. 13:24:34 Beau has joined #lws 13:25:03 acoburn: So, PUT to create resources... do we strike this or keep it? 13:26:50 acoburn: I think we strike this for now, and we can always put it back in later. 13:27:06 acoburn: Let's continue with containers now. 13:27:38 ... Let's start with a READ on a container. 13:27:46 ... We should consider pagination, content types, ... 13:28:05 ... Do we use HTTP GET for this. 13:28:08 laurens: Agreed. 13:28:40 ryey: Is a slash required then? 13:28:57 acoburn: I haven't seen anything that requires a trailing slash yet. 13:30:28 bartb: How do you then know what a resource is by its URI? 13:30:38 laurens: You can't, a GET or HEAD response should tell you. 13:31:48 acoburn: What with DELETE operations? 13:31:57 ... important here is recursive deletion. 13:33:06 ... Currently we don't have a recursive delete in Solid. 13:33:25 ... This is a developer nightmare, because of manual cleanup. 13:35:42 laurens: Why not have explicit semantics for recursive deletes, and do a non-recursive delete by default. 13:35:53 eBremer: WebDAV has a level header for this. 13:36:05 acoburn: We'll have to come back to recursion. 13:36:29 ... If containers are entirely server managed, there's no update operation. 13:37:20 laurens: And then for the creation I would propose a POST with a type link relation header defining it is a container. 13:38:28 beau: Could you POST to a container that does not exist? 13:38:35 acoburn: No, you would get a 404. 13:38:48 ... With the Solid specification you cannot do that. 13:40:21 acoburn: Now let's proceed to metadata. 13:40:58 ... I think that create and delete are no-ops. Because the lifecycle of the data and metadata resource are tied. 13:41:19 bendm: What about server managed vs client managed metadata. Have we considered that yet. 13:41:22 acoburn: Not yet. 13:42:23 ryey: Are we considering metadata over metadata? 13:42:30 acoburn: I wouldn't. 13:42:43 ryey: What about multiple metadata resources. 13:42:56 acoburn: I would specify any resource must have at least one metadata resource. 13:43:32 ... eBremer has already looked into work on HTTP link sets (https://datatracker.ietf.org/doc/rfc9264/) 13:43:51 ryey: Do metadata have ACLs over it? 13:44:11 acoburn: I would go so far as to say that they are governed by the ACLs of the data resource. 13:44:24 ryey: We have some use cases where this might be differently governed. 13:45:34 laurens: How is this today in Solid? 13:45:46 gibsonf: Today you can have separate ACLs on metadata. 13:50:06 laurens: You could have a metadata resource be a specific type of auxiliary resource governed by the same ACLs and lifecycle as the data or container resource. 13:50:17 acoburn: For the READ of metadata, a GET operation? 13:50:47 ... For the UPDATE operation it would make sense to use a PATCH operation. 13:51:14 ... Another contender might be PUT but this gets complicated with server managed metadata. 13:51:48 ryey: Containment is part of the metadata then? 13:52:11 ebremer: The RFC does not specify anything required about PATCH for link sets. 13:55:29 acoburn: For updates on the ACL, what do we do there? Both PUT and PATCH could work 13:55:34 bendm: Let's park that for now. 13:56:00 ... And what about ACLs on ACLS, 13:58:43 laurens: We have to watch out that we aren't getting ahead of ourselves in terms of authorization. 14:10:39 present+ 14:11:37 scribe+ 14:12:00 gibsonf1 has joined #lws 14:12:05 present+ 14:12:33 rrsagent, draft minutes 14:12:34 I have made the request to generate https://www.w3.org/2025/10/08-lws-minutes.html laurens 14:13:36 i/Defining core operations of the LWS protocol/scribe: jeswr/ 14:13:54 > rrsagent, draft minutes 14:13:58 rrsagent, draft minutes 14:14:00 I have made the request to generate https://www.w3.org/2025/10/08-lws-minutes.html laurens 14:14:07 s/> rrsagent, draft minutes// 14:14:30 i/topic: Defining core operations of the LWS protocol/scribe: jeswr/ 14:14:39 rrsagent, draft minutes 14:14:40 I have made the request to generate https://www.w3.org/2025/10/08-lws-minutes.html laurens 14:15:19 i/[laurens presents site logistics]/scribe: ericP/ 14:15:23 rrsagent, draft minutes 14:15:25 I have made the request to generate https://www.w3.org/2025/10/08-lws-minutes.html laurens 14:18:05 topic: Scope of Query in LWS 14:18:18 laurens: Now we are at the last part of today. My opinion is that LWS shouldn't know the contents format of the data. That means, we shouldn't query on the content of the data. Or maybe we want? Worth discussing that, including indexing, shape trees, etc. 14:19:02 bendm: I feel that if we agree as a group, if we excluded patch based on content type, we should do the same for query. 14:19:10 laurens: yes indeed 14:19:27 bendm: so that's mainly a question of consensus 14:19:55 ... I want that, but it doesn't necessarily be in the protocol. 14:20:16 acoburn: yes, supporting mechanism to allow that, but not mandate. 14:20:56 gibsonf1: we are now having issue with searching in thousands of thousands of pods. we can do permission scoped query on server. 14:21:13 rrsagent, draft minutes 14:21:15 I have made the request to generate https://www.w3.org/2025/10/08-lws-minutes.html laurens 14:21:23 bendm: so ACL is separate from search / query service, right? 14:22:15 bartb: so it's actually based on the types of data, right? E.g., for medication, it may related to metadata as well 14:22:39 laurens: we may want to specify what is contained in the metadata tomorrow 14:23:11 acoburn: so for bendm's point, having "query over resource content" is out of the scope of the protocol itself, right? 14:23:53 bendm: the query doesn't need to be in the base protocol. from gibsonf1's case, is querying by types supported, even if not the data content query? 14:24:23 gibsonf1: no. In our view, metadata and data content are the same thing. If you prevent one, you prevent both. 14:25:09 ... e.g. for genetic search, finding all patients of a certain criteria require accessing the data content 14:26:03 acoburn: the question is that should *all* services support querying over the data. The query can be efficient, but that's not the question now. 14:26:44 eBremer: I can have metadata about shape, content, type, etc of a data. Is that metadata resource? 14:27:34 gibsonf1: you have enormous information about a patient, e.g. their age, etc. They are not metadata, at least I don't think so. You need to search across them. 14:28:05 eBremer: we need to delineate. ... DIECON (?) is a format, but that's different 14:28:50 gibsconf1: I don't care about the format. I'm concerned about the actual information contained. So, I care about content search, because those information will be needed in our case 14:29:02 s/gibsconf1/gibsonf1/ 14:29:45 acoburn: with my chair hat on, we are specifying things that apply to all servers. Some things can be addons, and we don't have to support that, due to resoruce and time constraint 14:30:29 gibsonf1: On that, I support. But I hope we can specify the capability of the search, so services can specify the capabilities, to improve interoperability. Something like a scheme. 14:31:08 acoburn: we didn't get to the "storage-level metadata" earlier. Let's assume we can get to that tomorrow. 14:31:50 ... In Solid spec, it has some storage metadata, e.g. controlled identifier document 14:33:05 ... if we want to use that, it's basically an array of services. E.g. one particular service is of a certain type, e.g. query service. Then, you go to the URI of that service, to access that type of service. 14:33:22 laurens: yes, we could have a separate working group specifying that, if needed 14:33:52 acoburn: yes. and here, we only need to specify what services and where they are. 14:34:06 gibsonf1: how about we define a "must" list of services as well 14:34:46 laurens: yes. i don't like in some communities to define some extension points, but they are not really used in their specification in the end 14:35:12 ... I hope we can eat our own dog food. if we specify something, we use that. And, again, yes, fully agree 14:35:34 acoburn: how about defining as "can a service live without a part of these services"? 14:36:16 laurens: I would counter that. we are talking about query and data. i wouldn't have a generic "data discovery" service. But we should have a authorization service, etc. 14:37:15 acoburn: I'm not saying only these three. But these three are main ones. Todays, there is a lot of uses of Type Indexes (for RDF), especially client-managed ones, likely to be compromised. It's great to move it to server to make it authoritative. 14:37:32 ... I'm saying Type Indexes becasue it's typical. 14:38:01 gibsonf1 has joined #lws 14:38:01 Beau has joined #lws 14:38:01 ryey has joined #lws 14:38:01 Wonsuk6 has joined #lws 14:38:01 wonsuk has joined #lws 14:38:01 bendm has joined #lws 14:38:01 laurens has joined #lws 14:38:01 starl3n has joined #lws 14:38:01 bartb has joined #lws 14:38:01 ericP has joined #lws 14:38:01 eBremer has joined #lws 14:38:02 ... where does it belong? 14:38:22 laurens: it may be on the boundary between data and authorization. Let's reserve for tomorrow. 14:38:52 ... the word "authorization server" is overloaded, e.g. OIDC, etc. Better to give it another name. 14:38:58 bendm: let's do it tomorrow. 14:39:42 acoburn: one more on this. assuming a legitimiate type is server managed. you can legitimately say "give me the list of containers / resources" 14:39:59 ... because you have a token and server-managed. You can easily say that. 14:40:20 bendm: now TI in Solid is on RDF type, and pretty public. 14:41:16 acoburn: If type is included... if the metadata resource contains some server-managed type (e.g. it's a container), and some user-managed type (e.g. a uri representing a photo albumn). you can look up that on a given service. 14:41:41 ... the amount of data that have such types is rather limited, so not significant burden for serve. 14:42:10 bendm: if user managed types, will there be a jumble of types, e.g. some say "photo", some say "image" 14:43:01 laurens: but that at least solves the issue of what people use directory layout for 14:43:23 bendm: yes, but just to worry about the potential of having a lot of such cases of "photo" or "image" 14:43:57 acoburn: that saves different apps to find the resource. It supports interop in fact. 14:44:40 gibsonf1: we have server using a general ontology type... it's extremely powerful to search based on that 14:44:55 bendm: I can imagine that, definitely 14:45:19 ... do we need to support server types that you must support? And MIME types? Or is that too much detail? 14:45:33 acoburn: I think we can start with that. 14:45:54 laurens: we may get to that tomorrow 14:46:05 rrsagent, draft minutes 14:46:06 I have made the request to generate https://www.w3.org/2025/10/08-lws-minutes.html laurens 14:46:18 bendm: this would allow you to create services to do what gibsonf1 was discussing, right? 14:46:39 ... you have an index, and you can pull that within your own query service, right? 14:46:55 ... Is it on service level, or storage level? 14:47:26 acoburn: well... implementation is in service level, definitely. the pointer to those services should be on storage / pod level. 14:47:45 ... you may want to support multiple services of the same type. 14:48:47 bendm: I'm worried the service provider will force you to use a particular service for a particular type 14:49:50 bendm: the CID is in service level, right? 14:50:02 acoburn: I would imagine that. But we may allow flexibility 14:50:19 ... e.g. one being storage type index, one being federated type index 14:50:58 laurens: e.g. metadata is RDF LD. TI could be everything with predicate `rdf:type`. That's a simple solution. 14:51:53 ... simple solutions would try all things. Complicated solutions may consider more. But not that complicated in the end, because they are governed by the same ACLs 14:51:54 q? 14:52:06 bendm: does that have any effect on writing side? 14:52:37 ... you can imagine services for data validation. Where should I post data to, if TI is considered? 14:53:04 laurens: you can have additional metadata triples, as a simpliest solution. 14:53:05 q+ 14:53:22 bendm: or you want the service to do server-managed metadata 14:53:47 acoburn: there are some existing specs we might want to build on 14:54:17 q- 14:54:48 jeswr has joined #lws 14:54:51 present+ 14:55:29 jeswr: e.g. Inrupt has QPF endpoint, with named graph. For metadata, is there something we can easily access the metadata? E.g. as named graphs? 14:55:50 ... for query over resource metadata 14:56:32 acoburn: we may want to clarify that metadata query here is specifically about the metadata of the same data. 14:56:52 some recent blog post of my colleague Pieter Colpaert on graphs and semantics etc https://pietercolpaert.be/linkeddata/2025/09/30/named-graphs 14:57:10 jeswr: still for QPF, if I do a xxxxxx query, what would be the result? 14:58:10 acoburn: ESS use named graph is because the subject doesn't have to be in the same location as it is, which can lead to overrides. Here, metadata is about a particular resource, which likely doesn't have the same issue -- you can simply rely on the subject. 14:58:36 jeswr: so all metadata is in default graph response from servers? 14:59:05 acoburn: we are discussing something never existed before. we are discussing how it should implement 14:59:41 jewsr: QPF has an endpoint of named graphs. When you think of all RDF graphs in a Pod, it's just named graphs on the Web. I'm just trying to think what the meaning of this is. 15:00:22 gibsonf1: I see each pod is a graph, with resources potentially somewhere else. So putting named graphs into the graph doesn't make sense, if the pod is already a named graph 15:00:56 bendm: if you put it in that way, it may be quite problematic...? not something we can figure out in the next 15 min. Maybe worth discussing that later with use cases. 15:01:28 acoburn: it's easier to think from servers if you have VC, then you have named graph inside named graph, which is a violation. Or you have to figure out how that works. 15:01:49 ... If you want to index that, you need to figure out how to do it. 15:02:27 bendm: before concluding, gibsonf1, does it allow querying over content of resources already, or do you need more? 15:04:11 gibsonf1: on search, we already support billions of triples. currently you specify which service you search, and then the permission check. we want to have a service that first checks who you are. But maybe for SPARQL, it's not a good idea. At lesat for TI, we don't do it, we just want to know what types are there, so we can quickly find them. 15:04:30 acoburn: there are types of queries that cannot be satisfied with TI. I'm fine with that 15:04:55 ... we want to figure out today which of these should be required 15:05:13 bendm: I think you can do these queries with TI 15:05:27 ... gibsonf1, do we need more? 15:05:34 dmitriz has joined #lws 15:05:49 gibsonf1: Apart from TI (or, type search), we need at least paging 15:06:15 laurens: I would call "metadata property index" or something else, rather than type index. 15:07:10 acoburn: sure. using TI is just for easy understanding. 15:07:11 ... So TI is a must, querying over resource content is optional, and query over resource metadata is in limbo. 15:07:24 s/is in limbo./is in limbo?/ 15:07:42 jeswr: I don't think TI should be must; we shall develop more docs for that 15:08:10 bendm: cccc ... we need something else, but something to start building TI is a must 15:08:23 gibsonf1: something to build predicate type? 15:08:40 ericP: TI is what the world can see? 15:08:48 acoburn: no, only what a particular agent can see 15:09:38 ... you have access control for only a container, with different types, you'll get result 0 15:09:54 ericP: so everyone enters will get a different result? 15:10:29 laurens: yes. It's easier than to allow arbitrary queries with ACL 15:10:33 ... at least 15:10:49 ... you can apply cache, etc 15:11:02 acoburn: so do we agree TI is a must for ACL rules? 15:11:26 ... any objections? 15:11:30 ... no 15:11:46 ... query over resource content is out of scope, but not prohibited 15:11:57 yes 15:12:01 ... yes 15:12:26 ericP: clarification: is that for a specific API for metadata, or general? 15:12:52 ericP: about what's expressed in the query, for querying over metadata 15:13:15 acoburn: I want to be high-level, rather than details. we want to know what should be included, and later the mechanism 15:13:35 acoburn: for querying over resource metadata, skip? 15:13:44 laurens: put it as "may" 15:13:57 ericP: nnn? 15:14:30 gibsonf1: e.g. someone has 50m things, here is the place you can search, how to do that? 15:14:38 ericP: you are exploiting the server capabilities 15:15:07 gibsonf1: you want to do that, is on the implementation side. You can't have authorization and search being completely separate, otherwise too inefficient. 15:15:21 s/ericP: nnn?/ericP: do you mean for the off-resource-server authorizatin? 15:15:46 acoburn: we don't want to discuss ACL today for TI 15:17:32 https://tinyurl.com/2mx262z8 15:17:39 rssagent, draft minutes 15:18:30 Google drive with slides & pictures: https://tinyurl.com/2mx262z8/ 15:18:36 rssagent, draft minutes 15:18:49 s/rssagent, draft minutes// 15:18:55 rrsagent, draft minutes 15:18:56 I have made the request to generate https://www.w3.org/2025/10/08-lws-minutes.html laurens 15:19:38 acoburn has left #lws 15:37:31 acoburn has joined #lws 15:37:37 acoburn has left #lws 15:47:08 TallTed has joined #lws