Meeting minutes
Introductions and announcements
laurens: 1st agenda point - Introductions and announcements
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
Summary of face-to-face meeting
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.
<laurens> w3c/
<gb> Pull Request 41 Oct 2025 Meeting outcomes (by acoburn)
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.
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
acoburn: We consider scalability, security, interop, and dev experience.
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
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.
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
… 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.
<Zakim> gibsonf, you wanted to ask about container vs storage overall
gibsonf1: With this diagram, could you treat the base storage as a container so that you can have the root container as storage?
acoburn: Yes, a storage is a kind of resource. Storage metadata can be treated as a kind of resource.
gibsonf1: So, one can write data directly to the storage itself rather than choosing the specific container?
acoburn: Yes, we'll get into it later. But, you can say "post new resource whether its to a container or storage"
<timbl> Are notifications a service - or a facet of each resource?
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
… 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
… go about authenticating.
<Zakim> timbl, you wanted to ask where Notifications fit in - Are notifications a service - or a facet of each resource?
timbl: I'm wondering where notifications fit into the block diagram. Can any source have notifications?
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.
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
… things more interoperable, secure and performant.
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.
… 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
… the audience. But, it makes it simpler from a developer's perspective to not require DPoP
acoburn: For Authentication, we used webIds that work well for browser based connections
… 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
… One of the options is CIDs (Controlled Identifier Documents) do the same thing
… 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"
… 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
… it provides all the features we want, plus because it's JSON-LD, you can extend it
… There could be additional context for adding any other properties you want.
… 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
… 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.
… 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.
… 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.
… Our authorization server is also specified by IETF.
… The application performs authentication then exchanges it for a token from the Authorization server
… An application that delegates its authentication will produce the token shown via a token exchange
… We can clarify the token exchange with authorization_details_types_supported. (don't get too focused on the names, they're placeholders)
… 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
… That's the high-level for authorizations. Any questions?
… The next things are talked about at a high level, but we didn't clarify the details
… Metadata resources: there's a number of ideas of what they'd look like
… Containers are very under-specified. They look different in different implementations. We'd like to be more precise.
… There's scalability concerns too. There's no pagination, so if you have a container with thousands of resources that's a problem
… I've written down some examples of what they could look like, but I'm not trying to push for a particular thing.
… Erich Bremer has been working on this notion of a "link set."
… Imagine you have a JPEG and there's a whole bunch of link headers that come through with it.
… We'd like to define a link header that says "this is a data resource rather than a container"
… But also users can specify some user-specified types. Not just a single type. 1 or N types
… A resource might have an ACL and a link to that
… Then there's a couple of things related to metadata
… 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
… 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)
… But for general metadata, we'd want to have something more wide open like Turtle
… I mentioned earlier that we want links that link to the storage or storage description.
… 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
… The link set actually looks like: the IETF specification defines two formats
<Zakim> gibsonf, you wanted to ask about file metadate address
acoburn: But let me paus there.
gibsonf1: Wouldn't it be simpler to ask for RDF back rather than defining a whole metadata system?
acoburn: You could do that in RDF as well by saying "here's the link and ask for Turtle"
… 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"
gibsonf1: That sounds good. There's flexibility for what you're requesting.
acoburn: Anyway, IETF spec defines 2 formats
… The first is one of link headers, and the other is a JSON based format
… If we define it as JSON it becomes easier to edit
… The storage metadata... again this is just back of the napkin ... uses a CID. Just like the agent identity
… To be clear we may not want to use CIDs, it could be some other format
… 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
… CIDs also can define how you would use services too
… It's one way of representing the data we use in a storage, and because it's JSON LD its extendable
… On containers: This is REALLY back of the napkin so we'll need to talk about it more as a group
… There was a really strong desire for Pagination
… 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
… We will also need to clarify the contents of "contains"
… 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
… It can also have user defined types. That's potentially very useful in containers.
… There's lots to discuss on containers. We want to have dedicated sessions on conatiners
… What should a container look like? How can we come to a consensus so we can get the interop we want.
… Let's stop there about containers. Any questions?
acoburn: What comes next? It was a productive half-week in ghent. We talked about a lot of abstract things
… We got into details in authentication and authorization
… But we need to make the jump to much more concrete conversations.
… But starting next week we're going to talk explicitly about resource metadata
… whether to use link sets or not. The kinds of headers for metadata (for example, having descriptions in TURTLE or other formats)
… That might be 2 weeks. We want to give it as much time as it needs.
… After resource metadata, we'll discuss storage metadata.
… Please think about this and what the format should look like.
… What do we need to define specifically to help with interoperability.
… If we spend 2 weeks on resource headers and a week on storage metadata, that will get us into the end of november.
… Then we talk about containers, and I think that will take use through the end of the year
… 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
… meanwhile, Jesse and I will start working on authorization stuff.
… Like I said before, the concrete details are not in actual text yet
… So, we're going to start working on actual text which will need to go through review from this group and others
… I'd like that to happen by the end of November or December, because this is an essential part for LWS.
… After that, we get into all the "services" we'll need to sort out. That's going to be in January.
… This is all to have something in a "Solid form" by the end of April
… That will let us ask for an extension if we need an extension for the charter or to move us into a CR status.
… We'd like to have a lot of this in good shape before we do that. The timeline is early spring.
laurens: We have about 10 more minutes, so we'll go to the next agenda point unless someone has something else to say
… 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.
Discussion of meeting outcomes
laurens: Given I don't see anyone else, next agenda item, which has largely been discussed.
… Anything else? Or do we close early?
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.
gibsonf1: That was a fantastic presentation and conceptual framework. Thank you so much for all the work.
acoburn: Fred, I know you joined those meetings remotely from a challenging timezone. So thanks.
laurens: I see no-one further on the queue, so we'll end early