13:56:03 RRSAgent has joined #lws 13:56:08 logging to https://www.w3.org/2025/10/20-lws-irc 13:57:13 laurens has joined #lws 13:57:25 acoburn has joined #lws 13:57:26 agenda: https://www.w3.org/events/meetings/a19ab7dc-1753-433d-bac5-64e3ad8c0a43/20251020T100000/ 13:57:27 I have made the request to generate https://www.w3.org/2025/10/20-lws-minutes.html TallTed 13:57:30 clear agenda 13:57:30 agenda+ Introductions and announcements 13:57:30 agenda+ Summary of face-to-face meeting 13:57:30 agenda+ Discussion of meeting outcomes 13:57:30 agenda+ Next steps 13:57:39 chair: laurens 13:57:43 present+ 13:58:20 present+ 14:00:38 eBremer has joined #lws 14:00:46 RazaN has joined #lws 14:00:53 previous meeting: https://www.w3.org/2025/10/10-lws-minutes.html 14:00:53 next meeting: https://www.w3.org/2025/10/27-lws-minutes.html 14:01:17 AZ has joined #lws 14:01:23 present+ 14:01:26 I have made the request to generate https://www.w3.org/2025/10/20-lws-minutes.html TallTed 14:01:32 present+ 14:01:33 present + 14:01:58 s/present +/present+/ 14:02:00 gibsonf1 has joined #lws 14:02:06 present+ 14:02:37 ericP has joined #lws 14:02:57 present+ 14:03:03 present+ 14:04:20 jackson has joined #lws 14:04:20 present+ 14:04:24 scribe: jackson 14:05:00 next agendum 14:05:23 Zakim has joined #lws 14:05:28 zakim, next agendum 14:05:28 I see nothing on the agenda 14:05:41 s/next agendum// 14:05:58 agenda: https://www.w3.org/events/meetings/a19ab7dc-1753-433d-bac5-64e3ad8c0a43/20251020T100000/ 14:05:58 clear agenda 14:05:58 agenda+ Introductions and announcements 14:05:58 agenda+ Summary of face-to-face meeting 14:05:58 agenda+ Discussion of meeting outcomes 14:05:58 agenda+ Next steps 14:06:04 Zakim, next item 14:06:04 agendum 1 -- Introductions and announcements -- taken up [from agendabot] 14:06:17 laurens: 1st agenda point - Introductions and announcements 14:07:13 meeting: Linked Web Storage WG meeting 14:07:15 I have made the request to generate https://www.w3.org/2025/10/20-lws-minutes.html TallTed 14:07:22 laurens: From my end, daylight savings time starts in Europe this weekend, so next Monday's meeting on the 27th will be 1 hour earlier for europeans. 3 central european rather than the usual 4pm. This is over next week, so all meeting times in the w3c calendar are correct, so look there for the event date 14:07:39 zakim, next item 14:07:39 agendum 2 -- Summary of face-to-face meeting -- taken up [from agendabot] 14:08:06 Beau has joined #lws 14:08:10 present+ 14:08:29 laurens: Next agenda item: 2 weeks ago was the face to face meeting in Ghent. Lots of people were there. Thanks for joining us. We had productive discussions on the next steps, and Aaron has prepared a summary of what was discussed. All the work was brought together into a github PR. 14:09:01 https://github.com/w3c/lws-protocol/pull/41 14:09:01 https://github.com/w3c/lws-protocol/pull/41 -> Pull Request 41 Oct 2025 Meeting outcomes (by acoburn) 14:09:17 present+ timbl, eBremer 14:09:24 I have made the request to generate https://www.w3.org/2025/10/20-lws-minutes.html TallTed 14:09:30 timbl has joined #lws 14:09:30 acoburn: There's a PR 41. This isn't to put everything into a normative specification. It's documenting and making concrete things we talked about. I'm going to share my screen to show it off. 14:10:11 present+ hadrian 14:10:19 acoburn: There are 3 or 4 main categories: The first is about a few core elements. This will help clarify where the group goes and how we can identify and specify specific interactions and operations by first identifying what are the core entities in the ecosystem 14:10:32 acoburn: We consider scalability, security, interop, and dev experience. 14:11:09 acoburn: We want to make it simple while achieving the requirements and goals we have for this group. It's not very different from what you've seen in Solid. But, we'll go over the abstract items 14:11:20 hadrian has joined #lws 14:11:29 present+ 14:11:43 present+ 14:12:04 acoburn: There's storage, it has metadata. Inside the storage is data resources and containers resources (which can contain other containers and data resources). Everythign in there has one or more metadata resources. Data resources and containers have metadata. all Metadata points to the storage metadata resource. 14:12:21 q+ to ask about container vs storage overall 14:13:32 acoburn: Something not seen in Solid today, but is in a lot of implementations is this concept of a "service." It's a service that acts on the data in your storage. Maybe it acts on your behalf. One example would be a "type index" or maybe a "notification service" that dispatches messages, or a service that manages people asking for access to a 14:13:34 ... resource and a storage owner granting access. Those are some examples of services. We'll be specifying a minimal set of services, but it's an area where different implementations can explore new areas. 14:13:36 ack gibsonf1 14:13:49 ack gibsonf 14:13:49 gibsonf, you wanted to ask about container vs storage overall 14:13:59 gibsonf1: With this diagram, could you treat the base storage as a container so that you can have the root container as storage? 14:14:28 acoburn: Yes, a storage is a kind of resource. Storage metadata can be treated as a kind of resource. 14:14:44 gibsonf1: So, one can write data directly to the storage itself rather than choosing the specific container? 14:15:05 acoburn: Yes, we'll get into it later. But, you can say "post new resource whether its to a container or storage" 14:15:55 Are notifications a service - or a facet of each resource? 14:16:48 q? 14:17:40 I have made the request to generate https://www.w3.org/2025/10/20-lws-minutes.html TallTed 14:17:46 q+ to ask where Notifications fit in - Are notifications a service - or a facet of each resource? 14:17:58 acoburn: 2nd thing I wanted to go over was the authorization and authentication model. Today in Solid we say you must be authorized and authenticated, but that's really under-specified. It's not clear if you're a bot how you would authenticate. There's are pointers to WAC and ACP, but the precise flow isn't really specified. We spent quite a long 14:17:58 ... time on looking at details of what that flow would be. We looked at areas where we can leverage existing specs. We don't want to invent our own security model. We want to use those best practices. Particularly OAuth. We don't want to force OAuth (you could build this with SAML), but with OAuth as a base, it should give us a clear sense on how you 14:17:58 ... go about authenticating. 14:18:00 ack timbl 14:18:00 timbl, you wanted to ask where Notifications fit in - Are notifications a service - or a facet of each resource? 14:18:19 timbl: I'm wondering where notifications fit into the block diagram. Can any source have notifications? 14:19:03 acoburn: To avoid having links accross everything, if you wanted to watch a specific container or data resources there's a linkage. It would be a service and would operate on your behalf. 14:19:19 I have made the request to generate https://www.w3.org/2025/10/20-lws-minutes.html TallTed 14:20:10 ,a 14:20:10 acoburn: This authorization model is a lot more clear about access tokens. Today in Solid, you go to an authentication system and you get an ID token (which isn't an access token, but it's used as an access token). We want to avoid that. You still get an id token but that id token is exchanged for an actual access token. This will let us make 14:20:10 ... things more interoperable, secure and performant. 14:20:15 !e 14:20:16 !e 14:20:46 s/,a/ 14:20:53 s/!e/ 14:20:55 s/!e/ 14:22:32 acoburn: We want to separate out our storage, application, and Authorization server. You see this a lot in OAuth. RFC 9396 for rich authorization requests provides a nice framework for an application asking for exactly what it's trying to gain access to. And that will result in a token that's used by a storage to access lots of different resources. 14:22:32 ... It's used for access requests, capabilities requests, etc. It unifies them into a single access token. There's great properties like "audience claim" that scopes it to a specific storage. It doesn't prevent you from using DPoP. In Solid DPoP is used to constrain ID tokens, but with this DPoP isn't necessary because these storage tokens constrain 14:22:32 ... the audience. But, it makes it simpler from a developer's perspective to not require DPoP 14:23:59 acoburn: For Authentication, we used webIds that work well for browser based connections 14:24:23 ... there's a webid profile document that constrains openid servers. But, the WebId spec is only a draft so we can't normatively refer to it 14:24:39 ... One of the options is CIDs (Controlled Identifier Documents) do the same thing 14:25:02 ... You can see that a CID gives an agent identifier, and you can define a service saying "here's the openid provider we can use" 14:25:39 ... If you want to have a bot based access, you can provide a public key and use that same mechanism to authenticate yourself by generating an access token and sending it over to an authorization server 14:25:52 ... it provides all the features we want, plus because it's JSON-LD, you can extend it 14:26:04 ... There could be additional context for adding any other properties you want. 14:26:59 ... For the auth flow, when a client tries to access a storage without adequate authorization, you end up with a WWW-Authenticate response header. We'd want to as the "as_uri" property which tells the client where the auth server is. It explicitly tells the application where to go next 14:27:28 ... This is a technique used in UMA and GNAP which uses as_uri. We wouldn't be relying on those specs, we'd just be following that common pattern. 14:28:21 ... In Solid OIDC is a "client identifier document." Some other people have taken that and submitted it to IETF as a draft which has been adopted by the OAuth2 working group. It's still a draft, but we could non-normatively refer to that as a way to identify cleints with full uris. 14:29:16 ... There's also an example of the openid-configuration. This just shows that a client_id_metadata_docuement is supported and other features. But there are other fields for standard OIDC. 14:29:39 ... Our authorization server is also specified by IETF. 14:29:59 ... The application performs authentication then exchanges it for a token from the Authorization server 14:30:26 ... An application that delegates its authentication will produce the token shown via a token exchange 14:30:52 ... We can clarify the token exchange with authorization_details_types_supported. (don't get too focused on the names, they're placeholders) 14:31:36 ... As an example, It's required that a token would include a type, "locations" (all the reosurces that you want to access) "datatypes" you want to have access to, or "purposes" for accessing 14:31:47 ... That's the high-level for authorizations. Any questions? 14:32:12 ... The next things are talked about at a high level, but we didn't clarify the details 14:32:33 ... Metadata resources: there's a number of ideas of what they'd look like 14:33:00 ... Containers are very under-specified. They look different in different implementations. We'd like to be more precise. 14:33:21 ... There's scalability concerns too. There's no pagination, so if you have a container with thousands of resources that's a problem 14:33:39 ... I've written down some examples of what they could look like, but I'm not trying to push for a particular thing. 14:33:52 ... Aaron Bremer has been working on this notion of a "link set." 14:34:10 ... Imagine you have a JPEG and there's a whole bunch of link headers that come through with it. 14:34:23 ... We'd like to define a link header that says "this is a data resource rather than a container" 14:34:23 s/Aaron Bremer/Erich Bremer 14:34:56 ... But also users can specify some user-specified types. Not just a single type. 1 or N types 14:35:05 ... A resource might have an ACL and a link to that 14:35:13 ... Then there's a couple of things related to metadata 14:35:46 ... First is this idea of a link set. It's a way of representing Link headers as a resource. There are specs defining how you would modify them 14:36:19 ... But a link set is very constrained in what you can state. Imagine RDF triples but you can only use IRIs (no literals or blank nodes) 14:36:31 ... But for general metadata, we'd want to have something more wide open like Turtle 14:36:52 ... I mentioned earlier that we want links that link to the storage or storage description. 14:36:59 q+ to ask about file metadate address 14:37:12 ... There might be a link that's pointing to ACP or WAC, but you can use this spec to point to what that access control is 14:37:17 I have made the request to generate https://www.w3.org/2025/10/20-lws-minutes.html TallTed 14:37:32 ... The link set actually looks like: the IETF specification defines two formats 14:37:34 ack gibsonf 14:37:34 gibsonf, you wanted to ask about file metadate address 14:37:37 .. But let me paus there. 14:38:03 gibsonf1: Wouldn't it be simpler to ask for RDF back rather than defining a whole metadata system? 14:38:26 acoburn: You could do that in RDF as well by saying "here's the link and ask for Turtle" 14:39:15 ... The argument for having a different URI. From an agent perspective, you'd want to follow the link. The "/description" section is a placeholder, we're just saying "Here's a link, there's turtle" 14:39:30 gibsonf1: That sounds good. There's flexibility for what you're requesting. 14:39:45 acoburn: Anyway, IETF spec defines 2 formats 14:39:56 ... The first is one of link headers, and the other is a JSON based format 14:40:07 ... If we define it as JSON it becomes easier to edit 14:40:38 ... The storage metadata... again this is just back of the napkin ... uses a CID. Just like the agent identity 14:40:54 ... To be clear we may not want to use CIDs, it could be some other format 14:41:24 ... But the nice thing is that it has a way of presenting a public key for servers that want to sign response headers or use notification, it's a great way to use that public key 14:41:37 ... CIDs also can define how you would use services too 14:41:59 ... It's one way of representing the data we use in a storage, and because it's JSON LD its extendable 14:42:16 ... On containers: This is REALLY back of the napkin so we'll need to talk about it more as a group 14:42:24 ... There was a really strong desire for Pagination 14:42:49 ... This copies activity steams, and there are pros of cons with that, but we want to represent a large container over a series of pages 14:43:00 ... We will also need to clarify the contents of "contains" 14:43:40 ... Today in the Solid spec, there are references to doing this, but not requirements. So we'll need to define if this is a container/resource, the media type so you don't need to make a lot of header requests 14:43:57 ... It can also have user defined types. That's potentially very useful in containers. 14:44:12 ... There's lots to discuss on containers. We want to have dedicated sessions on conatiners 14:44:27 ... What should a container look like? How can we come to a consensus so we can get the interop we want. 14:44:36 ... Let's stop there about containers. Any questions? 14:44:50 q? 14:45:20 acoburn: What comes next? It was a productive half-week in ghent. We talked about a lot of abstract things 14:45:31 ... We got into details in authentication and authorization 14:45:41 ... But we need to make the jump to much more concrete conversations. 14:45:53 ... But starting next week we're going to talk explicitly about resource metadata 14:46:17 ... whether to use link sets or not. The kinds of headers for metadata (for example, having descriptions in TURTLE or other formats) 14:46:28 ... That might be 2 weeks. We want to give it as much time as it needs. 14:46:39 ... After resource metadata, we'll discuss storage metadata. 14:46:51 ... Please think about this and what the format should look like. 14:47:05 ... What do we need to define specifically to help with interoperability. 14:47:21 ... If we spend 2 weeks on resource headers and a week on storage metadata, that will get us into the end of november. 14:47:33 ... Then we talk about containers, and I think that will take use through the end of the year 14:47:46 I have made the request to generate https://www.w3.org/2025/10/20-lws-minutes.html TallTed 14:47:58 ... Ideally, we'll have word on resource metadata, storage metadata, and containers by the end of the year so we can work to normative texts 14:48:09 ... meanwhile, Jesse and I will start working on authorization stuff. 14:48:20 ... Like I said before, the concrete details are not in actual text yet 14:48:36 ... So, we're going to start working on actual text which will need to go through review from this group and others 14:48:56 ... I'd like that to happen by the end of November or December, because this is an essential part for LWS. 14:49:22 ... After that, we get into all the "services" we'll need to sort out. That's going to be in January. 14:49:44 ... This is all to have something in a "Solid form" by the end of April 14:50:05 ... That will let us ask for an extension if we need an extension for the charter or to move us into a CR status. 14:50:24 ... We'd like to have a lot of this in good shape before we do that. The timeline is early spring. 14:50:45 q? 14:51:00 ... laurens: We have about 10 more minutes, so we'll go to the next agenda point unless someone has something else to say 14:51:23 s/... laurens:/laurens: 14:51:29 ... We also are looking for anyone who wants to volunteer their time for any of the aspects we just discussed. It would be very appreciated even if it's just to give feedback. 14:51:35 zakim, next agendum 14:51:35 agendum 3 -- Discussion of meeting outcomes -- taken up [from agendabot] 14:51:51 ... Given I don't see anyone else, next agenda item, which has largely been discussed. 14:52:09 ... Anything else? Or do we close early? 14:52:35 q+ 14:52:45 acoburn: If folks can think about the resource metadata and look at the strawman arguments we have. I hope we can get into it in a concrete way. 14:53:00 gibsonf1: That was a fantastic presentation and conceptual framework. Thank you so much for all the work. 14:53:17 acoburn: Fred, I know you joined those meetings remotely from a challenging timezone. So thanks. 14:53:22 ack gibsonf 14:53:40 laurens: I see no-one further on the queue, so we'll end early 14:53:44 RRSAgent, make minutes 14:53:46 I have made the request to generate https://www.w3.org/2025/10/20-lws-minutes.html pchampin 14:54:21 acoburn has left #lws 14:54:39 RRSAgent, bye 14:54:39 I see no action items