Meeting minutes
acoburn: We have two items on the agenda today, the usual introduction & announcements and then our main focus will be storage metadata.
Introductions and announcements
acoburn: Are there any announcements?
ryey: I'll be changing my affiliation, as I am leaving Oxford University.
acoburn: If you are no longer affiliated with a member, you could apply to be an invited expert.
… I'll follow up with you on this.
Storage Metadata
acoburn: Last week we talked about resource metadata
… today we'll be talking about storage metadata.
… This has a different role and characteristics.
… We need to sort out what the role of storage metadata is.
… Then we'll discuss the contents.
… Therafter we'll talk about the discovery mechanism.
… And finally, the serialization format of the metadata.
… Both your storage and resources may point to the storage metadata.
… It's a way of discovering the kinds of services one can interact with in the scope of a storage server.
… There is some prior art for this in the Solid protocol.
… https://
… It includes very few requirements on the contents of the storage description in the Solid protocol.
… Also, it doesn't specify how it relates to authentication.
… Other prior art, in the world of OAuth2 RFC8414 specifies a discovery mechanism for authorization server metadata
… similar mechanisms exist in OIDC.
… These are defined through the IANA well known registry.
… https://
… So let's discuss what the role and scope of the storage metadata is.
… I.e. is the scope a single storage, or is the scope an entire server.
eBremer: A commercial service provider may offer additional services for paying customers.
ericP: They might just make a separate domain for that set of features.
acoburn: If you had a single storage on a single server, that would be a 1-to-1 mapping
… a commercial provider may have multiple storages.
… They may point to the same metadata or different metadata.
laurens: I think we should specify it such that we don't prevent either of both options.
… However, it should not be an extension to the user's identity document.
<Zakim> gibsonf, you wanted to ask shouldn't we differenatiate between the server and the storage for metadata?
gibsonf1: We would want to differentiate between the server itself and the entire server.
… There may be differences, they seem like separate items.
acoburn: One option here is that there might be metadata to describe the server, which could even go undefined,
… and then there's this thing we call storage metadata.
gibsonf1: Let's say you include server metadata in the storage metadata
… you would be repeating yourself over and over.
<Zakim> ryey, you wanted to ask about read-only or user-extension
acoburn: I think separating that might make a lot of sense.
ryey: I agree with what has been said roughly.
… I want to ask about this read-only thing.
… Will that prohibit the possibility of the storage owner through some extension mechanism?
… Read-only would entail that the service provider would offer a capability to register this.
acoburn: We could require it is read-only, or just not say anything about it.
… Through HTTP discovery the client could figure out it is read-only.
… If it is writeable we should consider the risks of this.
ryey: Do we want a storage owner to restrict the available services?
laurens: also a different way to look at this (now that we have a distinction with server metadata): could be shared responsibility
… between storage owner and service operator
… might be better to leave read-only restriction out and let implementer decide
… if this resource is writable, there are some tricky authZ issues
<eBremer> +1 laurens
laurens: I would leave out statements about read-only or writability
… and leave that open to implementations
… for user-managed capabilities, that could be listed in the root of a storage
<Zakim> gibsonf, you wanted to ask about root vs storage
gibsonf1: It might make sense not to add any additional role to the root of the storage (like in solid)
… and just treat it as a regular container.
laurens: I agree, we need that distinction
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.
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.
… Let's now discuss the contents.
… There may be specific capabilities and services described in the storage metadata.
… For example, services could be a notifiication location, type index, access request, ...
… And capabilities could be the trusted authorization server and supported access tokens or extensions.
<Zakim> gibsonf, you wanted to ask about including root container location in storage metadata
gibsonf1: It seems like this functions as a profile card?
acoburn: A profile card as I understand it is more for authn.
gibsonf1: It might be a good idea to have the root container location as well as the webid for the storage.
acoburn: There's some privacy considerations for that last part, but it could be.
… The root container location makes a lot of sense to me.
… There is some analogy to the issuer in the OpenID/Oauth metadata.
… This avoids a "confused deputy" problem.
<Zakim> ryey, you wanted to respond to gibsonf1
ryey: I wanted to reply to gibsonf1 on the webid in the storage metadata.
… I see a privacy issue there, as well as a situation with multiple "owners" of the storage.
acoburn: We could not specify this right now.
… And leave this open to implementers.
laurens: we need some equivalent to an "issuer" claim in the storage metadata. The controller part is more vague
… I wonder about whether the root is exposed, does that address the confused deputy problem?
… if we include that field, then the storage metadata would need to be per-storage
… there is good reason to include that field, but it might mean that this is a per-storage metadata
acoburn: After this discussion, if we include the root container it would have to be a per storage metadata document.
… Now let's move to discovery.
… Oauth uses a .well-known URI for discovery.
… This only works well at the domain level, for example at {UUID}.storage.example
… This might be problematic if storages live at subpaths, e.g. storage.example/{UUID}
… We could use link headers like in Solid, but this is hard if you don't have access to the storage.
… Another option is to include it in the WWW-Authenticate header upon a 401 response code.
… We could also do both the link header and the WWW-Authenticate header.
… Finally, it could live in the user's CID document.
laurens: at first, I thought using a CID document, but that doesn't necessarily solve this
… there could be documents in a storage for which the user isn't the controller
… user's CID doc works for cases where the user controls the resource, but it's more complicated in other cases
… openid uses a sub-path mechanism with .well-known
… so we could potentially use that, but it would need to be explicit
acoburn: We would want to be careful, because if we use .well-known we'll have to register with IANA.
… OpenID tends to do its own thing.
<Zakim> ericP, you wanted to ask why that's btter than just a Link header on 401s
acoburn: I am hearing consensus on this Link: <...>; rel="storageDescription and WWW-Authenticate: Bearer storageDescription="..." combination.
ericP: Even on a 401 you could still use this link header.
… But some frameworks might prevent you.
acoburn: You don't typically see link headers on the 401 response code.
ericP: Most link headers are registered for the 200 status code, but nothing prevents you.
acoburn: In LDP there is the w3.org/ns/ldp#constrainedBy Link header on 4xx response codes.
… We could have this link header be in the spec and explicitly require it be returned on a 401.
… I like the consistency of this.
acoburn: When we get around to writing this down, let's use the link header as the starting point for discovery.
… Now let's move on to the format.
… In Solid the storage description is assumed to be RDF, but it is very loosely specified.
… A JSON-LD with a particular frame might make most sense.
… Or it could be arbitrary RDF.
<gibsonf1> +1 to any RDF format (as per accept)
laurens: At least require JSON-LD with some frame.
<Zakim> ericP, you wanted to i like the marketability of JSON-LD
laurens: Implementers could choose to do content negotiation.
<eBremer> +1 laurens
acoburn: I think this is enough to start work on the storage metadata.
… Next, we should focus on containers.
… Containers are important, but they are underspecified in Solid.
… This will probably take a few weeks.
… Problems include pagination, format, user-managed metadata, ...
… I would encourage everyone to start thinking about this.
… This will be central to how applications interact with LWS storage.
… Otherwise, I think we can wrap things up for this meeting.
… We can close the meeting here.