Meeting minutes
<acoburn> Scribe list
Introduction and Announcements
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.
<jeswr5> solid/
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: solid/
… also gave presentation at State of Open Conference 25: https://
pchampin: Yes, it was interesting.
Pending Action Items
acoburn: re w3c/
<gb> Action 14 create a PR for the document to create a glossary (on hzbarcea) due 2025-02-10
hadrian: Thanks pchampin for reviewing w3c/
<gb> Pull Request 119 Template for requirements (by hzbarcea)
hadrian: 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.
… 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.
acoburn: Definitely something in flight as work moving along. We can leave it open.
hadrian: Agree to keep it open. Needs to go into the document but can change.
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
acoburn: If we close this, we can spend less time going over it. Good idea.
… Any other comments on that? or opposed to closing it?
… I will close it.
Re w3c/
<gb> Action 13 define a requirements template for the lws-ucs repository (on hzbarcea) due 2025-02-03
hadrian: I have to re-review but don't know who supposed to merge. Don't know the process.
… I think Sarven because he had some comments there.
csarven: no objection to close issue #13 or merging lws-ucs#119 with pchampin's suggestions
<gb> Pull Request 119 Template for requirements (by hzbarcea)
<gb> Action 13 define a requirements template for the lws-ucs repository (on hzbarcea) due 2025-02-03
csarven: No issue to close issue 13 or merging the associated PR based on pchampin 's suggestions, and improve.
acoburn: Re w3c/
<gb> Action 11 add categorization to the needs discussion labeled issues (on hzbarcea) due 2025-01-13
acoburn: 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.
… Please add links to relevant issues where the conversation is continuing.
Glossary for Use Cases
acoburn: Re w3c/
<gb> Issue 122 Glossary draft (by hzbarcea) [needs-discussion]
acoburn: This is about having a glossary. Critical both for the Protocol and defining the UCs that would go into the Protocol.
… 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..
… Everyone, if you haven't read already, please do.
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).
… If someone has a better term, please suggest. We want to have a good story and communicate to the audience.
… 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.
… Profile is common, WebID, DID etc.. that has to exist somehow.
… 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.
… Entity interacts with storage infra in general.
… User has rights to authorize all decisions
bendm: Should we clarify what an identity is? Is identity is a identifier + profile document?
hadrian: Identity is collection of things that can be stated about entity. That is captured in profile document in this case.
… 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.
… 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.
bendm: I suspect this will be added to the glossary draft.
hadrian: If anyone has a proposal, add it there.
<Zakim> acoburn, you wanted to ask about profile document in the context of existing specifications
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?
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.
pchampin: A few things may be too specific for the stage we are in.
… e.g., only human users having right to authorise. Perhaps too early and needs to be only in the spec.
<dmitriz> might it be easiest for us to just re-use the 'Entity' definition that's used by the OpenID / OAuth specs?
pchampin: 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.
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.
… But I think ultimately humans need to be responsible for it.
… 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.
acoburn: I think at this point we may be rabbitholing..
hadrian: That's exactly why I didn't want to discuss too much for now.
<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
csarven: I agree with hadrian about accountability, this is an important point.
… If the notion of accountability is in the UC, then I'm behind that idea. If it is not, we should add it!
<acoburn> +1 on having accountability (or trust) in the use cases
hadrian: Service / Service Provider, specific features and entity providing it respectively.
… We might want to associate identities to these services.
ryey: re Services, do we have a notion for apps? Do we not want to have it?
hadrian: It is further down the list.
ryey: Seems different.
hadrian: They are organised this way because of the dependencies of the concepts.
hadrian: Identity Service / Provider, are well understood terms.
… Relying Party, ditto.
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?
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.
bendm: I would not conflate authn/z though.
hadrian: I could present a doc that would authorise me ??? But maybe I didn't understand your question well.
bendm: The glossary seems more like a definition of functionality but not necessarily how things work. That's why I would add the service.
hadrian: I agree with you, will add it. However, I think it should be possible to be optional. Authorise without necessarily authorization service.
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.
<bendm> +1 on representing the trust relationships complementary to the entity
pchampin: re bendm's comment, to make an alternative proposal, authn/z. Could be realised by service or otherwise.
hadrian: There are a lot of lot of minor implied things. Generally agree.
csarven: a reminder: this is a sample of concepts that seem significant. They don't necessarily reflect what will be in the spec.
… If some use case calls for an authentication service, then it can be added.
… Let's not try to refine the UCs into precise requirements and terms right now.
hadrian: Storage, it is however we define it. Repository owned by an entity. Service of it and the Provider making it available.
… Application accessing storage or other services.
ryey: re Storage, for the Storage Provider, are we talking about the LWS storage provider or underneath, e.g., the cloud service.
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.
ryey: Is the provider of the Storage service rather than ???
hadrian: it is like GitHub for git repositories.
ryey: As in not the physical machines?
hadrian: At least not in this definition. That can be perhaps for the service.
… One for tech and one for operator.
ryey: There is a diff relying on their relationship and what's stated in the issue.
hadrian: Notification service is another service.
… Roles, there are a bunch listed and probably more.
acoburn: Noting that dmitriz mentioned owner instead of controller.
hadrian: Agree but in these circles the owner term used mostly but ack and personally sympathise with it.
<bendm> +1 to change to controller instead of owner
<dmitriz> the VC group /started/with "owner". and then renamed to "controller" (and had to rename a bunch of code/specs)
csarven: from the Web architecture perspective, "owner" and "controller" would be synonymous.
… But from a legal perspective, they would need to be distinguished.
<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. If the UCs e.g., distinguish re legal/policy owner from technical controller, we can have both, or other descr.
<gb> @csarven
https://
csarven: Do we have time for the terms I proposed to add?
acoburn: I'd rather discuss them next week.