14:58:26 <RRSAgent> RRSAgent has joined #lws
14:58:30 <RRSAgent> logging to https://www.w3.org/2025/02/10-lws-irc
14:58:30 <Zakim> Zakim has joined #lws
14:58:40 <acoburn> zakim, start meeting
14:58:40 <Zakim> RRSAgent, make logs Public
14:58:42 <Zakim> please title this meeting ("meeting: ..."), acoburn
14:58:46 <eBremer> eBremer has joined #lws
14:58:47 <acoburn> meeting: Linked Web Storage
14:58:52 <acoburn> chair: acoburn
14:59:38 <hadrian> hadrian has joined #lws
14:59:41 <eBremer> present+
15:00:06 <acoburn> present+
15:00:23 <pchampin> present+
15:02:09 <acoburn> -> https://github.com/w3c/lws-protocol/wiki/Scribe-list Scribe list
15:02:41 <bendm> bendm has joined #lws
15:02:51 <csarven> present+
15:03:05 <bendm> present+
15:03:32 <ryey> ryey has joined #lws
15:03:35 <ryey> present+
15:04:03 <acoburn> scribenick: csarven
15:04:19 <hadrian> present+
15:05:06 <acoburn> present: ericP
15:05:52 <pchampin> RRSAgent, make minutes
15:05:54 <RRSAgent> I have made the request to generate https://www.w3.org/2025/02/10-lws-minutes.html pchampin
15:06:01 <acoburn> RRSAgent, make minutes
15:06:02 <RRSAgent> I have made the request to generate https://www.w3.org/2025/02/10-lws-minutes.html acoburn
15:06:18 <eBremer> present+
15:06:19 <hadrian> present+
15:06:21 <csarven> present+
15:06:22 <pchampin> present+
15:06:23 <acoburn> present+
15:06:24 <bendm> present+
15:07:02 <acoburn> agenda?
15:07:34 <TallTed> TallTed has joined #lws
15:07:38 <acoburn> RRSAgent, make minutes
15:07:40 <RRSAgent> I have made the request to generate https://www.w3.org/2025/02/10-lws-minutes.html acoburn
15:08:29 <pchampin> agenda: https://www.w3.org/events/meetings/a19ab7dc-1753-433d-bac5-64e3ad8c0a43/20250210T100000/#agenda
15:08:30 <agendabot> clear agenda
15:08:30 <agendabot> agenda+ Introduction and Announcements
15:08:30 <agendabot> agenda+ Pending -> Action Items https://github.com/w3c/lws-protocol/issues?q=is%3Aopen+is%3Aissue+label%3Aaction
15:08:30 <agendabot> agenda+ Glossary for Use Cases
15:10:19 <pchampin> zakim, open agendum 1
15:10:19 <Zakim> agendum 1 -- Introduction and Announcements -- taken up [from agendabot]
15:11:00 <jeswr5> jeswr5 has joined #lws
15:11:13 <jeswr5> present+
15:11:28 <TallTed> TallTed has changed the topic to: Linked Web Storage WG -- 2025-02-10 agenda: https://www.w3.org/events/meetings/a19ab7dc-1753-433d-bac5-64e3ad8c0a43/20250210T100000/#agenda
15:11:36 <TallTed> previous meeting: https://www.w3.org/2025/02/03-lws-minutes.html
15:11:38 <TallTed> next meeting: https://www.w3.org/2025/02/17-lws-minutes.html
15:11:39 <laurens> laurens has joined #lws
15:11:43 <laurens> present+
15:11:46 <TallTed> present+
15:11:49 <jeswr5> q+
15:11:57 <csarven> acoburn: To allow more folks to participate, we'll have 2 minute informal timelimit for conversations. Applies to chairs as well. Keep comments short, if possible. We'll reassess if it needs to change.
15:12:14 <TallTed> RRSAgent, draft minutes
15:12:16 <RRSAgent> I have made the request to generate https://www.w3.org/2025/02/10-lws-minutes.html TallTed
15:12:22 <acoburn> ack next
15:12:55 <jeswr5> https://github.com/solid/odi-governance
15:13:09 <csarven> jeswr5: ODI has put out a propose governance structure on getting Solid adopted and roadmap, and what ODI works on in relation to Solid. Open for comments until 2025-02-26 as an issue. URL: https://github.com/solid/odi-governance
15:13:33 <csarven> ... also gave presentation at State of Open Con: https://stateofopencon.com/
15:13:50 <balessan> balessan has joined #lws
15:13:50 <csarven> s/Open Con/Open Conference 25
15:14:07 <csarven> pchampin: Yes, it was interesting.
15:14:08 <balessan> present+
15:14:27 <acoburn> zakim, open agendum 2
15:14:27 <Zakim> agendum 2 -- Pending -> Action Items https://github.com/w3c/lws-protocol/issues?q=is%3Aopen+is%3Aissue+label%3Aaction -- taken up [from agendabot]
15:15:27 <csarven> acoburn: re https://github.com/w3c/lws-protocol/issues/14 , hadrian do you want to keep it open or?
15:15:27 <gb> https://github.com/w3c/lws-protocol/issues/14 -> Action 14 create a PR for the document to create a glossary (on hzbarcea) due 2025-02-10
15:15:46 <csarven> hadrian: Thanks pchampin for reviewing https://github.com/w3c/lws-ucs/pull/119
15:15:47 <gb> https://github.com/w3c/lws-ucs/pull/119 -> Pull Request 119 Template for requirements (by hzbarcea)
15:16:14 <csarven> ... in issue 14, I want to look at the structure of the document and align it with the others. I don't know if to keep it open. Neutral to that.
15:16:43 <csarven> ... most of the terms are there I think. Sarven asked for three more which I'm okay with. The list is not complete but I think it is complete with respect to major concepts.
15:16:59 <pchampin> q+
15:17:04 <csarven> acoburn: Definitely something in flight as work moving along. We can leave it open.
15:17:08 <dmitriz> dmitriz has joined #lws
15:17:11 <acoburn> ack next
15:17:16 <dmitriz> present+
15:17:19 <csarven> hadrian: Agree to keep it open. Needs to go into the document but can change.
15:18:00 <csarven> pchampin: Suggest to close issue 14. Basically it is worth to keep two issues open on the same topic. Confusing perhaps. It is created in lws-ucs repo and so close the one in lws-protocol
15:18:18 <csarven> acoburn: If we close this, we can spend less time going over it. Good idea.
15:18:31 <csarven> ... Any other comments on that? or opposed to closing it?
15:18:36 <csarven> ... I will close it.
15:19:28 <csarven> Re https://github.com/w3c/lws-protocol/issues/13 , what's next?
15:19:29 <gb> https://github.com/w3c/lws-protocol/issues/13 -> Action 13 define a requirements template for the lws-ucs repository (on hzbarcea) due 2025-02-03
15:19:46 <csarven> hadrian: I have to re-review but don't know who supposed to merge. Don't know the process.
15:19:58 <csarven> ... I think Sarven because he had some comments there.
15:20:52 <pchampin> scribe+
15:21:15 <pchampin> csarven: no objection to close issue #13 or merging lws-ucs#119 with pchampin's suggestions
15:21:16 <gb> https://github.com/w3c/lws-ucs/pull/119 -> Pull Request 119 Template for requirements (by hzbarcea)
15:21:16 <gb> https://github.com/w3c/lws-protocol/issues/13 -> Action 13 define a requirements template for the lws-ucs repository (on hzbarcea) due 2025-02-03
15:21:17 <csarven> csarven: No issue to close issue 13 or merging the associated PR based on pchampin 's suggestions, and improve.
15:21:25 <pchampin> scribe-
15:21:27 <csarven> scribe+
15:21:45 <csarven> acoburn: Re https://github.com/w3c/lws-protocol/issues/11 , do we want to open / discuss or track elsewhere?
15:21:46 <gb> https://github.com/w3c/lws-protocol/issues/11 -> Action 11 add categorization to the needs discussion labeled issues (on hzbarcea) due 2025-01-13
15:22:58 <csarven> ... if we keep these action items lightweight, we can move quicker. I'll clean this up after the meeting, unless pchampin or others want to comment.
15:23:09 <acoburn> q?
15:23:10 <csarven> ... Please add links to relevant issues where the conversation is continuing.
15:23:27 <acoburn> zakim, open agendum 3
15:23:27 <Zakim> agendum 3 -- Glossary for Use Cases -- taken up [from agendabot]
15:23:48 <csarven> acoburn: Re https://github.com/w3c/lws-ucs/issues/122
15:23:49 <gb> https://github.com/w3c/lws-ucs/issues/122 -> Issue 122 Glossary draft (by hzbarcea) [needs-discussion]
15:24:21 <csarven> ... This is about having a glossary. Critical both for the Protocol and defining the UCs that would go into the Protocol.
15:24:49 <csarven> ... Making sure we have consensus on this is key. I'd like to nail this down on where we have consensus and where we differ, going, or reaching..
15:25:07 <csarven> ... Everyone, if you haven't read already, please do.
15:25:56 <csarven> hadrian: After I did this issue, I went through the UCs issues again to cover important concepts. Hope to accept issue on global context (117).
15:26:12 <csarven> ... If someone has a better term, please suggest. We want to have a good story and communicate to the audience.
15:26:40 <csarven> ... The notion of identifier which is globally unique identifier of something. There is no description because I have to think more and propose something, or others.
15:26:51 <csarven> ... Profile is common, WebID, DID etc.. that has to exist somehow.
15:27:26 <acoburn> q?
15:27:56 <csarven> ... Profile Address is via discovery or convention. While identifiers referring to identities... when I say identifiers I mean related to identities. We have to make a distinction between these notions.
15:28:03 <bendm> q+
15:28:05 <csarven> ... Entity interacts with storage infra in general.
15:28:23 <csarven> ... User has rights to authorize all decisions
15:28:58 <acoburn> ack next
15:29:19 <csarven> bendm: Should we clarify what an identity is? Is identity is a identifier + profile document?
15:29:36 <csarven> hadrian: Identity is collection of things that can be stated about entity. That is captured in profile document in this case.
15:29:59 <csarven> ... These are concepts we'll discuss in more detail. I didn't want to have a long conversation today. Perhaps most important, but you're right.
15:30:16 <acoburn> q+ to ask about profile document in the context of existing specifications
15:30:36 <csarven> ... Identity is defined by the profile document which has a global identifier associated with it. The location of the document can be found one or more addresses associated with that identifier. Discovered by some mechanism to be defined at some point.
15:30:47 <csarven> bendm: I suspect this will be added to the glossary draft.
15:30:52 <pchampin> s|agendum 3 -- Glossary for Use Cases -- taken up [from agendabot]|agendum 3 -- [Glossary for Use Cases](https://github.com/w3c/lws-ucs/pull/122) -- taken up [from agendabot]
15:30:58 <pchampin> RRSAgent, make minutes
15:30:59 <RRSAgent> I have made the request to generate https://www.w3.org/2025/02/10-lws-minutes.html pchampin
15:31:05 <csarven> hadrian: If anyone has a proposal, add it there.
15:31:12 <acoburn> ack next
15:31:13 <Zakim> acoburn, you wanted to ask about profile document in the context of existing specifications
15:31:53 <csarven> acoburn: re Profile Document, some existing specs have definitions for it. I'm assuming we'll want this to a lot of different kids of entities. In some cases, what currently exists in specs and otherwise we define. Is that a general rule of understanding?
15:32:49 <pchampin> q+
15:33:06 <csarven> hadrian: Right. We might make some suggestions but what's accepted or not is in the spec. Personally, I have had some conversations in past weeks. Such a LWS Storage being holding one profile document for authn and authnz as well. Another kind of trusted authz mechanism.
15:33:13 <acoburn> ack next
15:33:40 <csarven> pchampin: A few things may be too specific for the stage we are in.
15:34:03 <csarven> ... e.g., only human users having right to authorise. Perhaps too early and needs to be only in the spec.
15:34:15 <dmitriz> might it be easiest for us to just re-use the 'Entity' definition that's used by the OpenID / OAuth specs?
15:35:01 <csarven> ... The distinction re identifier and address, I can see it being useful but it is a relative distinction. We don't have the same opinion e.g. HTTP URI as identifier/address. It could be seen as stable identifier. But of course at another level of analysis it is not that stable, it is kind of an address. I think things can... it can be a grey area.
15:35:41 <csarven> hadrian: The authorization piece with users, it needs to go with accountability. If you have non-human entity to authorize it might not be accountable.
15:35:45 <csarven> q+
15:35:56 <csarven> ... But I think ultimately humans need to be responsible for it.
15:36:51 <csarven> ... The addresses, I don't think the difference of opinion is as I understand what you're saying. If you move from one ISP to another. You can't put burden on the ISP to put the forward. If I have my own domain, then you can say it is my own and control over it, and I agree with you. The quetsion is do we put everyone on their own domain.
15:37:06 <csarven> acoburn: I think at this point we may be rabbitholing..
15:37:25 <acoburn> ack next
15:37:27 <csarven> hadrian: That's exactly why I didn't want to discuss too much for now.
15:37:29 <pchampin> hadrian, re. accountability: I'm not questioning the choice; I just think it is not the role of the glossary to express this kind of constraint
15:37:41 <pchampin> scribe+
15:37:59 <pchampin> csarven: I agree with hadrian about acountability, this is an important point.
15:38:27 <pchampin> ... If the notion of accountability is in the UC, then I'm behind that idea. If it is not, we should add it!
15:38:38 <pchampin> s/acountability/accountability
15:38:47 <acoburn> +1 on having accountability (or trust) in the use cases
15:38:55 <pchampin> scribe-
15:40:35 <csarven> hadrian: Service / Service Provider, specific features and entity providing it respectively.
15:40:45 <csarven> ... We might want to associate identities to these services.
15:41:37 <csarven> ryey: re Services, do we have a notion for apps? Do we not want to have it?
15:41:46 <csarven> hadrian: It is further down the list.
15:41:51 <csarven> ryey: Seems different.
15:42:02 <csarven> hadrian: They are organised this way because of the dependencies of the concepts.
15:42:47 <bendm> q+
15:42:48 <csarven> hadrian: Identity Service / Provider, are well understood terms.
15:42:58 <acoburn> q+
15:42:59 <csarven> ... Relying Party, ditto.
15:43:08 <acoburn> ack next
15:43:36 <csarven> bendm: Re concept of authorization, but not authorization service, it is kind of in storage in Solid. Shouldn't we then also have that as part of the glossary?
15:44:25 <csarven> hadrian:Uhhhh yeaaaaah. Uhmm. Hmm. I could argue either way. Definitely have to have it. Let's add it. The question is how specific do you want to become. I prefer not to be too specific at this point as also mentioned by pchampin.
15:44:34 <csarven> bendm: I would not conflate authn/z though.
15:44:50 <jeswr> jeswr has joined #lws
15:44:55 <pchampin> q+
15:45:01 <csarven> hadrian: I could present a doc that would authorise me ??? But maybe I didn't understand your question well.
15:45:26 <csarven> bendm: The glossary seems more like a definition of functionality but not necessarily how things work. That's why I would add the service.
15:45:53 <csarven> hadrian: I agree with you, will add it. However, I think it should be possible to be optional. Authorise without necessarily authorization service.
15:46:10 <acoburn> ack next
15:46:12 <csarven> q+
15:47:02 <csarven> acoburn: In your list you are defining but also the trust relations. In e.g. GNAP they have definition of entities and the trust relationships. So, would be good to keep the concepts separate and allow to think better.
15:47:09 <acoburn> q?
15:47:18 <acoburn> ack next
15:47:28 <bendm> +1 on representing the trust relationships complementary to the entity
15:47:53 <csarven> pchampin: re bendm's comment, to make an alternative proposal, authn/z. Could be realised by service or otherwise.
15:48:06 <acoburn> q?
15:48:07 <csarven> hadrian: There are a lot of lot of minor implied things. Generally agree.
15:48:17 <acoburn> ack csarven
15:48:18 <pchampin> scribe+
15:48:55 <pchampin> csarven: a reminder: this is a sample of concepts that seem significant. They don't necessarily reflect what will be in the spec.
15:49:26 <acoburn> q?
15:49:27 <pchampin> ... If some use case calls for an authentication service, then it can be added.
15:49:43 <pchampin> ... Let's not try to refine the UCs into precise requirements and terms right now.
15:49:49 <pchampin> scribe-
15:50:36 <csarven> hadrian: Storage, it is however we define it. Repository owned by an entity. Service of it and the Provider making it available.
15:50:59 <csarven> ... Application accessing storage or other services.
15:51:22 <csarven> ryey: re Storage, for the Storage Provider, are we talking about the LWS storage provider or underneath, e.g., the cloud service.
15:51:47 <csarven> hadrian: I'm talking about more of the URL, the identity, the organisation that has the legal has the role, custody, and also related to trust.
15:51:52 <acoburn> q+ to mention scope and API
15:52:15 <csarven> ryey: Is the provider of the Storage service rather than ???
15:52:32 <csarven> hadrian: it is like GitHub for git repositories.
15:52:39 <csarven> ryey: As in not the physical machines?
15:52:52 <csarven> hadrian: At least not in this definition. That can be perhaps for the service.
15:52:58 <acoburn> q-
15:53:11 <csarven> ... One for tech and one for operator.
15:53:23 <csarven> ryey: There is a diff relying on their relationship and what's stated in the issue.
15:53:49 <csarven> hadrian: Notification service is another service.
15:54:01 <csarven> ... Roles, there are a bunch listed and probably more.
15:54:18 <csarven> acoburn: Noting that dmitriz mentioned owner instead of controller.
15:54:36 <csarven> hadrian: Agree but in these circles the owner term used mostly but ack and personally sympathise with it.
15:54:38 <bendm> +1 to change to controller instead of owner
15:54:45 <dmitriz> the VC group /started/with "owner". and then renamed to "controller" (and had to rename a bunch of code/specs)
15:54:53 <csarven> q+
15:55:05 <pchampin> scribe+
15:55:14 <acoburn> ack next
15:55:54 <ryey> q+
15:55:59 <pchampin> csarven: from the Web architecture perspective, "owner" and "controller" would be synonymous.
15:56:12 <pchampin> ... But from a legal perspective, they would need to be distinguished.
15:56:12 <dmitriz> @csarven - that's a good point, that we COULD have both. but I haven't seen any use for "owner" as separate from controller
15:56:13 <gb> https://github.com/csarven -> @csarven
15:56:13 <csarven> https://www.w3.org/TR/webarch/#def-uri-ownership
15:56:55 <ryey> q-
15:56:57 <pchampin> ... Do we have time for the terms I proposed to add?
15:57:11 <pchampin> acoburn: I'd rather discuss them next week.
15:57:32 <pchampin> RRSAgent, make minutes
15:57:33 <RRSAgent> I have made the request to generate https://www.w3.org/2025/02/10-lws-minutes.html pchampin
15:58:07 <acoburn> acoburn has left #lws
15:58:15 <pchampin> present+ ryey
15:58:16 <pchampin> RRSAgent, make minutes
15:58:18 <RRSAgent> I have made the request to generate https://www.w3.org/2025/02/10-lws-minutes.html pchampin
15:58:26 <csarven> s/from controller/from controller. If the UCs e.g., distinguish re legal/policy owner from technical controller, we can have both, or other descr.