14:45:52 <RRSAgent> RRSAgent has joined #lws
14:45:56 <RRSAgent> logging to https://www.w3.org/2025/11/10-lws-irc
14:45:56 <Zakim> RRSAgent, make logs Public
14:45:57 <Zakim> please title this meeting ("meeting: ..."), laurens
14:46:13 <laurens> meeting: Linked Web Storage WG - 2025-11-10
14:46:32 <laurens> agenda: https://www.w3.org/events/meetings/a19ab7dc-1753-433d-bac5-64e3ad8c0a43/20251110T100000/
14:46:33 <agendabot> clear agenda
14:46:33 <agendabot> agenda+ Introductions and announcements
14:46:33 <agendabot> agenda+ Storage Metadata
14:46:40 <acoburn> acoburn has joined #lws
14:46:40 <laurens> chair: laurens
14:49:23 <laurens> agenda+ Authentication
15:00:29 <eBremer> eBremer has joined #lws
15:01:30 <ericP> ericP has joined #lws
15:01:51 <gibsonf1> gibsonf1 has joined #lws
15:01:52 <ericP> present+
15:01:57 <gibsonf1> present+
15:02:34 <acoburn> present+
15:03:21 <ryey> ryey has joined #lws
15:05:10 <laurens> scribe: laurens
15:05:36 <acoburn> chair: acoburn
15:06:09 <gibsonf1> gibsonf1 has joined #lws
15:06:10 <laurens> acoburn: We have two items on the agenda today, the usual introduction & announcements and then our main focus will be storage metadata.
15:06:17 <ryey> present+
15:06:22 <laurens> present+
15:06:26 <gibsonf1> present+
15:06:31 <acoburn> zakim, open agendum 1
15:06:31 <Zakim> agendum 1 -- Introductions and announcements -- taken up [from agendabot]
15:06:42 <laurens> rrsagent, draft minutes
15:06:43 <RRSAgent> I have made the request to generate https://www.w3.org/2025/11/10-lws-minutes.html laurens
15:06:50 <eBremer> present+
15:07:01 <laurens> acoburn: Are there any announcements?
15:07:08 <gibsonf1> gibsonf1 has joined #lws
15:07:27 <laurens> ryey: I'll be changing my affiliation, as I am leaving Oxford University.
15:08:03 <laurens> acoburn: If you are no longer affiliated with a member, you could apply to be an invited expert.
15:08:20 <gibsonf1> gibsonf1 has joined #lws
15:08:36 <laurens> ... I'll follow up with you on this.
15:08:45 <acoburn> zakim, open agendum 2
15:08:45 <Zakim> agendum 2 -- Storage Metadata -- taken up [from agendabot]
15:08:55 <gibsonf1> gibsonf1 has joined #lws
15:09:18 <laurens> acoburn: Last week we talked about resource metadata
15:09:32 <laurens> ... today we'll be talking about storage metadata.
15:09:48 <laurens> ... This has a different role and characteristics.
15:10:05 <laurens> ... We need to sort out what the role of storage metadata is.
15:10:13 <laurens> ... Then we'll discuss the contents.
15:10:28 <laurens> ... Therafter we'll talk about the discovery mechanism.
15:10:43 <laurens> ... And finally, the serialization format of the metadata.
15:11:29 <laurens> ... Both your storage and resources may point to the storage metadata.
15:11:46 <laurens> ... It's a way of discovering the kinds of services one can interact with in the scope of a storage server.
15:12:01 <laurens> ... There is some prior art for this in the Solid protocol.
15:12:21 <laurens> https://solidproject.org/TR/protocol#storage-resource
15:12:49 <laurens> ... It includes very few requirements on the contents of the storage description in the Solid protocol.
15:13:05 <laurens> ... Also, it doesn't specify how it relates to authentication.
15:13:49 <laurens> ... Other prior art, in the world of OAuth2 RFC8414 specifies a discovery mechanism for authorization server metadata
15:14:02 <laurens> ... similar mechanisms exist in OIDC.
15:14:13 <laurens> ... These are defined through the IANA well known registry.
15:14:25 <laurens> https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml
15:14:51 <laurens> ... So let's discuss what the role and scope of the storage metadata is.
15:15:10 <laurens> ... I.e. is the scope a single storage, or is the scope an entire server.
15:15:20 <acoburn> q?
15:15:37 <gibsonf10> gibsonf10 has joined #lws
15:15:56 <laurens> eBremer: A commercial service provider may offer additional services for paying customers.
15:16:14 <laurens> ericP: They might just make a separate domain for that set of features.
15:16:36 <laurens> acoburn: If you had a single storage on a single server, that would be a 1-to-1 mapping
15:16:46 <laurens> ... a commercial provider may have multiple storages.
15:17:04 <laurens> ... They may point to the same metadata or different metadata.
15:17:38 <gibsonf1> q+ to ask shouldn't we differenatiate between the server and the storage for metadata?
15:17:56 <laurens> laurens: I think we should specify it such that we don't prevent either of both options.
15:18:10 <laurens> ... However, it should not be an extension to the user's identity document.
15:18:13 <ryey> q+ to ask about read-only or user-extension
15:18:13 <acoburn> ack next
15:18:14 <Zakim> gibsonf, you wanted to ask shouldn't we differenatiate between the server and the storage for metadata?
15:18:37 <laurens> gibsonf1: We would want to differentiate between the server itself and the entire server.
15:18:52 <laurens> ... There may be differences, they seem like separate items.
15:19:27 <laurens> acoburn: One option here is that there might be metadata to describe the server, which could even go undefined,
15:19:35 <laurens> ... and then there's this thing we call storage metadata.
15:20:16 <laurens> gibsonf1: Let's say you include server metadata in the storage metadata
15:20:23 <laurens> ... you would be repeating yourself over and over.
15:20:52 <acoburn> ack next
15:20:53 <Zakim> ryey, you wanted to ask about read-only or user-extension
15:20:58 <laurens> acoburn: I think separating that might make a lot of sense.
15:21:06 <laurens> ryey: I agree with what has been said roughly.
15:21:14 <laurens> ... I want to ask about this read-only thing.
15:21:32 <laurens> ... Will that prohibit the possibility of the storage owner through some extension mechanism?
15:21:59 <laurens> ... Read-only would entail that the service provider would offer a capability to register this.
15:22:17 <laurens> acoburn: We could require it is read-only, or just not say anything about it.
15:22:32 <laurens> ... Through HTTP discovery the client could figure out it is read-only.
15:23:01 <laurens> ... If it is writeable we should consider the risks of this.
15:23:35 <laurens> ryey: Do we want a storage owner to restrict the available services?
15:23:47 <laurens> q+
15:23:55 <acoburn> ack next
15:23:57 <acoburn> scribe+
15:24:32 <acoburn> laurens: also a different way to look at this (now that we have a distinction with server metadata): could be shared responsibility
15:24:43 <acoburn> ... between storage owner and service operator
15:24:59 <acoburn> ... might be better to leave read-only restriction out and let implementer decide
15:25:15 <acoburn> ... if this resource is writable, there are some tricky authZ issues
15:25:29 <eBremer> +1 laurens
15:25:30 <acoburn> ... I would leave out statements about read-only or writability
15:25:39 <acoburn> ... and leave that open to implementations
15:26:23 <acoburn> ... for user-managed capabilities, that could be listed in the root of a storage
15:26:26 <gibsonf1> q+ to ask about root vs storage
15:26:27 <acoburn> scribe-
15:26:33 <acoburn> ack next
15:26:34 <Zakim> gibsonf, you wanted to ask about root vs storage
15:27:10 <laurens> gibsonf1: It might make sense not to add any additional role to the root of the storage (like in solid)
15:27:16 <laurens> ... and just treat it as a regular container.
15:27:50 <acoburn> scribe+
15:28:00 <acoburn> laurens: I agree, we need that distinction
15:28:02 <acoburn> scribe-
15:28:52 <laurens> gibsonf1: This might be specific to our implementation (i.e. both storage and webids are hierarchical), but having the root container just be a regular container could simplify things.
15:29:41 <laurens> acoburn: Let's recap the discussion. Each storage could have a distinct metadata document and they might be read-only but we wouldn't require it.
15:29:56 <laurens> ... Let's now discuss the contents.
15:30:14 <laurens> ... There may be specific capabilities and services described in the storage metadata.
15:30:39 <laurens> ... For example, services could be a notifiication location, type index, access request, ...
15:30:48 <gibsonf1> q+ to ask about including root container location in storage metadata
15:30:57 <acoburn> ack next
15:30:57 <laurens> ... And capabilities could be the trusted authorization server and supported access tokens or extensions.
15:30:58 <Zakim> gibsonf, you wanted to ask about including root container location in storage metadata
15:31:13 <laurens> gibsonf1: It seems like this functions as a profile card?
15:31:26 <laurens> acoburn: A profile card as I understand it is more for authn.
15:31:55 <laurens> gibsonf1: It might be a good idea to have the root container location as well as the webid for the storage.
15:32:07 <laurens> acoburn: There's some privacy considerations for that last part, but it could be.
15:32:33 <ryey> q+ to respond to gibsonf1
15:32:56 <laurens> ... The root container location makes a lot of sense to me.
15:33:20 <laurens> ... There is some analogy to the issuer in the OpenID/Oauth metadata.
15:33:29 <laurens> ... This avoids a "confused deputy" problem.
15:33:31 <laurens> q+
15:33:32 <acoburn> ack next
15:33:33 <Zakim> ryey, you wanted to respond to gibsonf1
15:33:58 <laurens> ryey: I wanted to reply to gibsonf1 on the webid in the storage metadata.
15:34:11 <laurens> ... I see a privacy issue there, as well as a situation with multiple "owners" of the storage.
15:34:33 <laurens> acoburn: We could not specify this right now.
15:34:44 <laurens> ... And leave this open to implementers.
15:34:54 <acoburn> ack next
15:34:58 <acoburn> scribe+
15:35:21 <acoburn> laurens: we need some equivalent to an "issuer" claim in the storage metadata. The controller part is more vague
15:35:57 <acoburn> ... I wonder about whether the root is exposed, does that address the confused deputy problem?
15:36:17 <acoburn> ... if we include that field, then the storage metadata would need to be per-storage
15:36:40 <acoburn> ... there is good reason to include that field, but it might mean that this is a per-storage metadata
15:36:42 <acoburn> scribe-
15:36:47 <laurens> scribe+
15:36:59 <laurens> rrsagent, draft minutes
15:37:00 <RRSAgent> I have made the request to generate https://www.w3.org/2025/11/10-lws-minutes.html laurens
15:37:47 <laurens> acoburn: After this discussion, if we include the root container it would have to be a per storage metadata document.
15:38:19 <laurens> ... Now let's move to discovery.
15:38:39 <laurens> ... Oauth uses a .well-known URI for discovery.
15:39:00 <laurens> ... This only works well at the domain level, for example at {UUID}.storage.example
15:39:29 <laurens> ... This might be problematic if storages live at subpaths, e.g. storage.example/{UUID}
15:39:56 <laurens> ... We could use link headers like in Solid, but this is hard if you don't have access to the storage.
15:40:36 <laurens> ... Another option is to include it in the WWW-Authenticate header upon a 401 response code.
15:40:54 <laurens> ... We could also do both the link header and the WWW-Authenticate header.
15:41:14 <laurens> ... Finally, it could live in the user's CID document.
15:41:17 <laurens> q+
15:41:24 <acoburn> ack next
15:41:27 <acoburn> scribe+
15:41:49 <acoburn> laurens: at first, I thought using a CID document, but that doesn't necessarily solve this
15:42:04 <acoburn> ... there could be documents in a storage for which the user isn't the controller
15:42:44 <acoburn> ... user's CID doc works for cases where the user controls the resource, but it's more complicated in other cases
15:43:04 <acoburn> ... openid uses a sub-path mechanism with .well-known
15:43:17 <acoburn> ... so we could potentially use that, but it would need to be explicit
15:43:22 <acoburn> scribe-
15:43:58 <laurens> acoburn: We would want to be careful, because if we use .well-known we'll have to register with IANA.
15:44:06 <laurens> ... OpenID tends to do its own thing.
15:44:40 <ericP> q+ to ask why that's btter than just a Link header on 401s
15:44:51 <acoburn> ack next
15:44:52 <Zakim> ericP, you wanted to ask why that's btter than just a Link header on 401s
15:45:20 <laurens> ... I am hearing consensus on this Link: <...>; rel="storageDescription and WWW-Authenticate: Bearer storageDescription="..." combination.
15:45:43 <laurens> ericP: Even on a 401 you could still use this link header.
15:45:56 <laurens> ... But some frameworks might prevent you.
15:46:20 <laurens> acoburn: You don't typically see link headers on the 401 response code.
15:46:42 <laurens> ericP: Most link headers are registered for the 200 status code, but nothing prevents you.
15:47:09 <laurens> acoburn: In LDP there is the w3.org/ns/ldp#constrainedBy Link header on 4xx response codes.
15:47:57 <TallTed> present+
15:48:03 <laurens> ... We could have this link header be in the spec and explicitly require it be returned on a 401.
15:48:10 <laurens> ... I like the consistency of this.
15:48:16 <laurens> rrsagent, draft minutes
15:48:18 <RRSAgent> I have made the request to generate https://www.w3.org/2025/11/10-lws-minutes.html laurens
15:48:54 <laurens> acoburn: When we get around to writing this down, let's use the link header as the starting point for discovery.
15:49:01 <laurens> ... Now let's move on to the format.
15:49:31 <laurens> ... In Solid the storage description is assumed to be RDF, but it is very loosely specified.
15:49:43 <laurens> ... A JSON-LD with a particular frame might make most sense.
15:49:52 <laurens> ... Or it could be arbitrary RDF.
15:49:57 <laurens> q+
15:50:03 <gibsonf1> +1 to any RDF format (as per accept)
15:50:04 <acoburn> ack next
15:50:07 <ericP> q+ to i like the marketability of JSON-LD
15:50:35 <acoburn> ack next
15:50:35 <laurens> laurens: At least require JSON-LD with some frame.
15:50:36 <Zakim> ericP, you wanted to i like the marketability of JSON-LD
15:50:51 <laurens> ... Implementers could choose to do content negotiation.
15:51:00 <TallTed> s|https://solidproject.org/TR/protocol#storage-resource|... https://solidproject.org/TR/protocol#storage-resource
15:51:11 <eBremer> +1 laurens
15:51:14 <TallTed> s|https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml|...https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml
15:51:33 <RRSAgent> I have made the request to generate https://www.w3.org/2025/11/10-lws-minutes.html TallTed
15:51:49 <laurens> acoburn: I think this is enough to start work on the storage metadata.
15:52:04 <laurens> ... Next, we should focus on containers.
15:52:16 <laurens> ... Containers are important, but they are underspecified in Solid.
15:52:27 <laurens> ... This will probably take a few weeks.
15:52:47 <laurens> ... Problems include pagination, format, user-managed metadata, ...
15:52:59 <laurens> ... I would encourage everyone to start thinking about this.
15:53:12 <laurens> ... This will be central to how applications interact with LWS storage.
15:53:27 <laurens> ... Otherwise, I think we can wrap things up for this meeting.
15:53:58 <laurens> ... We can close the meeting here.
15:54:19 <acoburn> RRSAgent, make minutes
15:54:20 <RRSAgent> I have made the request to generate https://www.w3.org/2025/11/10-lws-minutes.html acoburn
16:00:18 <acoburn> acoburn has left #lws