– DRAFT –
LWS WG F2F Meeting 2026 (Day 1)

Introduction and announcements

acoburn: I would like to propose that we do not change our scope

termontwouter: Lets not widen, but lets clarify the scope as there is consistently debate
… this may resolve ongoing discussions around containers and query

<acoburn> Charter

laurens: Agree, lets expand out of scope section
… one aspect I want out of scope is access control
… in-scope I want to brush up the UC&R documents and reference that in the re-chartering

eBremer: I agree with all that has been said. Something new would have to be critical.
… Can we have a plan for the future (what is in 1.1, 1.2)

acoburn: What we need in 1.0 is publication of a TR document
… For a 2 year re-charter. Year 1 is to publish that TR document. Year 2 is the maintenance mode, and getting two implementations of every feature.
… working backwards. CR status by September. Then 1 year for TR, 1 year for maintenance.

jeswr: If access control is out-of-scope, does that mean we cannot then define it until a 1.1 2 years down the track

laurens: When we go in maintenance mode, that does not mean we stop work on a new version of LWS. We can prepare for a 1.1 or 2.0, including work on a re-chartering during a maintenance mode.

elf-pavlik: Is that a new charter or re-charter

laurens: It depends. VC did a re-charter for 2.0.

jeremycaine: Lets have a diagram showing access control implemented by an external service to 1.0, and then in scope for 1.1

elf-pavlik: Is threat modelling in scope for 1.0

laurens: Yes. However, we lack volunteers willing to work on this.

eBremer: Can we have a rough overview of the next 5 years. Does not need to be detailed plan.

<Zakim> acoburn, you wanted to talk about incubation

laurens: Yes we can

acoburn: Adding to what is out of scope for 1.0, leaving things like access control out of scope is ok. These can be incubated outside LWS, e.g., working with the Solid CG.
… So let's define the core boundaries in a clear and compelling way

uvdsl: I agree with what has been said of clear scoping. I share the concern of not shooting ourselves in the foot. To be clear, the re-chartering is for 1 year?

<Zakim> laurens, you wanted to talk about the role of the Solid CG

acoburn: Yes. The goal is to get to 1.0 1 year after the current charter ends.

laurens: We should more clearly define the role of CG's in the incubation process. There are interesting issues that have been raised that are out-of-scope for the WG. I do see a role for CG's like the Solid CG to have a more clearly defined incubation pipeline
… we still need to define what such a pipeline would look like

<laurens> jeswr: ODI can support this. At the moment we're setting up Solid26

<laurens> ... as an implementers guide to the Solid specification.

<laurens> ... ODI is helping to develop a feedback model.

<laurens> ... That feedback can be triaged and fed into CG, WG, ...

<laurens> ... Some of the enterprise-oriented feedback might feed into e.g. Inrupt, IBM, OpenLink, Trinpod, ...

<laurens> ... This would help the adoption of the technologies.

<Zakim> jeswr, you wanted to talk about supporting role of ODI

<Zakim> ryey, you wanted to ask about scope about recharter (esp. optional items such as access control)

ryey: What are we allowed to do in a re-charter. Can we keep rechartering through to an LWS 1.5

acoburn: An administrative re-charter should have no change in scope. A full re-charter can be whatever we like subject to AC approval.
… There are therefore two things to consider. What we want as a group, and what we think will get approval.

ryey: Is the proposal that we do not define access control in 1.0

acoburn: Yes, that is what laurens suggested

ryey: If we lack acl, will people think LWS is not mature

laurens: There are two aspects to this: 1) defining a language for requesting changes to access 2) how these access controls are materialised and stored
… we have now left open the higher abstraction of how we interact with access control rules, but we do not define the access control rules
… for 1.0 I would avoid the complexity of defining access control rules

acoburn: In the Solid CG we found access control to be a contentious topic. I worry that it will consume all our time if we bring it in scope.

ryey: I agree.
… Is there a practise of showing recommended implementations?

acoburn: Implementation reports can describe what implementations support
… with a matrix of features and implementations

<Zakim> elf-pavlik, you wanted to suggest prioritized list of items in scope

elf-pavlik: Reflecting on Solid26, it was a very short time frame. This group also has a limited time frame, it would be healthy to track what is required to implement and what is optional to implement.
… as we also need implementations and test suites. Not just the spec document.

laurens: We have the notion of tentative deliverables. The FedID group did this.

acoburn: Yes, and so lets clarify whats in and out. Currently Access Requests, Notifications, Containers, Terminology, Type Index, and Metadata
… are on the table in the group

bendm: Do we have a full picture of how mature and what the features of these are

acoburn: The table of contents of https://w3c.github.io/lws-protocol/lws10-core/ gives this
… authentication and authorisation: says oauth is baseline and you can do other things
… discovery: Storage description document

laurens: We then have access requests & grants, notifications and type indexes
… currently access requests & grants require notifications
… type indexes are most at risk

acoburn: Outstanding features that we need to clarify. Access Requests are an open pull requests. Hopefully today we will narrow in on consensus. Similarly for notifications and type indexes
… we may decide to drop one and have all 3
… From a prioritisation perspective, if we are not doing access control at all -- then access requests provides a way for at least requesting access to resources.

<ericP> we could have access grants without notifications

bendm: There is a fine line between access requests, and access controls

<Zakim> jeremycaine, you wanted to ask about external acl specification

jeremycaine: You have these external entities that are going to be doing things for you. When you describe access requests, is that not the interface that external entities interact with the access control system

acoburn: Yes, access requests are higher level. Everything that you can do in access requests, can also be done with an access control language.
… so the question is what is a minimal high level interface for agents to request acess.
… that is the extent of the scope of that feature

bendm: I understand that in there we could have a hook to an access control language

acoburn: We will get into that in a bit. We are using ODRL as a baseline, but even that is as baseline. One could map that to different kinds of policy languages. It could be anything. It just requires some kind of a mapping. But that becomes an implementation detail
… one could also imagine that there is an ODRL profile and then it is a trivial 1:1 mapping between the content of the access request and the access control

jeswr: Could we not take the ODRL profile we have for access requests and make that our access control language for 1.0
… or at least an access control profile for LWS

