13:55:37 RRSAgent has joined #lws 13:55:42 logging to https://www.w3.org/2025/08/25-lws-irc 13:55:42 Zakim has joined #lws 13:56:01 meeting: Linked Web Storage WG 13:56:22 agenda: https://www.w3.org/events/meetings/a19ab7dc-1753-433d-bac5-64e3ad8c0a43/20250825T100000/ 13:56:22 clear agenda 13:56:22 agenda+ Introductions and announcements 13:56:22 agenda+ Action Items 13:56:22 agenda+ Continued -> clarification https://w3c.github.io/lws-ucs/spec/#requirements of requirements (from -> Auditable Trail https://w3c.github.io/lws-ucs/spec/#dfn-auditable-trail ) 13:56:52 TallTed has changed the topic to: meeting: Linked Web Storage WG -- 2025-08-25 agenda: https://www.w3.org/events/meetings/a19ab7dc-1753-433d-bac5-64e3ad8c0a43/20250825T100000/ 14:00:20 eBremer has joined #lws 14:00:38 present+ 14:00:44 present+ 14:00:51 zakim, start meeting 14:00:51 RRSAgent, make logs Public 14:00:53 please title this meeting ("meeting: ..."), acoburn 14:01:06 meeting: Linked Web Storage WG 14:01:09 present+ 14:01:12 I have made the request to generate https://www.w3.org/2025/08/25-lws-minutes.html TallTed 14:01:19 present+ 14:01:19 RRSAgent, make minutes 14:01:20 I have made the request to generate https://www.w3.org/2025/08/25-lws-minutes.html acoburn 14:01:48 jeswr has joined #lws 14:01:56 present+ 14:01:57 chair: acoburn 14:01:58 chair: acoburn 14:01:59 present+ 14:02:19 Jackson has joined #lws 14:02:22 present+ 14:02:25 previous meeting: https://www.w3.org/2025/08/18-lws-minutes.html 14:02:25 next meeting: https://www.w3.org/2025/09/01-lws-minutes.html 14:02:48 dmitriz has joined #lws 14:02:54 I have made the request to generate https://www.w3.org/2025/08/25-lws-minutes.html TallTed 14:03:08 Scribing 14:03:10 scribenick: Jackson 14:03:40 zakim, open agendum 1 14:03:40 agendum 1 -- Introductions and announcements -- taken up [from agendabot] 14:04:11 present+ 14:05:03 ac: Slightly smaller group because it's august people are on vacation. AC is still in catchup mode. 14:05:37 ac: Lawrence sent out a message about face-to-face meeting. There's an RSVP link. Could people remember to RSVP so he knows how many people to account for. 14:05:41 s/ac:/acoburn:/ 14:06:16 s/ac: Slightly/acoburn: Slightly/ 14:06:27 I have made the request to generate https://www.w3.org/2025/08/25-lws-minutes.html TallTed 14:06:35 zakim, open agendum 2 14:06:35 agendum 2 -- Action Items -- taken up [from agendabot] 14:07:18 ac: The only action item is related to use cases. But, there aren't any new ones this week. If anyone knows of new requirements let me know. (no one has any) 14:07:57 s/ac: The/acoburn: The/ 14:08:31 laurens has joined #lws 14:08:32 acoburn: Please type out the full acoburn 14:08:38 present+ 14:08:52 zakim, open agendum 3 14:08:52 agendum 3 -- Continued -> clarification https://w3c.github.io/lws-ucs/spec/#requirements of requirements (from -> Auditable Trail 14:08:52 TallTed: Tab completion does work (I have confirmed it does) 14:08:54 ... https://w3c.github.io/lws-ucs/spec/#dfn-auditable-trail ) -- taken up [from agendabot] 14:09:22 acoburn: The next requirement is "Auditable Trail" 14:09:23 s/TallTed: Tab/TallTed -- Tab/ 14:09:28 -> https://w3c.github.io/lws-ucs/spec/#dfn-auditable-trail Auditable Trail 14:10:07 acoburn: We want to focus on clarifying the requirements rather than rabbit holes on the solution. We could possibly finish today. 14:10:41 s|-> https://w3c.github.io/lws-ucs/spec/#dfn-auditable-trail Auditable Trail|subtopic: -> https://w3c.github.io/lws-ucs/spec/#dfn-auditable-trail Auditable Trail 14:11:22 acoburn: The requirement is to access an auditable log of access requests. Specifically about auditablity of access requests and grants. It also includes auditability of resources being created, modified, or deleted. 14:11:37 q+ 14:11:37 acoburn: How much should be part of the HTTP API, and how much should be internal details? 14:11:37 ack next 14:11:39 ryey has joined #lws 14:11:42 present+ 14:12:09 dmitriz: It's 99% internal details, but the API should expose a link to the auxilary resource. We need a way to discover the auditable log, but everything else is internal 14:12:27 acoburn: Would it be required that an auditable log is available, or would that be an extension. 14:12:35 q+ 14:12:36 dmitriz: No. 14:12:38 +1 dmitriz 14:12:47 hadrian has joined #lws 14:12:53 present+ 14:12:53 dmitriz: Most of it would be internal. 14:13:40 dmitriz: One is a log of http requests, and the other is a log of what agents have requested. These are different. 14:14:32 acoburn: There was earlier work in combining audit-related requirements. We might want to split it into one requirement related to access requests and another one that is a part of an extension that has to do with logging resource creation/modification etc. 14:14:33 sounds good to me 14:14:37 +1 to split them 14:14:55 acoburn: Someone to open a PR to split those? 14:14:59 +1 to split out audit logs for permission delegation and audit logs for resource acces 14:15:13 hadrian: I would open it, but could you clarify the request 14:16:07 acoburn: Right now there's an auditable trail requirement but it has two portions: accesing logs of grants, and the other is about logs of modifications to resoruces. The first is more akin to what should be available on an HTTP API, and the other is about an internal audit log that would not be a part of a core requirement. 14:16:13 q- 14:16:16 acoburn: Move on to "8: Data Sharing" 14:17:34 acoburn: If I'm a storage owner and I want to get read/write access to a thrid party. 14:17:51 +1, does seem fairly core\ 14:17:54 acoburn: Seems like something very core to LWS 14:17:54 _1 14:17:56 +1 14:17:56 _1 14:18:05 +1 :P 14:18:10 q+ 14:18:11 +1 14:18:17 ack next 14:18:34 q+ 14:18:37 ryey: I want to ask for verification: Does this only involve reading/writing rather than "control?" 14:18:56 ack next 14:18:56 acoburn: I would say this has to do with granting some kind of access. I don't think we even need to define the kind of access. 14:19:34 dmitriz: I think it's fine as is. But, to give more details I'd like to add "grant access to known parties" and "access to unknown parties. Ex: anyone with a link can..." 14:19:48 acoburn: Dmitri, can you edit the requirement. 14:19:51 q+ 14:19:57 q+ to make a meta request that both `Issues` and `Stories` be styled to have "open spacing" (i.e., blank line above them). Currently, only `Issues` do, so if there's no `Issues` paragraph, `Stories` are right below the UC summary. 14:20:18 dmitriz: Yes, what's the procedure. Should I go the issues, or should I make a modification to the document directly. 14:20:22 ack next 14:20:31 acoburn: Make an edit to the document directly 14:20:54 hadrian: To clarify, when you say "everyone with a link" do you mean everyone authenticated or do you also include non-authenticated people 14:21:00 dmitriz: Both are useful for both 14:21:08 hadrian: That goes into audit trails 14:21:22 dmitriz: It does so we'd need to handle that. 14:22:45 dmitriz: Because creating an account is trivial, there's no difference between an IP address in the access log and a random username in the access log, so I don't see the difference. 14:24:05 acoburn: The high level point is we want two axies of data sharing: by identity or by capability. But, we don't need to go into the details now 14:24:12 ack nex 14:25:17 TallTed: You should see a use case the flows into stories if you scroll up or down. If you look at #5, I think it will be better to have a blank line. It will visually separate issues and stories. 14:25:30 s|https://w3c.github.io/lws-ucs/spec/#dfn-auditable-trail|https://www.w3.org/TR/2025/DNOTE-lws-ucs-20250804/#dfn-auditable-trail 14:25:37 acoburn: That will help folks read this. Hadrian, could you make a PR for it? 14:25:41 hadrian: Absolutely 14:25:57 q? 14:26:01 ack next 14:26:01 acoburn: Next Topic: "#7 adding Adding Updating and Deleting Resources" 14:26:03 TallTed, you wanted to make a meta request that both `Issues` and `Stories` be styled to have "open spacing" (i.e., blank line above them). Currently, only `Issues` do, so if 14:26:03 ... there's no `Issues` paragraph, `Stories` are right below the UC summary. 14:26:25 s|acoburn: Move on to "8: Data Sharing"|subtopic: -> https://www.w3.org/TR/2025/DNOTE-lws-ucs-20250804/#dfn-data-sharing Data Sharing 14:27:03 s|acoburn: Next Topic: "#7 adding Adding Updating and Deleting Resources"|subtopic: -> https://www.w3.org/TR/2025/DNOTE-lws-ucs-20250804/#dfn-adding-updating-deleting-resources-in-storage Adding Updating and Deleting Resources 14:27:42 Eric: Things to think about: Do we want to delete many files with a single deletion? Do we want a more command (for a version 1 spec they would be for the same server). It would be interesting to have things between servers, but that gets complicated. Do we want copy move with append? 14:27:43 q+ 14:27:47 ack next 14:28:00 TallTed: I ask that you capture that in an issue so we don't forget it. 14:28:25 I'm certainly a fan of the http COPY command, at very least. (I proposed it for solid, way back in the day, and implemented it in life-server). 14:28:26 Eric: Yes, I'll take care of it. 14:28:37 Worth adding #171 to this requirement 14:28:38 Issue 171 not foundacoburn: 14:28:42 acoburn: What do people think about #7? It seems core 14:28:50 acoburn: No comments, so we can move on. 14:29:03 acoburn: Next topic: #6 data portability 14:29:22 acoburn: Are there clarifications to this requirement that help us prioritize it? 14:29:30 s|acoburn: Next topic: #6 data portability|subtopic: -> https://www.w3.org/TR/2025/DNOTE-lws-ucs-20250804/#dfn-storage-portability Storage Portability 14:29:52 s/Eric:/Erich: 14:30:05 dmitriz: I'm not sure the last sentence makes sense. The export and import part and portability of the data model is the point. What happens to the provider complicates it. 14:30:11 "everything moves, with same permissions" is relatively easy. "links still work" is hard. 14:30:15 acoburn: Are there any concerns about removing the last sentence? 14:30:53 TallTed: The last sentence might imply that the original storage provider is not responsible for redirect URIs, but it is a valuable ongoing service. 14:31:06 acoburn: Is that going to be a requirement or will it be optional? 14:31:22 q+ 14:31:27 TallTed: I think optional is the way to go, but I think we should talk about whether or not it's required. 14:32:00 ack next 14:32:06 acoburn: We'll have a set of requirements in the spec, but we'll also have sections on "portability considerations" or "security considerations," and this might make it into "portability considerations" 14:32:54 dmitriz: I wanted to add a clarifying datapoint. When we discuss data porability in the social web working group. We differentiate between portability between living servers and dead servers. Different solutions apply for dead servers. 14:33:38 acoburn: Certain kinds of URI structures could provide portability automatically. There are considerations there. Things like WebVH might provide protability in the URI itself, whereas a plain URL would require the interaction of different servers. 14:33:59 acoburn: Is there more to discuss on storage portability? 14:34:13 acoburn: Next Topic: #5 Transfer of Control 14:34:38 correct 14:34:48 acoburn: This is about taking an existing storage with an entity that controls that storage and reassigning it to some other entity. 14:34:49 As written, that looks like "transfer of ownership" 14:34:53 s|acoburn: Next Topic: #5 Transfer of Control|subtopic: -> https://www.w3.org/TR/2025/DNOTE-lws-ucs-20250804/#dfn-transfer-of-control Transfer of Control 14:34:55 q+ "transfer" and "dual-ownership" 14:35:20 q- "transfer" and "dual-ownership" 14:35:21 q+ 14:35:28 ack next 14:35:30 q+ 14:35:31 I'd disagree - ownership is orthogonal to control 14:35:32 TallTed: That sounds like transfer of ownership. 14:35:40 (ownership involves weird legal considerations, whereas control doesn't quite) 14:36:17 ryey: I don't remember if there's a requirement talking about multiple ownership or control of the same storage. Therefore, for this item that only allows transfer rather than allowing for two different entities having control over the same storage 14:36:46 (we definitely want to avoid weird legalities where we can, but... maybe this case requires clever definitions no matter what else is involved) 14:36:52 acoburn: We'll get to "each storage should have one controller" in a moment. Those all relate to the question you're asking. 14:36:57 ack next 14:37:52 hadrian: For Ted: Yes Ted, there was a discussion about verbage. We chose "control" because "ownership" is nebulous. For Ryey: Control may have to be one entity that could be a group. 14:38:07 my proposal with this is - we completely avoid the 'owenrship' term. and just use control. (and don't restrict it to just one entity) 14:38:10 q+ 14:38:38 q+ 14:38:41 yes, for example, Data Integrity keys used to have an 'owner' field, way back, in the first iteration 14:38:47 acoburn: There are other specs in W3C land that have addressed this issue of "ownership" vs "control." Does anyone know which ones have worked through this issue and where they landed? 14:39:00 but it got changed to 'controller' 14:39:10 TallTed: Unix-like operating systems refer to "owner" and not "control" 14:39:14 ack next 14:39:45 TallTed: When designating "owner" or "controller" the best practice would be to use a URI and that URI could be an individual, or a group, or any other kind of agent. 14:39:46 I agree, no reason to differentiate groups vs individuals 14:40:24 Ownership *can be* a legal term. It's not guaranteed to be. 14:40:54 dmitriz: Ownership is a legal term which is different in every jurisdiction. Control has an authorization/access control definition. I strongly recommend saying "controller" instead of "owner." Data integritiy key serialization used to have an owner field, but it got changed to controller. 14:41:02 An interesting read on the notion of "data ownership" https://doi.org/10.1007/s13347-020-00404-9 14:41:39 acoburn: We will need to sort this out more formally, but I will open an issue about clarifying that terminology. 14:41:40 q? 14:41:43 ack next 14:42:30 hadrian: I'm neutral to which term we use. The discussion did take place before in the Control Identifier group. This is not about data ownership it's about control of storage. So, we should make a decision as quickly as possible. We understand the same thing, it's just choosing the right word. 14:43:05 acoburn: Any other conversation for "transfer of control" and what it means as a requriement? 14:43:18 acoburn: Next Topic: "Delegation of Control" 14:44:04 s|acoburn: Next Topic: "Delegation of Control"|subtopic: -> https://www.w3.org/TR/2025/DNOTE-lws-ucs-20250804/#dfn-delegation-of-control Delegation of Control 14:44:06 acoburn: Should 3, 4, and 5 be combined into a single requirement with sub-topics? Any preference? 14:44:46 acoburn: Next Topic: "Control of Storages" 14:45:00 I'm curious about the 'exactly one' restriction 14:45:03 why did it come about 14:45:10 acoburn: This says and entity should control one or more storage and that a storage should only have one controller 14:45:24 dmitriz: Where did the exactly one restriction come from? 14:45:49 eBremer: It came from Hadrian 14:46:28 "exactly one controller" can make sense *if* a controller identifier can denote a group/list. 14:46:45 again, consider Unix-like filesystems 14:46:59 hadrian: The first part is self evident. For the exactly one restriction, it's about how you model a controller. It's much easier if storage has one controller. If that controller is more than one entity (like a group) the composition of the group can be managed separately without the control of the storage being changed. 14:47:20 dmitriz: I think it makes sense, but I'm not sure the restriction is necessary. It could be implementation details. 14:47:26 s|acoburn: Next Topic: "Control of Storages"|subtopic: -> https://www.w3.org/TR/2025/DNOTE-lws-ucs-20250804/#dfn-control-of-storages Control of Storages 14:47:46 hadrian: If you don't do that then servers CAN have multiple controllers and that complicates things. Making it a requirement simplifies the implementation effort. 14:47:56 dmitriz: I think it presumes implementation details. 14:49:12 acoburn: If we have a restriction in place we need a rationale as to why that restriction is there. I would say "A storage must have at least one controller" rather than "only one controller" 14:49:36 acoburn: I feel like removing the last line or changing it somehow might be good. 14:49:52 hadrian: Can there be an entity with no controller? Oh at least one 14:49:53 q+ 14:50:01 ack next 14:50:07 scribe+ 14:50:21 Jackson: hadrian, can you give examples of how multiple controllers make things complicated? 14:50:32 to me, that's just like saying "a storage should only have one user account". why not multi-user servers? well, those are more complicated. 14:50:37 I have made the request to generate https://www.w3.org/2025/08/25-lws-minutes.html TallTed 14:50:45 so it's like, yes, of course multi user is more complicated. but there's no reason for the spec to restrict that 14:50:56 s/Scribing// 14:51:23 hadrian: Think of how the implementation is going to go. If there are more controllers, how are they represented? A list, rows, legal entities? But, I'm not clinging to it. I thought this was a better way to do it. I thought this was a simplification. 14:52:00 I have made the request to generate https://www.w3.org/2025/08/25-lws-minutes.html TallTed 14:52:10 yes, we're specifically saying - 'controller' property should be an array, optionally 14:52:23 q+ 14:53:06 hadrian: If you implement it the way I thought as a group, then it's kind of like delegation. In a way. 14:53:37 ack next 14:53:44 Jackson: I can see how multiple controllers can "compete" when changing things. Having a group as a single owner seems to have the same complexity. 14:54:03 +q 14:54:31 q+ for "Storage" only, or also "Resource"? 14:54:32 acoburn: I think at this requirement stage, we should avoid this level of restriction. When we get to the point of drafting text, we can add certain clarifications. I think it would be better to strike the last sentence or change it to "as storage should at least have one controller." 14:54:35 q- 14:54:37 hadrian: I'll create a PR for it. 14:55:01 q? 14:55:04 ack next 14:55:05 ryey, you wanted to discuss "Storage" only, or also "Resource"? 14:55:09 scribe- 14:55:37 ryey: I just scrolled down the list of requirements. There's only mentioning the controller of the storage and not the controller of the resource. That implies that the controller of the storage is the same as the controller of the resource always. 14:56:23 acoburn: This gets into the question of how the authorization system works. Is it heirarchical? Is it some other system? At the storage level, we want to be sure there is a controller of a storage overall. It implies that you also control the resources in the storage. 14:57:18 q+ 14:57:25 acoburn: Could you, ryey, open a new issue or add a comment to the existing issues asking the question "does control of a storage imply control over the resources of that storage?" 14:57:31 ack next 14:57:47 acoburn: We'll defer the last two to next week? 14:58:54 ryey: One possible authorization mechansim, SAI, uses an agent that modifies the authorization. That agent is not the controller of the storage. So, that's an example where there's a difference. 14:59:05 acoburn: Let's continue the discussion in the issues. 14:59:09 RRSAgent, make minutes 14:59:10 I have made the request to generate https://www.w3.org/2025/08/25-lws-minutes.html pchampin 15:00:03 Zakim, end meeting 15:00:03 As of this point the attendees have been acoburn, TallTed, pchampin, eBremer, jeswr, Jackson, dmitriz, laurens, ryey, hadrian 15:00:05 RRSAgent, please draft minutes 15:00:07 I have made the request to generate https://www.w3.org/2025/08/25-lws-minutes.html Zakim 15:00:12 I am happy to have been of service, pchampin; please remember to excuse RRSAgent. Goodbye 15:00:13 Zakim has left #lws