Meeting minutes
jeswr: Propose a topic for contribution guidelines
… we have a PR open, which probably should be merge
… but I would like to have formal guidelines on number of approvals and timeline.
… Preferably these guidelines would be based on the correction class of the change.
… Additionally I want to discuss a topic on research into prior art.
Introduction and announcements
Use Cases organization
eBremer: Hadrian has been working on the initial use cases documents. I spent some time on aggregating use cases based on the github API
… Thereafter I've summarized all issues using the Gemma3 LLM
… This information was shared with Hadrian.
… Now I've integrated this in the organization set up by hadrian.
… What does the group think of this?
<acoburn> document preview
uvdsl: I noted your PR and am working through it, there are some minor things which need discussion. Some use cases are very general.
… Seems like a good starting point, this can be refined further.
jackson: This looks really good. We might be using the term "user" too much, "data owner" or other specific roles might be better suited.
eBremer: The next step is to leave this PR open for review for a couple of days, to get some feedback asynchronously.
<uvdsl> +1 to leaving the PR open for feedback (working on it!)
eBremer: I am using similar methodology to bounce the open issues on the solid protocol against these use cases. The code for this has been written already.
… This is a starting point, open for further suggestions or refinement.
Scope of portability use case
acoburn: We've had some discussions on portability, but we want to ground that in use cases.
… One of the things we need to figure out is the scope of portability for the purpose of this group.
… We may e.g. decide it is out of scope, or certain elements are in scope.
<acoburn> Use case 1
<gb> Issue 30 [UC] Move between service providers (by uvdsl) [triage] [usecase]
acoburn: I have put some references in the calendar invite to issues.
<acoburn> Use case 2
<gb> Issue 164 [UC] Move between service providers preserving legacy ACLs (by ericprud) [triage] [usecase]
<acoburn> Use case 3
<gb> Issue 165 [UC] Portability of public resources (by ericprud) [triage] [usecase]
acoburn: When the chairs were talking about this last week, we were trying to find a way of scoping this for the group.
… Portability level 0 could be the ability to transfer data.
… Then level 1 could be transfering metadata e.g. auxiliary resources, ACLs, ..., abstractly related to a resource.
… Then level 2 could be the preservation of user experience, which could mean a lot of things.
… Finally, could you also preserve authorization. There might be private resources, public resources, ...
… For example is a resource that is public still public, is a private resource still private ...
… Are all of this in scope, or only certain levels.
<Zakim> ericP, you wanted to say that DNS solutions are probably not available to permutaions of 9B people and that http-based conventions with degrees of indirection introduce single points of failure
acoburn: The last level could be split in public and private resources, but generally related to authorization.
ericP: While we are thinking about authorization and the cost of portability. DNS-based solutions are probably not available to all 9B+ people out there.
… There is probably not really an easy solution to this.
acoburn: I think it's all about trade-offs. Copying and pasting data could satisfy level 0 already, which is somewhat trivial.
… The more interesting use cases are on transfering metadata, and preserving user experience and authz.
… Answers might differ between levels, even though there is overlap;
dmitriz: Preserving user experience would entail preserving everything.
acoburn: We should figure out whether that is the goal and be clear about that.
pchampin: One way making the distinction between UX and authorization, would be the UX of the owner vs people with whom they've shared the data.
<Zakim> uvdsl, you wanted to say that UX can be preserved in various ways, not only by preserving what is at the source of the data.
uvdsl: I want to mention that I don't think that preserving the UX of the user necessarily means preserving what was at the source.
… The question is does it work.
acoburn: Could you clarify this?
uvdsl: What we mean by UX is that as an end user I want the ability to transfer data between storages, and it should still work. The end-user should not be concerned with how this works behind the scenes.
… We could e.g. make transfering a zip-file work for portability.
laurens: i follow pierre-antoine's point. you can shift burden to owner
… we've had migrations of storage endpoints. most issues for owner was easy but it's harder and more important to handle remote user experience
acribe -
<Zakim> uvdsl, you wanted to ask if the "user" in UX is a general data consumer or the end user?
uvdsl: When we talk about user experience, do we mean the "average joe" end-user or the end-user as a technical entity (e.g. data consumer/provider)?
acoburn: We have these different personas, as we get into this conversation it would make sense to split this out.
… For whom are we preserving this user experience, which may differ per persona.
… There is some nuance there, and I don't have the answer right now.
uvdsl: When we have these conversations, we should be clear about who the user is. Else we might lose ourselves in the conversation.
… We should be clear about whom we're refering to.
<pchampin> leaving
<acoburn> meeting just ended
<ericP> oops
<acoburn> I'll start another one, one sec
acoburn: Agreed. The typical personas that I've encountered tend to be at one end the data consumer (someone who's using an application), a data owner (potentially another user using an application), thirdly a developer who is building an app who has to handle data in another location.
<acoburn> https://
Most people were able to rejoin the Zoom call.
acoburn: Lastly, a data operator (infrastructure provider) could also be a category.
etiquette for PR merging
jeswr: We should have a best practice about how long a PR should be open, how many people and whom should approve before merging and the timeline for merging.
<jeswr> https://
<gb> Pull Request 29 chore: add required editor approvals and timelines for PRs (by jeswr)
<jeswr> The following etiquette is followed for managing PRs submitted to this repository. The we refer to the official W3C Correction Classes.
<jeswr> | Class | No. Editor Approval | Time PR must be open | Requires WG Call Discussion |
<jeswr> | ----- | ------------------- | -------------------- | --------------------------- |
<jeswr> | 1 | 1 | 0 buisness days | No |
<jeswr> | 2 | 2 | 3 buisness days | No |
<jeswr> | 3 | 2 | 5 buisness days | Yes - formal vote not required |
<jeswr> | 4 | 2 | 5 buisness days | Yes - formal vote required |
jeswr: Any feedback to this?
uvdsl: What is a formal vote?
ericP: Voting happens either through a meeting (or could be asynchronously)
acoburn: We should give a heads up for this in the agenda.
ericP: Some groups have rules on giving sufficient notice
laurens: i would interpret "formal vote" as a decision within the WG.
… makes sense that it should be on the agenda before hand
research into prior art
jeswr: Two weeks ago we started a discussion of research topics
… with the goal of having direct pointers to prior art on each topic
… for example with respect to authz we want specific pointers where relevant materials are in the input documents.
… As well as potential related spaces (e.g. SAI), or the broader ecosystem (Amazon or Google authz mechanisms).
… We would be looking for individuals with expertise in these topics, with goal of coordinating this research and pulling in people who have expertise to provide the relevant pointers and inputs.
… If you look through these topics and see something of interest to you, either mention it in the call or put your name in the discussion so we can figure this out async.
<jeswr> w3c/
<gb> Issue 18 Research Topics (by jeswr)
<jeswr> https://
dmitriz: I am unsure if I can lead the topic, but I'd be happy to contribute with prior examples where appropriate.
<Zakim> ericP, you wanted to say that e.g. GDrive, AWS provide useful input on user experience/tollerance
ericP: For example Google Drive or AWS could give useful input on UX or tolerance.
jackson: I'm not sure if I'm the best person, but I could spend some time on discovery.
jeswr: Happy for you to take this up.
ericP: Do we have a list of all of the protocols/topics we want to have summarized? How do we organise this?
jeswr: My understanding is that the topic you would take on is one of the 8 or so topics in the protocol document.
… You would not just refer to protocols, but also implementations.
ericP: Do we want to take authn and authz orthogonally?
dmitriz: I think we should take authz as the root/anchoring element.
<Zakim> uvdsl, you wanted to say that authentication and authorization are distinct
uvdsl: Authn and authz are distinct functionalities that aren't necessarily tightly coupled. Would make sense to treat them separately
ericP: We have a pretty wide space we need to populate here. I feel like we need to organise this.
… We could have people just sign up in #18 for now and then take it from there.
<gb> Issue 18 Research Topics (by jeswr)
jeswr: Let's start there.
… I could do some work on the structure of the template for this. But I don't have more thoughts for now.
ericP: Do we want a wiki on this?
jeswr: That's what I have right now.
<jackson> Could you paste to auth example link?
<acoburn> Authorization example
ericP: Look at #18 and sign up for one of the research topics, share you expertise.
acoburn: And please review eBremer's PR on the use cases repo.