acoburn: Yes we could

jeremycaine: Is access control any easier or harder than the way you have defined containers

jeswr: will need multiple access profiles for the different uses cases
… what LWS currently does, this is the interface by which you can modify access control

acoburn: for certain use cases there are needs for complicated access control policies
… but if we define that level of complexity for everyone its a real burden
… 80% could get by with something simple and straightforward without everyone doing some complicated arcane structure

jeremycaine: if you make it too simple, it wont work for an enterprise example

acoburn: exactly. so for the group to leave out of scope or make it an implemntation detail
… anything related to security...it is a constantly moving target
… in 2years, may be so out of data leaving LWS not so useful

<Zakim> termontwouter, you wanted to ask about scoping of authentication

termontwouter: Given that we put access control out of scope, how does the authentication method still relate it

acoburn: Nobody objects to OAuth. HTTP also provides a mechanism for negotiating for other things. Technically we are not mandating that everyone implement OAuth. We are making OAuth a baseline for interoperability.
… What we describe in the specs today says if you are using OAuth, use it correctly
… Other challenges could come back (e.g. GNAP, UMA, etc.) but that is not a requirement of LWS.
… You could also support HTTPSig

termontwouter: Whatever the choice of mechanism, why define ???

acoburn: This is the balance between having enough guidance for interop, whilst also leaving things open-ended to build upon
… so we are giving profiles (e.g. OpenID, SAML, Server side agents)
… which are rec track documents. Servers are not required to implement any of the specific profiles.

pchampin: Think of them like modules, someone could also define their own profiles and plug them in. But they would need a good reason to do so rather than use the ones we define

laurens: The larger we make the specification in terms of MUSTs, the more complicated we make it to define implementations
… what we have seen with Solid in the past is that there was a big surface to cover on the server side
… whilst our use-cases were much smaller than what was defined
… and this cost did not end up benefitting adoption
… Having OAuth as a basline is also very beneficial. It is quite popular in places like MCP and we could benefit from implementing profiles of what they have

<Zakim> elf-pavlik, you wanted to mention evolution of specs

elf-pavlik: We discussed earlier, if the ecosystem of authentication evolves -- there is something better in 5 years it will be easier to plug that in.
… having that mechanism is more important than one specific suite

termontwouter: If the server is required to declare what authentication method it supports. Then there also needs to be a "micro" specification defining what identifier refers to which spec

elf-pavlik: So you use something like a WWW-authenticate header to determine what the authentication method is

<termontwouter> acoburn: summarizes previous hours

<termontwouter> ... Let's wrap up the scope, timeframe, and mechanics for a possible extension

<termontwouter> ... Scope: delineate the currently open-ended scope; emphasize what's IN and what is OUT

<termontwouter> pchampin: By declaring the scope closed, we would need to recharter if afterwards we already want to move on.

<termontwouter> acoburn: As general timeframe, I proposed to aim for a CR this fall (2026), TR fall 2027, which leaves us one year of 'maintenance mode'.

<termontwouter> elf-pavlik: Which specific documents?

<termontwouter> acoburn: All the rec-track ones

<termontwouter> ... we can always descope things if they become at risk

<termontwouter> bendm: Is it common to have a year of maintenance mode?

<termontwouter> pchampin: Increasingly so as a good practice nowadays, though sometimes dormant. It also gives a good start for starting discussion and chartering a possible next version.

<termontwouter> bendm: Then we can also list features that we want to keep possible in 1.0 without actually specifying it yet?

<termontwouter> acoburn: Yes. In particular what other specifications could possibly take up separately.

<termontwouter> ... Let's write this down as a proposal; summarized, not rewriting the charter right now.

<termontwouter> bendm: Maybe we should also add the decision to aim for a recharter.

<acoburn> PROPOSAL: The LWS WG will pursue an administrative extension in order to focus on working on a new charter document.

<laurens> +1

<pchampin> +1

<bendm> +1

<acoburn> +1

<eBremer> +1

<jeremycaine> +1

<uvdsl> +1

<jeswr> +1

<elf-pavlik> +1 (guest)

<gibsonf1> +1

RESOLUTION: The LWS WG will pursue an administrative extension in order to focus on working on a new charter document.

<ryey> +1

<ericP> +1

<acoburn> PROPOSAL: The LWS WG will focus on the current deliverables during the remainder of the existing charter

<laurens> +1

<jeremycaine> +1

<acoburn> +1

<eBremer> +1

<bendm> +1

<pchampin> +1

<uvdsl> +1

<gibsonf1> +1

<ryey> +1

+

<jeswr> +1

<elf-pavlik> +1 (guest)

RESOLUTION: The LWS WG will focus on the current deliverables during the remainder of the existing charter

<acoburn> PROPOSAL: The next LWS WG charter will focus on reaching REC status for version 1.0

<acoburn> +1

<jeremycaine> +1

<bendm> +1

<pchampin> +1

<eBremer> +1

<gibsonf1> +1

<laurens> +1

<ryey> +1

<elf-pavlik> +1 (guest)

<uvdsl> +1

RESOLUTION: The next LWS WG charter will focus on reaching REC status for version 1.0

<acoburn> PROPOSAL: The next LWS WG charter will include a maintenance period

<acoburn> +1

<ericP> +1

<bendm> +!

<eBremer> +1

<ryey> +1

<pchampin> +1

<laurens> +1

<jeremycaine> +1

<bendm> +!

<gibsonf1> +1

<elf-pavlik> +1 (guest)

<bendm> +1

RESOLUTION: The next LWS WG charter will include a maintenance period

<acoburn> PROPOSAL: The timeframe goals for LWS deliverables includes: CR by Fall 2026, TR by Fall 2027

<ericP> +1

<acoburn> +1

<pchampin> +1

<laurens> +1

<bendm> +1

<eBremer> +1

<jeremycaine> +1

<jeswr> +1

<uvdsl> +1

<gibsonf1> +1

<elf-pavlik> +1 (guest)

<ryey> +1

RESOLUTION: The timeframe goals for LWS deliverables includes: CR by Fall 2026, TR by Fall 2027

acoburn: Let's move on to the next topic, which is Access Requests

