LWS WG Meeting - 24/03/2025

hadrian: csarven commented that we have too many terms that point to a specific solution
… i see his point of view. those glossary terms are there right now. if anyone wants, i can remove them temporarily

hadrian: table to next agendum
… status of categories?

<laurens> w3c/lws-protocol#11

CLOSED Action 11 add categorization to the needs discussion labeled issues (on hzbarcea) due 2025-01-13

hadrian: you can close that. we have a critical mass of categories

Introductions and Announcements

Use Cases and Requirements

laurens: i see progress over the weekend. update, hadrian?

hadrian: 1st, two probs:

<laurens> w3c/lws-ucs#139

<gb> MERGED Pull Request 139 add minimal CSS for readable tables (by pchampin)

hadrian: .. pchampin's patch for tables was good but doesn't fully work because of respec limitations
… gonna play with HTML tables

<laurens> w3c/lws-ucs#143

<gb> Pull Request 143 Add requirements and requirements matrix (by hzbarcea) [needs-discussion]

hadrian: there's only one UC because i'm experimenting with the requirements matrix
… i couldn't create anchors in the matrix (of course, i can do it in HTML)
… i added a few requirements
… we can select any for today
… i didn't work on authentication requirements. once i've done them, we can add them to lots of UCs and mark them complete
… happy to discuss and close any issues

<laurens> https://github.com/w3c/lws-ucs/issues?q=is%3Aissue%20state%3Aopen%20label%3Aneeds-discussion

<laurens> w3c/lws-ucs#141

<gb> Issue 141 [REQ-F] Consent based sharing (by hzbarcea) [needs-discussion]

w3c/lws-ucs#141

laurens: let's start with w3c/lws-ucs#141
… the input documents have ACL mechanisms but no protocol for granting access in the input documents
… do we see it as part of the requirements to provide a mechanism to request access
… i think it's important to have and make interoperable

<Zakim> ericP, you wanted to asy that the low bar is that we do nothing

ericP: if you move your data from provider A to provider B, you may have to learn a new way to setup your ACLs
… and we don't have the "google docs" mechanism to request access
… those are the known pain points

<gb> CLOSED Pull Request 253 Add Inbox Discovery on Client Error (by csarven) [doc: Protocol] [topic: resource access] [topic: events and notifications] [status: Nominated]

laurens: i think the lack of standard way to req access is the primary pain point
… nothing analogous to the Google Doc req for access

csarven: i think the proposed req issue is unclear but the things that folks have said here seem familiar
… SolidCG made an attemt to build on Solid protoocol to req access
… in Google Docs, if you try to access a doc you don't have access to, [there's a button to request access]

<pchampin> +1 to csarven, I think there has been several incubated work around consent request; I don't think I heard anyone say it hadn't been incubated, though, only "not standardized"

csarven: 403 gives you a link to req access
… in Solid CG, we had a notification sent to the resource owner. There is implementation experience / still in use, e.g., in https://dokie.li

<acoburn> Interoperability Panel incubation

csarven: this is the low-tech approach to requesting access
… what to put in the payload is a data-modeling exercise
… the solution incubated in the SolidCG was based on WAC

<Zakim> bendm, you wanted to ask whether we have (industry) standards to start from

bendm: csarven's approach is sort of a minimum thing to add to the protocol

<Zakim> acoburn, you wanted to note Inrupt's incubation of this feature

bendm: wanted to mention other industry standards

acoburn: we have access reqs with tamper evidence. simiarl to interop panel's tech
… these aren't industry standards but they are used in production environments at scale

<Zakim> TallTed, you wanted to talk about access permission request elements as primitives, rather than specifics

TallTed: rather than taking about interactions, i think we should talk about a resource and an agent trying to delete or append
… the controler and owner may have different interactions
… may be useful to create a Mermaid diagram

primatives are more likely to be generically applicable
… the looser this can be speciified, the better. how to make it interact and how to make it portable

hadrian: agree. was careful with phrasing to say "verifiable proof" and "audit trail"
… i'm not personally interested in the flows

<bendm7> +1 on focusing on the proofs of access request/grant so you have portability, eg for the audit trail

hadrian: jessie, acoburn and few others wanted to avoid specific mechanism in the spec
… can we just prescribe the proof of an agent's access ?

TallTed: just saying we need a "verifiable proof of consent" doesn't tell me the required functionalities

hadrian: as the server, i need to say that i granted an agent access and a proof for how the grant was appropriate
… we have two providers, A and B
… if storage provider A grants TallTed access to hadrian's resource, ...

TallTed: that seems like ACLs

hadrian: should we say that there should be a way to req access or should we prescribe it?
… i think the former because it will change monthing as providers innovate

TallTed: what happens when you move your data from detailed provider to minimal provider

laurens: i'm concerned by the spread between a minimal provider and a detailed provider
… diff betwen consent and ACLs:
… .. concsent: i wanna give user Alice access to my health records
… .. ACLs: specific documents and agents

jeswr: i think we're conflating:
… .. portablily
… .. auditability

<csarven> +1 jeswr re not conflating requirements

jeswr: .. access management
… .. consent

<csarven> +10 jeswr for making an excellent attempt at reverse-engineering the requirement

jeswr: for access controls and consent, i'd like to differentiate hadrian:proof (ESS gramt model, with proof-carrying-authentication) vs. WAC-like mechamisms where you only show up with an identity
… when't we're taking about access conbtrol, we need to discuss attempting to access a resources and the server deciding or not to give access

<Zakim> csarven, you wanted to follow-up on primitives, e.g., notification, unit of information, actors, kind of access

<ryey> +2 jeswr for distinction between proof and access control, and stages of access (control) evaluation, for more flexible policy mechanism

jeswr: also need to determine how we achieve interop on request consents, then we can ground our audit discussion

csarven: +1 ot unpacking the reqs
… the first sentence in issue 141 could say "to allow access to an entity"
… sencond sentence talks about "proof of consent"
… i think we're using the word "consent" with different perspectives
… +1 to focusing on the primatives
… if i want to req access, i need to make a call, click a button, ....
… are we asking for a specifc way to request access?

<Zakim> acoburn, you wanted to note that consent is often time-constrained and bound to a specific purpose

acoburn: more to unpack. continue in following weeks

laurens: we need to ensure we understand the terminology, e.g. "consent"
… we need to not conflate reqs. this issue relates closely to data and permission portability
… this discussion has layers. we'll need to scope

hadrian: i'll add more thoughts in issue 141

acoburn: as will i
… anything we want to see more of?

laurens: data discoverability

<csarven> pchampin: Note "joined at 14:17 UTC" in the Attendees / Present :)

– DRAFT –
LWS WG Meeting - 24/03/2025

24 March 2025

Attendees

Meeting minutes

Action Items

Action 16 present a weekly overview of closed issues in the https://github.com/w3c/lws-ucs/issues repository (on hzbarcea) due 2025-03-17

Action 15 introduce both the term owner and controller in the glossary, and clarify their meaning. (on hzbarcea) due 2025-02-24

CLOSED Action 11 add categorization to the needs discussion labeled issues (on hzbarcea) due 2025-01-13

Introductions and Announcements

Use Cases and Requirements

w3c/lws-ucs#141

Diagnostics