08:11:44 RRSAgent has joined #lws 08:11:48 logging to https://www.w3.org/2026/04/27-lws-irc 08:12:28 acoburn has changed the topic to: Linked Web Storage WG - 2026-04-27 - https://www.w3.org/events/meetings/fed3ebd2-1330-4853-8ec4-12442c47e32c/ 08:12:44 zakim, start meeting 08:12:44 RRSAgent, make logs Public 08:12:46 please title this meeting ("meeting: ..."), acoburn 08:13:07 agenda: https://www.w3.org/events/meetings/fed3ebd2-1330-4853-8ec4-12442c47e32c/#agenda 08:13:09 acoburn, sorry, I did not recognize any agenda in https://www.w3.org/events/meetings/fed3ebd2-1330-4853-8ec4-12442c47e32c/#agenda 08:13:32 zakim, open agendum 1 08:13:32 agendum 1 -- Introduction and announcements -- taken up [from agendabot] 08:13:36 termon has joined #lws 08:13:37 termon has left #lws 08:13:42 present+ 08:13:57 termontwouter has joined #lws 08:14:40 rrsagent, make minutes 08:14:42 I have made the request to generate https://www.w3.org/2026/04/27-lws-minutes.html acoburn 08:14:50 present+ 08:14:54 present+ termontwouter 08:15:01 present+ jeswr 08:16:40 ryey has joined #lws 08:16:46 present+ 08:16:47 eBremer has joined #lws 08:16:55 present+ 08:17:04 uvdsl has joined #lws 08:17:43 jeremycaine has joined #lws 08:18:11 bendm has joined #lws 08:18:17 present+ 08:18:51 acoburn has joined #lws 08:27:49 present+ 08:29:07 rrsagent, make minutes 08:29:08 I have made the request to generate https://www.w3.org/2026/04/27-lws-minutes.html acoburn 08:30:25 jeswr1 has joined #lws 08:32:31 elf-pavlik has joined #lws 08:32:47 present+ 08:32:57 rrsagent, make minutes 08:32:58 I have made the request to generate https://www.w3.org/2026/04/27-lws-minutes.html acoburn 08:33:29 present+ 08:33:45 scribenick: jeswr 08:34:01 elf-pavlik0 has joined #lws 08:34:55 acoburn: I would like to propose that we do not change our scope 08:35:52 termontwouter: Lets not widen, but lets clarify the scope as there is consistently debate 08:36:27 ... this may resolve ongoing discussions around containers and query 08:36:32 Charter -> https://www.w3.org/2024/09/linked-web-storage-wg-charter.html 08:37:19 laurens: Agree, lets expand out of scope section 08:37:42 ... one aspect I want out of scope is access control 08:38:10 ... in-scope I want to brush up the UC&R documents and reference that in the re-chartering 08:38:42 eBremer: I agree with all that has been said. Something new would have to be critical. 08:39:14 elf-pavlik has joined #lws 08:39:28 ... Can we have a plan for the future (what is in 1.1, 1.2) 08:39:34 q+ 08:39:43 acoburn: What we need in 1.0 is publication of a TR document 08:40:33 ... 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. 08:41:34 ... working backwards. CR status by September. Then 1 year for TR, 1 year for maintenance. 08:42:33 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 08:43:27 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. 08:43:29 q+ to talk about incubation 08:43:54 elf-pavlik: Is that a new charter or re-charter 08:44:05 laurens: It depends. VC did a re-charter for 2.0. 08:44:54 ack next 08:45:22 jeremycaine: Lets have a diagram showing access control implemented by an external service to 1.0, and then in scope for 1.1 08:45:39 elf-pavlik: Is threat modelling in scope for 1.0 08:46:08 laurens: Yes. However, we lack volunteers willing to work on this. 08:47:24 eBremer: Can we have a rough overview of the next 5 years. Does not need to be detailed plan. 08:47:33 ack next 08:47:34 acoburn, you wanted to talk about incubation 08:47:43 laurens: Yes we can 08:48:43 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. 08:49:25 ... So let's define the core boundaries in a clear and compelling way 08:49:36 q+ to talk about the role of the Solid CG 08:50:05 q+ to talk about supporting role of ODI 08:51:09 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? 08:51:21 ack laurens 08:51:21 laurens, you wanted to talk about the role of the Solid CG 08:51:30 acoburn: Yes. The goal is to get to 1.0 1 year after the current charter ends. 08:51:36 q+ to ask about scope about recharter (esp. optional items such as access control) 08:52:22 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 08:52:29 acoburn has joined #lws 08:52:33 q+ to suggest prioritized list of items in scope 08:52:34 ... we still need to define what such a pipeline would look like 08:53:02 jeswr: ODI can support this. At the moment we're setting up Solid26 08:53:13 ... as an implementers guide to the Solid specification. 08:53:24 ... ODI is helping to develop a feedback model. 08:53:37 ... That feedback can be triaged and fed into CG, WG, ... 08:54:18 q? 08:54:19 ... Some of the enterprise-oriented feedback might feed into e.g. Inrupt, IBM, OpenLink, Trinpod, ... 08:54:37 ... This would help the adoption of the technologies. 08:54:48 ack next 08:54:49 jeswr, you wanted to talk about supporting role of ODI 08:54:59 ack next 08:55:00 ryey, you wanted to ask about scope about recharter (esp. optional items such as access control) 08:56:05 ryey: What are we allowed to do in a re-charter. Can we keep rechartering through to an LWS 1.5 08:56:30 acoburn: An administrative re-charter should have no change in scope. A full re-charter can be whatever we like subject to AC approval. 08:56:57 ... There are therefore two things to consider. What we want as a group, and what we think will get approval. 08:57:32 ryey: Is the proposal that we do not define access control in 1.0 08:57:45 acoburn: Yes, that is what laurens suggested 08:58:21 q+ question about external acl specification 08:58:31 ryey: If we lack acl, will people think LWS is not mature 08:58:37 eBremer has joined #lws 08:58:42 present+ 08:59:07 q+ to ask about external acl specification 08:59:09 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 08:59:50 ... 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 09:00:06 ... for 1.0 I would avoid the complexity of defining access control rules 09:00:41 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. 09:00:50 ryey: I agree. 09:01:25 ... Is there a practise of showing recommended implementations? 09:02:17 acoburn: Implementation reports can describe what implementations support 09:02:43 q+ to ask about scoping of authentication 09:02:45 ... with a matrix of features and implementations 09:03:33 q? 09:03:41 ack next 09:03:42 elf-pavlik, you wanted to suggest prioritized list of items in scope 09:04:31 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. 09:05:00 ... as we also need implementations and test suites. Not just the spec document. 09:05:41 laurens: We have the notion of tentative deliverables. The FedID group did this. 09:06:51 acoburn: Yes, and so lets clarify whats in and out. Currently Access Requests, Notifications, Containers, Terminology, Type Index, and Metadata 09:07:02 ... are on the table in the group 09:07:53 bendm: Do we have a full picture of how mature and what the features of these are 09:08:47 acoburn: The table of contents of https://w3c.github.io/lws-protocol/lws10-core/ gives this 09:09:39 ... authentication and authorisation: says oauth is baseline and you can do other things 09:09:56 ... discovery: Storage description document 09:10:42 laurens: We then have access requests & grants, notifications and type indexes 09:10:56 ... currently access requests & grants require notifications 09:11:03 ... type indexes are most at risk 09:11:33 ericP has joined #lws 09:11:40 present+ 09:11:59 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 09:12:09 ... we may decide to drop one and have all 3 09:12:54 ... 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. 09:13:14 we could have access grants without notifications 09:13:19 bendm: There is a fine line between access requests, and access controls 09:13:23 q? 09:13:27 ack next 09:13:28 jeremycaine, you wanted to ask about external acl specification 09:14:07 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 09:14:39 acoburn: Yes, access requests are higher level. Everything that you can do in access requests, can also be done with an access control language. 09:14:55 ... so the question is what is a minimal high level interface for agents to request acess. 09:15:02 ... that is the extent of the scope of that feature 09:15:04 q+ 09:15:18 bendm: I understand that in there we could have a hook to an access control language 09:16:03 termontwouter has joined #lws 09:16:13 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 09:16:41 ... 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 09:18:12 jeswr: Could we not take the ODRL profile we have for access requests and make that our access control language for 1.0 09:19:20 ... or at least an access control profile for LWS 09:19:53 acoburn: Yes we could 09:20:47 jeremycaine: Is access control any easier or harder than the way you have defined containers 09:21:24 scribe+ 09:22:15 jeswr: will need multiple access profiles for the different uses cases 09:23:07 ... what LWS currently does, this is the interface by which you can modify access control 09:23:45 acoburn: for certain use cases there are needs for complicated accesstrol policies 09:23:59 ... but if we define that level of complexity for everyone its a real burden 09:24:11 q? 09:24:12 q+ 09:24:30 ... 80% could get by with something simple and straightforward without everyone doing some complicated arcane structure 09:24:50 jeremycaine: if you make it too simple, it wont work for an enterprise example 09:25:19 acoburn: exactly. so for the group to leave out of scope or make it an implemntation detail 09:25:36 ... anything related to security...it is a constantly moving target 09:25:50 q? 09:25:50 ... in 2years, may be so out of data leaving LWS not so useful 09:25:58 ack termontwouter 09:25:58 termontwouter, you wanted to ask about scoping of authentication 09:26:35 termontwouter: Given that we put access control out of scope, how does the authentication method still relate it 09:27:49 present+ 09:27:52 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. 09:28:07 ... What we describe in the specs today says if you are using OAuth, use it correctly 09:28:32 ... Other challenges could come back (e.g. GNAP, UMA, etc.) but that is not a requirement of LWS. 09:28:57 ... You could also support HTTPSig 09:29:25 s/accesstrol/access control 09:29:38 termontwouter: Whatever the choice of mechanism, why define ??? 09:30:08 acoburn: This is the balance between having enough guidance for interop, whilst also leaving things open-ended to build upon 09:31:15 ... so we are giving profiles (e.g. OpenID, SAML, Server side agents) 09:32:07 ... which are rec track documents. Servers are not required to implement any of the specific profiles. 09:33:02 q+ to mention evolution of specs 09:33:05 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 09:33:12 ack jeswr 09:33:22 ack next 09:33:45 laurens: The larger we make the specification in terms of MUSTs, the more complicated we make it to define implementations 09:34:17 ... what we have seen with Solid in the past is that there was a big surface to cover on the server side 09:34:29 ... whilst our use-cases were much smaller than what was defined 09:34:38 ... and this cost did not end up benefitting adoption 09:35:53 ... 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 09:36:02 q+ 09:36:03 ack next 09:36:04 elf-pavlik, you wanted to mention evolution of specs 09:36:41 q- 09:36:47 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. 09:37:10 ... having that mechanism is more important than one specific suite 09:37:49 q? 09:37:51 woutertermont: 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 09:39:03 elf-pavlik: So you use something like a WWW-authenticate header to determine what the authentication method is 09:39:58 termontwouter has joined #lws 10:04:08 gibsonf1 has joined #lws 10:04:13 present+ 10:04:36 jeremycaine has joined #lws 10:04:36 acoburn: summarizes previous hours 10:05:08 ... Let's wrap up the scope, timeframe, and mechanics for a possible extension 10:05:47 elf-pavlik has joined #lws 10:06:00 ... Scope: delineate the currently open-ended scope; emphasize what's IN and what is OUT 10:06:52 pchampin: By declaring the scope closed, we would need to recharter if afterwards we already want to move on. 10:07:51 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'. 10:08:05 elf-pavlik: Which specific documents? 10:08:25 acoburn: All the rec-track ones 10:08:55 ... we can always descope things if they become at risk 10:09:12 bendm: Is it common to have a year of maintenance mode? 10:10:30 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. 10:11:02 s/dormant.It/dormant. It/g 10:12:52 bendm: Then we can also list features that we want to keep possible in 1.0 without actually specifying it yet? 10:13:27 acoburn: Yes. In particular what other specifications could possibly take up separately. 10:14:22 ... Let's write this down as a proposal; summarized, not rewriting the charter right now. 10:15:37 RRSAgent, make minutes 10:15:39 I have made the request to generate https://www.w3.org/2026/04/27-lws-minutes.html pchampin 10:17:33 bendm: Maybe we should also add the decision to aim for a recharter. 10:19:55 acoburn has joined #lws 10:20:00 scribe+ 10:22:21 s/woutertermont/termontwouter/ 10:23:01 ryey has joined #lws 10:23:50 PROPOSAL: The LWS WG will pursue an administrative extension in order to focus on working on a new charter document. 10:23:58 q? 10:24:02 +1 10:24:02 +1 10:24:03 elf-pavlik has joined #lws 10:24:04 +1 10:24:09 +1 10:24:10 +1 10:24:12 +1 10:24:18 +1 10:24:19 +1 10:24:21 +1 (guest) 10:24:22 +1 10:24:32 RESOLVED: The LWS WG will pursue an administrative extension in order to focus on working on a new charter document. 10:24:36 +1 10:24:40 +1 10:24:54 PROPOSAL: The LWS WG will focus on the current deliverables during the remainder of the existing charter 10:24:59 +1 10:25:00 +1 10:25:00 +1 10:25:01 +1 10:25:01 +1 10:25:01 +1 10:25:02 +1 10:25:04 +1 10:25:08 +1 10:25:09 + 10:25:12 +1 10:25:12 +1 (guest) 10:25:18 RESOLVED: The LWS WG will focus on the current deliverables during the remainder of the existing charter 10:25:30 PROPOSAL: The next LWS WG charter will focus on reaching REC status for version 1.0 10:25:34 +1 10:25:35 +1 10:25:37 +1 10:25:37 +1 10:25:37 +1 10:25:38 +1 10:25:38 +1 10:25:39 +1 10:25:41 +1 (guest) 10:25:48 +1 10:25:53 RESOLVED: The next LWS WG charter will focus on reaching REC status for version 1.0 10:26:06 PROPOSAL: The next LWS WG charter will include a maintenance period 10:26:08 +1 10:26:10 +1 10:26:10 +! 10:26:11 +1 10:26:11 +1 10:26:11 +1 10:26:12 +1 10:26:13 +1 10:26:14 +! 10:26:15 +1 10:26:15 +1 (guest) 10:26:16 +1 10:26:35 RESOLVED: The next LWS WG charter will include a maintenance period 10:26:44 PROPOSAL: The timeframe goals for LWS deliverables includes: CR by Fall 2026, TR by Fall 2027 10:26:45 +1 10:26:46 +1 10:26:47 +1 10:26:47 +1 10:26:49 +1 10:26:49 +1 10:26:49 +1 10:26:51 +1 10:26:51 +1 10:26:53 +1 10:26:53 +1 (guest) 10:26:55 +1 10:27:02 RESOLVED: The timeframe goals for LWS deliverables includes: CR by Fall 2026, TR by Fall 2027 10:27:28 acoburn: Let's move on to the next topic, which is Access Requests 10:29:38 q+ 10:31:33 zakim, open agendum 3 10:31:33 agendum 3 -- Container features and proposals -- taken up [from agendabot] 10:31:56 agenda? 10:32:34 agenda: https://www.w3.org/events/meetings/fed3ebd2-1330-4853-8ec4-12442c47e32c/#agenda 10:32:34 acoburn, sorry, I did not recognize any agenda in https://www.w3.org/events/meetings/fed3ebd2-1330-4853-8ec4-12442c47e32c/#agenda 10:32:54 topic: Access Requests 10:33:17 s/agendum 3 -- Container features and proposals -- taken up [from agendabot]/ 10:33:37 Access Requests PR -> https://github.com/w3c/lws-protocol/pull/106 10:33:38 https://github.com/w3c/lws-protocol/pull/106 -> Pull Request 106 Add editors draft for LWS Access Requests and Access Grants (by acoburn) 10:34:45 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. 10:35:05 RRSAgent, make minutes 10:35:06 I have made the request to generate https://www.w3.org/2026/04/27-lws-minutes.html termontwouter 10:35:50 acoburn: The (currently separate) document does three things 10:36:15 ... it allows the actor to request access to resources 10:36:50 ... it defines the semantics of a grant to do specific actions on resources 10:37:30 ... and it defines how to specify profiles that use this model with a specific policy language. 10:38:47 ... The examples use JSON-LD, but the data model is completely abstract, separate from any serialization. 10:39:28 scribe+ 10:41:28 acoburn: The high level model of a request consists of a type, a notification inbox, a storage identifier, and an array of access objects 10:42:21 q+ to ask about target 10:42:28 eBremer: We should make clear that JSON-LD arrays are unordered. 10:43:38 acoburn: An access object defines what access is being requested, and is specified in the profile. 10:43:48 q+ to ask about storage (as recipient), see also https://github.com/w3c/lws-protocol/pull/106#discussion_r3009771501 10:43:53 ... I'd like to have some input on certain questions. 10:44:24 ... First, I wonder if hasPurpose should be part of the access object or of the request as a whole. 10:45:20 ... The rest of the access object consists of a target, an array of actions, and an array of constraints. 10:45:31 ack next 10:45:38 laurens: Are the constraints additive? 10:45:45 q+ to ask about specific profile identifier 10:45:50 acoburn: Yes 10:46:03 ack next 10:46:04 gibsonf, you wanted to ask about target 10:46:05 bendm: Can we do disjunctions as in ODRL? 10:46:25 acoburn: No, it is a subset. 10:46:32 gibsonf1: Why do we have a type on the target? 10:46:54 q+ for purposes; maybe also interplay of multiple access items (over same resource), and partial grants 10:47:54 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. 10:48:36 acoburn: We also might not know the exact URL, so we need an indication of how to interpret the values. 10:49:27 q+ 10:49:49 q- 10:50:06 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. 10:50:20 ... I would refrain from putting semantics about the resource in the access request. 10:51:43 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. 10:51:47 +1 from SAI access needs on only knowing type/shape 10:53:53 ... 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...). 10:54:48 gibsonf1: I understand the StorageResource type, but not the Container vs DataResource types. 10:55:05 q+ 10:55:39 ... It would be more helpful to have types like PhotoAlbum or Friends etc. 10:56:24 acoburn: I'd expect there to be other types. We kept this minimal because of the work on Type Indexes. 10:56:44 ... The three provided options are about literal locations, but this is not a requirement. 10:57:09 jeremycaine: I think we are mixing up type and metatype. 10:57:46 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`? 10:58:09 elf-pavlik: It is the type of targeting method, not the type of resource. 10:58:38 acoburn: Indeed, and this would also depend on the underlying policy language. 10:58:48 q? 10:58:52 +1 to ryey here, maybe the terms could be clearer in what their usage entail / what their goal is 10:59:51 +1 to clarify naming 10:59:53 uvdsl: Maybe we should rather define the types by the functionality you want to achieve. For example the container itself vs the child resources... 11:00:38 +1, this clarifies the fact that "type" captures the intent of the requester (and therefore how to interpret the "value") 11:00:56 Sure. Will do now 11:00:59 elf-pavlik has joined #lws 11:01:22 ack next 11:01:23 uvdsl, you wanted to ask about storage (as recipient), see also https://github.com/w3c/lws-protocol/pull/106#discussion_r3009771501 11:02:22 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. 11:02:44 ... Would this not better be modeled as the 'audience'? 11:03:03 +1 user centric flows 11:04:12 ... That would decouple it from the storage location, and allow user centric approaches where a grant gives access to resources on different storages. 11:04:18 I may have a different opinion than uvdsl of the "recipient" (already in queue) 11:04:45 acoburn: Good idea. Would this still be required? 11:04:57 uvdsl: I feel like it should. 11:05:21 pchampin: But this would be posted to the inbox which is discovered at the storage? 11:05:27 q? 11:05:30 acoburn: Not necessarily, that is just one option. 11:05:35 ack next 11:05:36 bendm, you wanted to ask about specific profile identifier 11:05:47 q- 11:06:39 ryey: My main reservation here is that as the recipient, why would it need to be present? 11:07:04 uvdsl: That is why 'audience' is a better concept here. 11:07:18 q+ to suggest defining storage manager term 11:07:59 ... Similarly, this would allow requests to be made without knowing the storage location (cf. Google Drive) 11:08:43 ... The main difference is that storage is a technical perspective. 11:09:11 ryey: There are arguments for both aspects. 11:09:43 uvdsl: The value of this 'audience' property could cater to both. 11:09:53 q+ to ask about terminology since 'storage' in the Terminology section of core spec; we are discussion enumeration of audience (storage, user etc) 11:09:57 ryey: Should that be a single value or an array? 11:10:02 q+ 11:10:19 acoburn: I'd think a single value 11:10:40 uvdsl: The audience of JWTs can be an array 11:12:00 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? 11:12:44 elf-pavlik: In SAI, grants are scoped to single storages, because they are used as credentials. 11:13:01 acoburn: But here grants are not used as credentials. 11:13:23 elf-pavlik: As long as they are never exposed to other storages, it's a possibility. 11:13:51 uvdsl: I think there is no issue with having an array in grants as well. 11:15:26 ... Though the authorization server would probably want to limit the audience of the grant to the specific storage. 11:17:30 ack pchampin 11:17:31 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. 11:18:34 uvdsl: But in the grant the same field was used as 'sender', or 'assigner'. 11:18:50 elf-pavlik: How would we use the value of such a field? That would be helpful. 11:19:41 acoburn: Storage was meant as a high-level scoping mechanism, as a 'realm' of data. 11:21:16 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. 11:22:36 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. 11:23:23 uvdsl: I'm fine with either, but maybe there are use cases that might require it. 11:23:39 acoburn: Worst case, one can emulate this with multiple requests. 11:23:42 elf-pavlik has joined #lws 11:23:56 q+ 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 11:24:18 bendm: What do we decide on the kind of audience? 11:25:08 scribe+ 11:25:21 termontwouter: if we want to allow this kind of broader, non-storage, audience 11:26:05 ... to support something like "I want to see all your photos (wherever they are stored)" to a user 11:26:11 ... what would the grant look like? 11:26:52 acoburn: imagine I have 5 different storage providers, and someone sends a request to see photo of my recent trips 11:27:05