Access Requests

<acoburn> Access Requests PR

<gb> Pull Request 106 Add editors draft for LWS Access Requests and Access Grants (by acoburn)

acoburn: I'd like to set as a goal that we get consensus on what we want this proposal to be, and clarify what we still want to change and how.

acoburn: The (currently separate) document does three things
… it allows the actor to request access to resources
… it defines the semantics of a grant to do specific actions on resources
… and it defines how to specify profiles that use this model with a specific policy language.
… The examples use JSON-LD, but the data model is completely abstract, separate from any serialization.

acoburn: The high level model of a request consists of a type, a notification inbox, a storage identifier, and an array of access objects

eBremer: We should make clear that JSON-LD arrays are unordered.

acoburn: An access object defines what access is being requested, and is specified in the profile.
… I'd like to have some input on certain questions.
… First, I wonder if hasPurpose should be part of the access object or of the request as a whole.
… The rest of the access object consists of a target, an array of actions, and an array of constraints.

laurens: Are the constraints additive?

acoburn: Yes

<Zakim> gibsonf, you wanted to ask about target

bendm: Can we do disjunctions as in ODRL?

acoburn: No, it is a subset.

gibsonf1: Why do we have a type on the target?

laurens: To make the request self-contained. For example if a container changes to a resource, in which policies on the first apply to its children, but the latter on the resource itself.

acoburn: We also might not know the exact URL, so we need an indication of how to interpret the values.

gibsonf1: The server knows what is at the URI. Reusing URIs is confusing, plus the request would have been decided upon by the resource owner, who should be aware of this change.
… I would refrain from putting semantics about the resource in the access request.

acoburn: Going back to use cases. When someone requests data, it is often the case they don't know the URLs, but they do know the type.

<elf-pavlik> +1 from SAI access needs on only knowing type/shape

acoburn: We define target as a term with a type and a value. The type is an extension point to indicate how to interpret the values (paths, categories, resources...).

gibsonf1: I understand the StorageResource type, but not the Container vs DataResource types.
… It would be more helpful to have types like PhotoAlbum or Friends etc.

acoburn: I'd expect there to be other types. We kept this minimal because of the work on Type Indexes.
… The three provided options are about literal locations, but this is not a requirement.

jeremycaine: I think we are mixing up type and metatype.

<ryey> Confusion is probably only on these three terms (and the intention of types used for other stuffs is less confusing). I suggest changing `DataResource` + `Container` + `StorageResource` to `Resource` + `AllSubResources`?

elf-pavlik: It is the type of targeting method, not the type of resource.

acoburn: Indeed, and this would also depend on the underlying policy language.

<uvdsl> +1 to ryey here, maybe the terms could be clearer in what their usage entail / what their goal is

<acoburn> +1 to clarify naming

uvdsl: Maybe we should rather define the types by the functionality you want to achieve. For example the container itself vs the child resources...

<pchampin> +1, this clarifies the fact that "type" captures the intent of the requester (and therefore how to interpret the "value")

<ryey> Sure. Will do now

<Zakim> uvdsl, you wanted to ask about storage (as recipient), see also https://github.com/w3c/lws-protocol/pull/106#discussion_r3009771501

uvdsl: I commented on the initial draft of Access Requests, and I understand the storage field as pointing to the 'recipient' of the action/grant.
… Would this not better be modeled as the 'audience'?

<elf-pavlik> +1 user centric flows

uvdsl: That would decouple it from the storage location, and allow user centric approaches where a grant gives access to resources on different storages.

<ryey> I may have a different opinion than uvdsl of the "recipient" (already in queue)

acoburn: Good idea. Would this still be required?

uvdsl: I feel like it should.

pchampin: But this would be posted to the inbox which is discovered at the storage?

acoburn: Not necessarily, that is just one option.

<Zakim> bendm, you wanted to ask about specific profile identifier

ryey: My main reservation here is that as the recipient, why would it need to be present?

uvdsl: That is why 'audience' is a better concept here.
… Similarly, this would allow requests to be made without knowing the storage location (cf. Google Drive)
… The main difference is that storage is a technical perspective.

ryey: There are arguments for both aspects.

uvdsl: The value of this 'audience' property could cater to both.

ryey: Should that be a single value or an array?

acoburn: I'd think a single value

uvdsl: The audience of JWTs can be an array

acoburn: A quick followup. The audience from a request should translate smoothly to the one in a grant. Can we have an array there as well?

elf-pavlik: In SAI, grants are scoped to single storages, because they are used as credentials.

acoburn: But here grants are not used as credentials.

elf-pavlik: As long as they are never exposed to other storages, it's a possibility.

uvdsl: I think there is no issue with having an array in grants as well.
… Though the authorization server would probably want to limit the audience of the grant to the specific storage.

pchampin: My interpretation of the storage field is that this coincides with the owner/inbox where the request/grant was posted, and thus neither the requester nor the assignee.

uvdsl: But in the grant the same field was used as 'sender', or 'assigner'.

elf-pavlik: How would we use the value of such a field? That would be helpful.

acoburn: Storage was meant as a high-level scoping mechanism, as a 'realm' of data.

ryey: For me, it should be a single value, and not an array, since the information it adds is to inform the requester. Multiple ones muddle this information.

acoburn: Given that it is a very high-level security API, I also think we should value clarity over extensibility. So I'd be inclined to have a single value too.

uvdsl: I'm fine with either, but maybe there are use cases that might require it.

acoburn: Worst case, one can emulate this with multiple requests.

bendm: What do we decide on the kind of audience?

termontwouter: if we want to allow this kind of broader, non-storage, audience
… to support something like "I want to see all your photos (wherever they are stored)" to a user
… what would the grant look like?

acoburn: imagine I have 5 different storage providers, and someone sends a request to see photo of my recent trips
… and that those photos are spread on 2 of my 5 storages
… I am the audience of the access request, I would create two access grants, one per storage

termontwouter: so the grant is not a copy-paste of the request

acoburn: there is a relation, but this is not copy-paste
… if your request access to a type, I would grant you access to a location

<Zakim> ryey, you wanted to discuss purposes; maybe also interplay of multiple access items (over same resource), and partial grants

ryey: The hasPurpose and constraint fields seems exceptional in that they are not something the LWS server knows about. Maybe we should group this in one object (constraints)?

acoburn: I concluded the opposite. A server is indeed going to have a hard time enforcing a purpose. Constraints, as I understand them, will be enforced at evaluation time.

ryey: My rationale is that constraints are an extension point, and are therefore not necessarily enforceable. For example whether the data is going to be processed locally.

termontwouter: this is not stctrictly ODRL model ... assignee is also a constraint...

<ericP> 0

<pchampin> STRAWPOLL: should "purpose" be merged into "constraints"

<gibsonf1> I'm not sure what purpose would mean at all for a server

<pchampin> -1

<termontwouter> +1

<jeremycaine> -1

acoburn: ODRL purpose goes inside of constraint block

<ryey> +1

<bendm> +1 (follow ODRL)

<elf-pavlik> 0

<gibsonf1> wouldn't purpose only be understood by the resource owner as opposed to the server?

<uvdsl> +1 because it would allow discover servers that support purpose

<laurens> 0

acoburn: servers may not be able to enforce

laurens: do we need to spec it, one can put it into ODRL

acoburn: we can add it into constraints or leave it out

<uvdsl> A Server could advertise supported constraints, that could include a constraint on purpose (if a server finds a way to enfoce it)

pchampin: i sympathise with idea that ODRL supports it, it is still wip, semantics are still being defined, constraints in ODRL are to flexible for interop, that's why i voted -1
… there are two options, enforcable constraints other constraints that include purpose etc. i see value in separating both
… mixing it together doesn't feel right

termontwouter: you can't split up constraints into two groups, some can only be enforced in audit, you can't clear cut it off
… it may be required for constraints to define how they apply

laurens: i think for now we define only minimum constraints that can be enforced at requires time, other can be added up to implementers to do that
… we should start only with what's possible at request time

uvdsl: there's also an option to add discovery aspect for servers, clients can only expect what server advertises, so client doesn't shoot request into dark
… instead client checks beforehand, for purpose it would know which one is supported

<uvdsl> Similar to https://solid.github.io/web-access-control-spec/#acl-resource-condition-discovery

acoburn: to your point about constraints, jeswr and I, we had idea that a lot of values represented in access token at some point are validated
… issuer client id, there is some mechanism to validate it
… it is really hard to validate client assertions for how something is to be used, client can make one claim but do something else
… if there is a some constraints for purpose, in access grant or set of ag, there is purpose a and purpose b
… we can then supply link header in response to indicate this is purpose a this is purpose b, that would be one thing that we could do

uvdsl: i was saying that weather or not a particular constraint.... my suggestion was that server can advertise what they support

<termontwouter> +1 for servers declaring supported constraints

uvdsl: server can say my engine allows for this or that constraing
… if the client approaches a server stating it's purpose, and the server can check what the client has stated based on policy

uvdsl: i agree with link header which could be a hint
… client can also have a purpose in the token used for request, server could check asserted purpose if it matches what policy says

uvdsl: that would provide technical foundation for argument of misuse

acoburn: one could build rich authz request on top of what we have, this would allow to add purpose in the entire interaction
… we could add in the discovery document indicate which constraints are supported by the server
… all of which leads to moving the purpose to the constraints object

pchampin: it may be harder to figure out what is being supported, especially if discover is via user's id not the storage
… : some servers can enforce it some not, we may not rely on discovery of specific capabilities before asking

jeremycaine: lws client, makes request to the server eg. give me photos
… server has multiple storage managers

acoburn: the owner has a role to play there

jeremycaine: server consults icloud photos, medical photos etc.
… decides which photos to grant access to
… client may receive only some of the exising photos

acoburn: i would imagine that owner of the data will be involved in those negotations
… you would get a notification and had UI as owner to make the decision
… you created the request, i create the grant saying what you have access to
… access policies get updated accordingly
… the grant is just a receipt

jeremycaine: i have evernotes, which could be lws connecting to various systems
… request comes for photos, i will not allow access to some sensitive photos

acoburn: request allows me to describe what i'm looking for, the purpose would be one of those things
… you would respond, or ignore it,

<Zakim> elf-pavlik, you wanted to suggest defining storage manager term

<Zakim> jeremycaine, you wanted to ask about terminology since 'storage' in the Terminology section of core spec; we are discussion enumeration of audience (storage, user etc) and to ask is access request for the client to access a resource from LWS server, or access request for LWS server to an external thing e.g. the stored item

<Zakim> bendm, you wanted to ask about profile identifier

bendm: how is the access request/grant structure linked to a profile identificator?

acoburn: we're currently using the lws#AccessProfile identificator
… other profiles may have different features/qualities

bendm: so how is a grant body linked to a specific profile identifier?

acoburn: there's a type field

acoburn: so a wac profile would have type WacPolicy

<Zakim> gibsonf, you wanted to ask about purpose - woldn't that just be a message to the resource owner? and to ask how a server would theoretically enforce purpose

gibsonf1: the purpose of purpose
… this is more a human understanding kind of thing?

acoburn: yes, there are things that you might need to enforce in a legal way
… we are not formalizing how a client makes use of this purpose, but it enables regulatory enforcement

gibsonf1: it feels like it wants to be a string?

<pchampin> https://www.w3.org/community/dpvcg/

jeswr: there's a set of DPV vocabularies (live with ODLR), with a large set of purpose terms

gibsonf1: but a client enforcing usage controls, what does that mean?

jeswr: in the scope of digital rights management
… e.g. within a bank, there's software infrastructure, where data being collected is only used for their specific purposes

acoburn: it's more about auditability than enforcement

<Zakim> termontwouter, you wanted to clarify ODRL constraints

termontwouter: about declaring the access request service
… does it mean an access request is tied to the storage?
… does a storage only provide one for all its resources?

acoburn: access request service can be separate, but they could be deployed together as well

acoburn: you could also have multiple access request services, e.g. for different profiles

acoburn: next: serialization
… the idea: jsonld serialization is one possible serialization
… the datamodel is independent of serializatoin
… the protocol states: access request and access grant endpoints are LWS containers
… some things
… one: the access controll properties within such a container might act a bit different than in a 'normal' container
… there might be need for particular behavior, e.g. a particular agent could manage all requests, or only a specific set of requests
… the details, I moved to security and privacy considerations

jeswr: this was based on the way inboxes work
… we are defining containers in a way that are inspired by LDP
… I could imagine implementations that state: LWS + set of restrictions === LDP
… could we think of similar constraints so that LWS + set of restrictions === LDN inbox?

acoburn: I had activitystreams in the back of my head
… for reasons, we don't want to pull in the entire LDP spec
… we could clarify that more

elf-pavlik: useful reference is social web WG note where Amy wrote how activitypub relates to this.

acoburn: there's a notification section: this section is intentionally vague

<Zakim> termontwouter, you wanted to clarify request service API

termontwouter: why should we define the API for the access request / grant service? given there's already a profile
… we don't really separate that kind of request from the OAuth request, which transfers the same info

acoburn: profile defines the datamodel
… defining the API here was defining something generic
… it could go into the profiles

<uvdsl> Ben, can you again elaborate on how your solution works?

termontwouter: having the protocol either as part of the profile, or as a separate profile would make sense

acoburn: we could move that right now, to keep flexibility

acoburn: security and privacy considerations would be part of thread modeling excercise
… the profile we want to define should be general-purpose and as simple as can be
… taking ODRL profile, underlying layer of WAC would need a translation to the actual WAC execution

jeswr: I propose we say we can use the ODRL access request also feasible for access control language

acoburn: I think one could use that, but it's not necessary
… I propose to keep out of scope, so existing systems can still be used

jeswr: I'm building an authz mgmt browser extension
… you could issue your access request to that extension, so granting access can be done in a popup (nothing to the server yet), which could then be translated to access control update
… so wherever you want to issue an access request, you might want a client that can issue that as a change to access control

acoburn: I don't think our proposal prevents what you're describing
… so, yeah, it looks like that's possible, let's round off here

gibsonf1: so, access grants, are effectively receipts? server could then interpret that to access control as that server sees fit?

<Zakim> gibsonf, you wanted to ask about nature of access requests

gibsonf1: so if that grant is deleted, that access control is also deleted?
… is it the only way to give access?

acoburn: it's one way, we hope one that's interoperable
… if you have other ways to achieve that, access requests shouldn't prevent that

gibsonf1: if this were the only way, it solves different servers having different WAC vs ACP etc

acoburn: in principle, it would provide a high-level interface
… it doesn't prevent you from working on that lower lever

gibsonf1: in LWS spec, will this be the only spec'd way to do it?

acoburn: a conforming LWS implementation doesn't need to support this to be conformant
… but if it wants to implement this feature, this is how to do it

gibsonf1: I suggest to just require this
… to make interop easier

acoburn: so, suggestion is that all servers support at least this access request/grant grant

<uvdsl> does this work with the "profile approach"?

jeswr: I get the access request/grant way, not the ODRL profile

acoburn: in the doc today, we describe a profile, but don't require it
… we could require access request / grant, but not enforce the specific profile

pchampin: can I just pop a grant out of the blue?

acoburn: yes

pchampin: so that would be a replacement of finding and patching the ACL resource?

acoburn: not necessarily a replacement, but a higher-level API

<uvdsl> I hope not

<uvdsl> re pchampin...

termontwouter: so you could move the requirement of the feature to the core, and have the profile as a separate doc

pchampin: yes, but that's an editorial decision

uvdsl: Is then the access grant the normative source for authz? or the higher-level interface?

acoburn: the latter, the higher-level interface
… we're not specifying the lower-level

uvdsl: so if I delete a grant, is the authz still in place?

gibsonf1: I'd say no

acoburn: if I were writing an implementation, I would have the authz rules follow the existence of the grant

pchampin: the current spec does state that the existence of the grant is leading

laurens: the implementation may choose to do something specific, e.g. WAC, and additional rules on top of the grants can happen, but that's not materialized to the access grants

<Zakim> elf-pavlik, you wanted to mention that SAI uses access grants as access control source of truth

elf-pavlik: implementer feedback: I just do queries on top of the grants to grant access, that's possible

<Zakim> ryey, you wanted to ask about ODRL profile as access control, with editors; also about not necessarily access control language and to ask about (notification of) revocation

ryey: access grants as source of truth: it works alright if we require an access control policy under the hood, but if we look into other possibilities, the policy is not an access control policy
… I see difficulties trying to implement this in the policy engine I'm working on
… this is a mental model difference of how we see access

acoburn: can we make an issue about whether access request / grant layer is a source of truth? or just a layer on top?

<uvdsl> +1 on scrutinizing whether the access grants are the source of truth for the system (also given that there might be other parallel mechanisms on-top of a dedicated authorization layer)

bendm: I think we may need more access control constraints below or above access grants

gibsonf1: our implementation would be: grants would be guiding on active WAC rules

uvdsl: that's also how I implemented it

<pchampin> "source of truth" is an implementation detail

uvdsl: the interface for the user is the access grants

acoburn: there's the interface for describing how access works
… there's interface for enforcing access controlls
… the API for describing what access is given could be access request/grant
… but what access is given, is on the WAC level

uvdsl: question is: can you require the sync? eg if you have multiple interfaces or sideload authz
… or should it be a SHOULD?

bendm: so it can be possible that you have lower rules that are more than what grants are exressing
… eg. i can have admin account that allows me to do more than what grants are specifying

laurens: if implementation uses something more, i would expect that access grants i retreve to be in sync

bendm: if i make 5 grants, is it possible to have 7 rules where 5 are from the grants and 2 extra

acoburn: it seems like an impl detail

acoburn: are we going in the right direction?

all: nodding yes

<gibsonf1> +1

laurens: let's do terminology

Terminology

acoburn: I made a start on terminology

acoburn: i feel like we need 'Storage'
… 'Resource' is from HTTP
… everything else is up for debate
… Storage Description, Storage Workspace/Root, Container, Data Resource, Metadata Resource, Membership/Containment?
… Agent, Controller/Storage Manager, Services, Capabilities
… there could be other terms

acoburn: Storage. If you look at Solid, storage is a URI space
… Storage defines the identity space

<ericP> propose s/URI space/Resource hierarchy/

acoburn: so, within a Storage, all resources are within that URI space
… the provider (dropbox.com) could be different from the uri space
… and you can link to other URI spaces, but all managed resources are within that URI space

<gibsonf1> "The target of an HTTP request is called a "resource". HTTP does not limit the nature of a resource; it merely defines an interface that might be used to interact with resources. "

jeremycain: at the end of the day, the Storage is the 'top of the tree'?

elf-pavlik: does the storage denote the root?

acoburn: the workspace is part of the URI space, with specific behaviors
… a Storage only defines the URI space, once we're in a Workspace, it can have specific behaviors
… a Workspace can have the same URI as the Storage, link in Solid, but they can also be different
… it gives you some models to organize things
… eg having multiple roots, things that live without the roots

<Zakim> gibsonf, you wanted to ask on sync and to ask about resource definition

laurens: shouldn't we clarify what we mean by URI space?
… is that a set of HTTP uris, what about subdomains, etc?
… my main issue is that it's a bit ill-defined

<Zakim> ericP, you wanted to propose s/URI space/Resource hierarchy/ + specifiy that it may not be the root

ericP: in most systems, it will not be a server root, but everyone knows what slash means
… e.g. unix-like, /home/alice/bob/claire
… for alice: it'll start at /home/alice, for bob it'll be /home/alice/bob
… so I suggest to make it broad enough, also for people that don't maintain their own domain names

acoburn: conceptually, /home/alice is a storage, /home doesn't need to mean anything

ericP: are we prohibiting?
… e.g. can a storage be within another container?

acoburn: here, we're talking about /home and /home/alice: /home is out of scope for LWS

ericP: so, we are indeed prohibiting that a LWS server has /home as container, cannot specify /home/alice as storage?

termontwouter: but they can both storage roots, right?

acoburn: I would state that storage roots are non-overlapping

jeremycaine: so you should never be able to go from one storage to another storage?

acoburn: yes, but that's rather an implementation detail

acoburn: storage is conceptual URI hierarchy/space, the workspace has particular behaviors

laurens: would an access request audience be the storage or the storage workspace?

termontwouter: can we keep storage as the higherlevel thing, and rename the current to Storage Namespace?

acoburn: I like workspace, to disambiguate from 'Root' as that's both a hierarhcy root as a URI root

laurens: should we clarify that it's an http namespace?
… and further narrow that down?
… or keep it vague?

acoburn: for me, someone could use a different URI space

bendm: but there's already a lot HTTP dependency in the spec, so we could just be specific from the start.

acoburn: we could allow DID, as many DID ids have an HTTP interpretation

<gibsonf1> The actual definition in the spec of a resource: "3.1. Resources

<gibsonf1> The target of an HTTP request is called a "resource". HTTP does not limit the nature of a resource; it merely defines an interface that might be used to interact with resources. Most resources are identified by a Uniform Resource Identifier (URI), as described in Section 4."

jeremycaine: so if we start from HTTP, and going to Resource, does it have to be HTTP?

laurens: we collapsed RESTful bindings, so now everything is HTTP
… in an LWS 2.0, we could decouple actions from protocols, but for now I wouldn't

jeremycaine: suggest to simplify: Storage Namespace and Storage Workspace

pchampin: explicit notion of namespace is good, but we don't specify storage anymore
… for my understanding, in solid storage namespace and workspace are collapsed
… so this definition, a namespace can have multiple workspaces
… what does this distinction buy us?

acoburn: example: storage namespace is https://storage.example/

storage workspace is https://storage.example/ws/

acoburn: you can have https://storage.example/sparql/
… part of the storage, but don't conform to LWS
… and you can have multiple workspaces

eBremer: so is the namespace a template for all the URIs?
… a prefix for everything?

elf-pavlik: like void:prefix

acoburn: yes, but not everything is RDF

pchampin: so storage NS has multiple workspaces (that are LWS containers) and can have other things

<Zakim> gibsonf, you wanted to ask about storage as a container itself and to ask that Storage itself should be identical to a container when an interface made to it for that data

gibsonf1: so could you have a storage that is also a workspace, and have as many hierarchies you want below
… issue of ldp is the nature of ldp:contains as only form of hierarchy
… so could we have different semantic hierarchies within a workspace?

<uvdsl> ... needs to leave ....

acoburn: question is, do we need a notion of workspace?

TallTed: there is a blurring between the 'client' and 'server' perspective
… recognize that the server concept of root needs to be distinguished from the client concept of root
… LWS should be usable for more than Solid implementation pattern
… that separation between what works for LWS and what works for Solid should be kept in mind

acoburn: cfr blurriness, that's why I want clear definitions

<Zakim> elf-pavlik, you wanted to ask about UC for multiple workspaces

elf-pavlik: is there a clear usecase for multiple workspaces?

acoburn: depends on how storage description is structured
… #117

<gb> Issue 117 Clarifications around containers and roots (by kaefer3000)

bendm: if you want to have sparql services, then you need a distinction between workspace and storage, and you may as well allow mutiple workspaces

acoburn: Storage (concept) vs Storage Identifier (globally unique id) vs Storage Description Resource

acoburn: Storage Description Resource could specific ID, multiple workspaces. if you workspace root is the same as your storage ID, you get the Solid scenario
… at some point, you need a reference from the storage to a 'this is a place where you can start writing'

elf-pavlik: yes, but then you need to prompt the user for which workspace to use

pchampin: I see difference between storage and workspace is still useful
… storage is 'all resources', workspace is 'a specific set of resources'

<termontwouter> +1 to definitions of pchampin

pchampin: 1-to-1 relation is simpler, but distinction is useful

<elf-pavlik> +1 pchampin

laurens: in making this distinction between storage namespace and workspace: what does that buy us in terms of authz and authn?

bendm: only storage workspace conforms to lws or the storage as well?

pchampin: the storage has one identified controller, in my opinion
… the workspace are the containers (which could be only one)

<gibsonf1> storage = service provide by LWS compliant system

laurens: a simpler way of approaching: a storage is realizing some operations on logical resources, rather than saying something else
… I would like to say: a storage may contain one or more collections of resources managed by one subject

termontwouter: I like the logical aspect of that

<Zakim> jeremycaine, you wanted to ask about parallels to cloud object service and buckets and folders

TallTed: multiple services may use the same directory; this leads to security issues that we will need to discuss later

jeremycaine: parallel with AWS: tenant > service > instance > bucket
… are we aiming to align our terminology to something like that?

laurens: I think we are moving closer to that
… bucket would be workspace
… tenant would be storage
… I'm not sure what "service" would be

termontwouter: in the example we have a SPARQL service, we could have more of those

acoburn: we should clarify the concepts first; then discuss how we express them

laurens: as in: "a workspace could be just another service"

bendm: I don't think a storage could have no workspace, that justifies treating it differently

laurens: what we call a storage is a collection of services, that complies with our spec; think of it more as an openid description
… most of the confusion comes from the word "storage", which assumes that everything under it follows the CRUD operations

gibsonf1: I agree; I assumed that storage was what we called "pod" but it seems that we are talking about the service serving the pod

<Zakim> gibsonf, you wanted to ask: are we conflating the idea of a Storage with the Service providing the storage (in terms of services supported by the overall service etc)

gibsonf1: this makes it confusing

laurens: the issue I see, in turning this into a general service description, is creating more room for interpretation

<Zakim> elf-pavlik, you wanted to clarify server with diverse storage configurations

elf-pavlik: I understood gibsonf1as suggesting we provide whole server description
… I think one description per storage is simpler

laurens: I would avoid the term "server", it adds complexity

jeremycaine: in cloud, we talk about "control plane" which has many "data planes"

pchampin: My understanding is that storage is close to the term "Pod" in Solid
… I would avoid generalizing storage description into a service description
… The description is storage centric.

gibsonf1: having "LWS service with a URI" in the terminology, would not prevent you from having a more specific "pod" description
… every storage could use these services or not
… it would still make sense to have a global list of the services available with a given service provider

<Zakim> termontwouter, you wanted to preserve storage as it is

termontwouter: to gibsonf1's comment; in that case, you could have all storage desciptions point to the same resource
… to laurens, I don't think that the notion of storage is strange

<elf-pavlik> Hydra has something in lines of (REST) Entry Point

termontwouter: +1 to pchampin to be storage centric

laurens: the more I think about it, the less I like the level of indirection introduced by workspaces
… it makes sense to have a description resources associated to a storage; but that storage should have a singular container as an entry point

acoburn: so you propose that the storage URL is a solid container? like Solid?

laurens: yes

gibsonf1: +1 to that

acoburn: is everyone ok with that?

<TallTed> "LWS Storage" much preferred. Specificity in naming is a good thing.

acoburn: the storage URI is a root container; every storage has exactly one root container?

<TallTed> "LWS Storage" in part because we know "Solid Storage" already exists

<TallTed> yes!

<TallTed> "Storage" is ambiguous from the start. That's not good.

laurens: I would not have the examples assume that there is a single-storage tenant

elf-pavlik: for me that's ok
… the most confusing for me is "storage" vs "workspace"
… having different endpoints under the same NS may not be an issue if we removed slash semantics

<TallTed> "LWS-compliant Storage" ight be better

TallTed: "storage" in itself is ambiguous, e.g. "solid storage", we need a more specific name
… "LWS-compliant" storage

termontwouter: it is a URI, the term "Storage" in the JSON-LD is scoped by the context

pchampin: the distinction between root and storage is benfitial, even that it would still allow solid practice but not make it mandatory
… possibly just a purist view, but still have 1 to 1 storage to root container / workspace

<TallTed> TallTed: We have to think about humans as well as machines. The URIs for "Solid Storage" and "LWS Storage" will be different, but humans will typically be seeing "Storage" and "Storage" and not understand the collision.

acoburn: you couldhave storage and workspace at a different url, but there would be 1 to 1

laurens: just as we define access request service, we could define storage / root container service, don't care how we call it

termontwouter: but there would be requirement for just one service of that type

acoburn: yes, similar to storage description

acoburn: so we have Storage, Storage Description and Storage Workspace, all in 1-1 relation

laurens: I would reword the definition of storage, to "a set of services discovered through a single Storage Description"

<Zakim> jeremycaine, you wanted to ask what is storage

jeremycaine: we still have not addressed TallTed's point about the term "storage"
… would the name "LWS server" work?

laurens: a server could be multi-tenant
… multiple individual storages could be hosted in a single deployment

pchampin: let's call it full Linked Web Storage and in spec shorten it to Storage

<TallTed> +1 pchampin

pchampin: : i didn't have all the services in mind, they are useful but not in scope of the spec

gibsonf1: a note on the pod/storage; in our case we are modelling a storage as a container for a certain kind of thing
… a single user may have thousands of storages
… the idea of a Solid pod is a unit with a given controller
… the storage is not the service, it is the thing being served

<Zakim> elf-pavlik, you wanted to mention classes of products and requirement subject used in normative statements

laurens: we also have use-cases where a user has several storages

<TallTed> "Set of services" because Create, Read, Update, Delete might be considered different services.

elf-pavlik: for the test suite, we need to determine if the subject of a normative statement is the storage, the storage description...

laurens: to pchampin, if the storage is not a *set of service* then what distinguishes it from the workspace?

pchampin: the workspace is a single container (node), the storage is everything under it (tree)

TallTed: it is a set of services if you consider each operation as a different service -- I could provide only a subset of these operations/services

jeremycaine: I would say those are operations; the services are things like access control...

acoburn: can we improve the definition.

[wordsmithing the definition of storage]

<Zakim> jeremycaine, you wanted to ask have we defined service

laurens: I would like to reach the definition of "resource"
… do we restrict it to "LWS resource", or keep a generic "resource"
… I would define a LWS Resource as either a container or a data resource.
… I agree that there might be other aspects (user-managed / server-managed).
… I see use-cases for more subtle definitions, but in the interest of time and simplicity, I would stay away from them.

acoburn: is this definition different from the definition HTTP?

gibsonf1: the definition in the HTTP RFC is actually different from what we have in the definition right now. We should not define what the resource *is*, only how one interacts with it.

<Zakim> gibsonf, you wanted to ask that we use the actual HTTP definition

gibsonf1: the current definition conflates resource and URI, while many URIs may identify the same resource
… LWS should not tell you how to manage resources.

laurens: what I want to prevent is that a representation of a resource / modification of a resource operate over mixed content (user-defined vs server-managed)
… we can say that an LWS resource is an HTTP resource, but with additional restrictions

gibsonf1: for us, the problem you describe does not exist. We are data-first, so each piece of data has its own permissions. We would not split the data in different resources based on user- vs. server-managed.

termontwouter: I agree with gibsonf1 that the current definition looks a bit like a 1-to-1 mapping between resource and URI, which is not what it should be

jeremycaine: we could start by defining an LWS resource as an HTTP resource

[wordsmithing the definition of resource]

<gibsonf1> +1 on definition

acoburn: the service description is available at a given URI, and has a specific representation.

gibsonf1: the definition should say "a representation" not "a resource"

<Zakim> gibsonf, you wanted to change resource to representation

pchampin: I disagree; it is not a LWS a resource, but it is a resource in the HTTP/Webarch sense

gibsonf1: we should not define the nature of resources, we should define interactions with those resources

acoburn: this is a resource that should respond to GET request

elf-pavlik: my understanding is that HTTP does not define whether 2 resources are the same or not; WebArch allows several URIs to identify the same resource
… there is no assumption when we say "resource" that we are making it distinct from any other resource

pchampin: "storage description" is not the nature of the resource, it is its role

gibsonf1: we are specifying a very specific kind of representation, that what we should say

laurens: yes, the representation format is the spec part; but what we are specifying is the representation of *a resource*

acoburn: let's move on to "storage workspace"

termontwouter: following pchampin's suggestion, the workspace is singular when the storage is a a whole

pchampin: then the term "root" might actually be more appropriate; "workSPACE", as laurens's question earlier shown, may give the impression of a "whole"

ryey: does a storage root imply that the storage is a tree?

acoburn: in many places in the space, we talk about a hierarchical tree, so yes

ryey: does that involve some changes in the description of multiple-containment?

acoburn: we are not there yet, but I don't think we are going to specify multiple containment

[wordsmithing the definition of "Storage Root"]

acoburn: let's move on to "Container"

laurens: we have had multiple discussions about whether a container can also be a data resource. I would like to solve this.
… It adds complexity over operations that govern containers. It would make it simpler to split the two.
… There might be implementations that want to allow a resource to be both; we should maybe provide some leeway for that.

<Zakim> termontwouter, you wanted to replace containers by collections with multiple hierarchies

laurens: But operations on data resources and containers are very close, so I'm a bit worried.

termontwouter: it is difficult if you start by considering them as separate.

jeremycaine: what is special about data resources vs. containers?

acoburn: the difference is that a data resource is entirely controlled by a client.
… complexity starts when you allow a container to have some part managed by the client, and some part managed by the server

termontwouter: it is not completely true; the server adds some metadata that a client can modified

gibsonf1: about this implementation issue of managing the data: whenever you have a file on a server, some server-managed metadata are associated to the file
… so this mix occurs all the time
… this separation would make a big change from Solid

<Zakim> acoburn, you wanted to talk about the difficulties of composite resources

gibsonf1: I don't see this as a simplification, but as making things more complex

acoburn: I have worked on a number of Solid / LPDish implementation.
… composite resources come with a lot of problems. E.g. ETAGs (what changes are you measuring?)
… For very large containers, we want a paging mechanism; where would the additional properties go? first page? every page?
… Currently, in Solid or Fedora, you have a place where you can put additional metadat.
… You can include them in the main description using preferred headers.

gibsonf1: acoburn, I appreciate what you are saying.
… we have in production a system where each triple has permissions, everyone sees different triples based on their permissions
… if you make this distinction between containers and data resources, you are preventing us from being compliant

pchampin: let's be careful with "user-managed" vs "server-managed"; things are more nuanced

<gibsonf1> It would be impossible to get data resource json about a container if you seperate these this way

termontwouter: acoburn's arguments are about it is difficult to implement, but gibsonf1 reports that they have an implementation

acoburn: to respond to that; for me the challenge is to reuse the URL of the container itself to make user-defined changes
… there are other ways to manage user-managed data in the container representation

<Zakim> elf-pavlik, you wanted to consider what gets surfaced to UX

elf-pavlik: mixing containment triples with user-managed triples has a long history of being painful
… it boils down to priority of constituents: on whom we put the burden
… there should be a way for the user to define a collection around a container

gibsonf1: the key issue is: if I do a GET on a container, I want the containment triples + additional data
… it is game over for us here, it is a big deal
… I understand what acoburn's point about how implementations would solve it; some implementations might not support it, but those who do must be able to do it

<TallTed> What we need to do is restrict only as much as necessary, permitting other things to "extend" or otherwise work differently yet similarly.

<TallTed> I look forward to tomorrow's presentation of the grand unification proposal that gets developed during conversation over dinner & drinks tonight. :-)

laurens: to propose a way forward, we could continue with the spec as it is (operations on data resource and on containers)

<Zakim> pchampin, you wanted to suggest a middleground

laurens: implementations could introduce additional operations on containers (we need to check how that's possible)

<Zakim> termontwouter, you wanted to summarize w3c/lws-protocol#116

laurens: some servers could accept "data resource operations" on a containers, but I would refrain from specifying it

jeswr: gibsonf1 what is preventing you from doing what you want with a metadata resource?

gibsonf1: if I do a GET on a container, currently I can't get the additional data

laurens: you can! Nothing prevents you from including that data in the container's JSON-LD
… the set of attributes at the resource level is extensible

pchampin: take it the other way around, if you get json ld the way your app is expecting.... it depends how you look at it
… what laurens is describing, you can look at it as using your original description plus lws container desc

gb: i don't want two requests

pchampin: this is possible i don't see what would prevent it

dinner location: Granary Square Brasserie