07:32:31 <RRSAgent> RRSAgent has joined #lws
07:32:35 <RRSAgent> logging to https://www.w3.org/2025/10/10-lws-irc
07:35:14 <acoburn> zakim, start meeting
07:35:14 <Zakim> RRSAgent, make logs Public
07:35:16 <Zakim> please title this meeting ("meeting: ..."), acoburn
07:35:33 <acoburn> meeting: Linked Web Storage - Face-to-Face meeting (day 3)
07:35:50 <acoburn> RRSAgent, make minutes
07:35:51 <RRSAgent> I have made the request to generate https://www.w3.org/2025/10/10-lws-minutes.html acoburn
07:36:27 <pchampin> present+
07:36:55 <laurens> laurens has joined #lws
07:37:01 <laurens> present+
07:37:03 <acoburn> present+
07:37:48 <jeswr> jeswr has joined #lws
07:38:10 <jeswr> present+
07:39:39 <acoburn> topic: Access Requests
07:39:52 <acoburn> scribenick: acoburn
07:43:39 <acoburn> present: tobin
07:44:13 <acoburn> tobin: introduction, working with autonomous agents, co-chairs OpenID working group
07:45:05 <pchampin> scribe+
07:45:24 <pchampin> aaron: let's start by focusing on authentication and identity
07:45:32 <pchampin> ... we are focusing on 2 flows:
07:45:42 <Wonsuk> Wonsuk has joined #lws
07:45:49 <pchampin> ... 1. users interact via a browser, standard OpenID connect flow
07:45:54 <Wonsuk> present+
07:46:01 <pchampin> ... 2. client able to manage its own secrets (agent, bot, script)
07:46:13 <pchampin> ... there are a couple of features that we need in the context of LWS
07:46:40 <pchampin> ... globally unique agent identification: the sub claim should be a full URI
07:47:08 <pchampin> ... I believe that sub claims can be full URIs, wonder about size restriction.
07:47:25 <pchampin> ... we need global identity for clients (azp claim, client id)
07:47:42 <pchampin> ... typically a string scoped to an issuer, but we want that to be global, decoupled from an individual ID provider
07:47:55 <pchampin> ... we want to avoid the challenge of having to register any client to any ID provider
07:48:15 <pchampin> ... and we don't see dynamic client registration; ephemeral client identity is of no use for authorization
07:48:27 <pchampin> tobin: the problem of getting a global ID is tough
07:48:58 <pchampin> ... in MCP, using the metadata URL as an ID
07:49:05 <pchampin> laurens: is that speced alreadt?
07:49:14 <pchampin> tobin: I think it was merged today
07:49:30 <pchampin> s/aaron: /acoburn:
07:49:44 <pchampin> acoburn: the Solid community has a "Solid OIDC" spec
07:49:56 <pchampin> ... that defines a "webid" scope, we think we can get rid of that
07:50:16 <pchampin> ... Solid OIDC requires DPop, which is sketchy; we think we can get around that
07:50:42 <pchampin> ... the third think is a client identifier descrtibed by a JSON file sitting somewhere
07:50:59 <pchampin> ... if we can avoid specifying that ourselves, that would be great
07:51:16 <pchampin> tobin: the client ID metadata was spec'ed today
07:51:38 <jeswr> https://datatracker.ietf.org/doc/draft-parecki-oauth-client-id-metadata-document/
07:52:22 <jeswr> announcment https://www.linkedin.com/posts/aaronparecki_the-ietf-oauth-working-group-has-adopted-activity-7382203049647230976-HnIp/?utm_source=share&utm_medium=member_desktop&rcm=ACoAAB5334sBEoBFzCtubbRVzVnbgik6Sxn60y4
07:52:26 <pchampin> ericP: we need to determine what we need to write in our own spec, vs. Shim spec pointing to something else
07:53:50 <pchampin> jeswr: noting that Emilia Smith (formerly Inrup) is an editor of that spec, and that the spec mentions Solid OIDC :-D
07:54:30 <pchampin> acoburn: this is funny. This is currently a draft. We can normatively reference to it when this is stable.
07:54:46 <pchampin> tobin: in MCP, this is the minimally viable solution that we need.
07:54:56 <pchampin> ... it does not solve the problem of authorization.
07:55:06 <pchampin> acoburn: in LWS we need global identifiers
07:55:45 <pchampin> ... without requiring this mechanism for all client identification, this gives us an example of how this can be done
07:56:04 <pchampin> ... Tobin, are you familiar with the notion of CID document, published by W3C in May?
07:56:44 <pchampin> ... It defines a common data model for describing public keys and other ID info.
07:56:55 <pchampin> ... In Solid we use WebID, that plays a similar role.
07:57:06 <pchampin> ... WebID has a long history, but it is not an official spec.
07:57:46 <pchampin> ... We could replace it with CID. We could have metadata in the CID document including the public portion of a JWK.
07:58:09 <pchampin> ... That could be used by this clients sign tokens and produce ID assertions.
07:58:34 <pchampin> jeswr: for the problem of agents self-certifying, we were proposing "use a CID with a public key"
07:58:54 <pchampin> ... is there in the MCP world / OAuth 2.1 an existing self-certifying mechanism?
07:59:28 <pchampin> tobin: a constant question with MCP is "what is an agent?"
07:59:38 <pchampin> ... the spec is opinionated but that is going to change
07:59:50 <pchampin> ... I don't know how to plugin in whatever robust ID you want into that setup
08:00:17 <pchampin> jeswr: we use the term "agent" very generally, could be a simple scripts that is authorized to access a server
08:00:33 <pchampin> ... it could be an MCP server accessing a pod. We want to address a range of use-cases.
08:01:47 <pchampin> tobin: in AI, the permissions are expressed in natural language
08:02:02 <pchampin> ... that sounds strange, but AI folks are doing this more and more
08:02:24 <pchampin> ... I want to nudge you to leave room for that. This is moving faster than you might like.
08:02:41 <pchampin> acoburn: this is a useful nudge when we come to specify the ACL language.
08:03:11 <pchampin> ... we know what we have today is insufficient, we are reluctant to define our own.
08:03:54 <pchampin> ... Yesterday we talked about "Authorization details", as a way to not reinvent something.
08:04:05 <pchampin> ... In your opinion, does it seem like a reasonable approach?
08:04:25 <pchampin> tobin: I have no issues with that. People with a more decentralization approach might have.
08:04:41 <pchampin> laurens: is there anyway that we could liaison with your group?
08:05:42 <pchampin> tobin: a cool touchpoint: we have a meeting with a bunch of OAuth people
08:05:54 <pchampin> acoburn: the timing could be convenient for me
08:08:13 <acoburn> topic: Authorization Requests/Grants in LWS
08:08:47 <acoburn> laurens: there should be some way for an agent to express that it wants access to a resource
08:09:02 <acoburn> ... prior art in Interop Panel, Inrupt (Access Grants)
08:09:18 <acoburn> ... authorization_details could also be useful
08:09:51 <acoburn> ... this relates to topic of notifications, since some notification is important for access requests
08:10:32 <acoburn> ... looking ahead, we can discuss test suite in afternoon
08:11:47 <acoburn> ... 2 scenarios
08:12:27 <acoburn> ... (1) user with client application, accessing own data on RS
08:14:10 <acoburn> ... could be client id matcher (e.g. in ACP), setting ACLs
08:15:10 <acoburn> ... hard to put restrictions on clients when editing ACLs (e.g. time horizons, purpose, etc)
08:16:01 <acoburn> ... authorization_code flow easier in centralized applications, harder with decentralized apps
08:16:18 <acoburn> ... in GDrive, there are a set of pre-defined scopes
08:16:44 <acoburn> ... problem with decentralization is that you need a universal way to express these operations
08:17:20 <acoburn> pchampin: to clarify, existing (centralized) apps have their own defined scopes
08:17:47 <acoburn> laurens: naive approach: scopes matcher, but this just shifts the problem
08:18:24 <acoburn> ... these are strings and can lead to interop problems, since each impl can have its own approach
08:20:24 <acoburn> ... this scenario typically includes a synchronous flow
08:20:57 <acoburn> ... existing solutions in OAuth could be good solutions
08:21:23 <acoburn> ... for async flows, the device code flow may be more appropriate
08:21:39 <acoburn> ... but this doesn't really solve the access control problem
08:23:53 <acoburn> acoburn: seems that the first (single-agent) flow could be built today without new features in Solid/AWS
08:24:17 <acoburn> ... async, multi-agent flow would need new features beyond what solid defines today
08:24:59 <acoburn> laurens: two agents, agent A wants access to data controlled by B
08:25:27 <acoburn> ... A and B each have their own RS
08:27:06 <acoburn> ... linked data notifications defines an inbox. Security considerations are significant
08:28:10 <acoburn> ... LDN, webhooks (service-to-service) possibilities
08:29:03 <acoburn> ... would like to see some sort of Inbox, hard to provide strong security guarantees
08:29:25 <pchampin> acoburn: not to suggest that we do what Inrupt does,
08:29:49 <pchampin> ... but we do thing to make Inboxes tractable
08:29:56 <pchampin> ... it has to do with HTTPsig
08:30:27 <pchampin> ... in almost all cases where entities exchange messages, the security issues are not well considered
08:31:09 <pchampin> ... token exfiltration is not a solution we should encourage
08:31:29 <pchampin> ... Alice performs some action, that triggers a notif that may go to an inbox (or a specialized one)
08:31:49 <pchampin> ... the server that delivers this can act on behalf of Alice, with its own signature
08:32:24 <pchampin> ... let's assume it is the RS that sends this message
08:32:55 <pchampin> ... it does not send an auhtorization header, instead it sends signature headers that need to be validated by Bob's RS
08:33:51 <pchampin> ... Bob's RS needs to validate those signatures; we don't need to invent anything, this is spec'ed already
08:33:59 <pchampin> ... we would just have to define a few required fields
08:34:54 <pchampin> laurens: I agree [mentions a few specs complementing HTTPsig]
08:35:54 <pchampin> ryey: would it make sense that the message is between ASs rather than RSs?
08:36:34 <pchampin> laurens: I think it would make sense because such servers already have signature material available
08:36:51 <pchampin> acoburn: to push back on this a little
08:37:14 <pchampin> ... in LWS, we are focusing on Resource Servers
08:37:28 <pchampin> ... Monday we talked about storage metadata
08:37:49 <pchampin> ... it could be a CID, it could say something like "this storage has an agent"
08:38:04 <pchampin> laurens: you could make this argument for the Authorization Server
08:38:04 <acoburn> s/Monday/Wednesday/
08:38:29 <pchampin> ... some specs in this spec could be reused
08:39:20 <pchampin> ... this kind of exchange could be about other things than resources in the RS
08:39:56 <pchampin> acoburn: I know that everyone is Solid is using OIDC today
08:40:10 <pchampin> ... but I don't think we should tie ourselves to OpenID or OAuth
08:40:32 <pchampin> laurens: granted; the only reason I mention it is that someone else may want to spec it
08:40:57 <pchampin> jeswr: a hesitation I have with Resource Servers communicating:
08:41:06 <pchampin> ... you may have several storages
08:41:21 <pchampin> laurens: you may also have several ID providers
08:41:38 <pchampin> jeswr: yes, but when you make an access request it is bound to a single identity
08:42:21 <pchampin> acoburn: the access request would be send to a server and ask "send your response there"
08:42:37 <pchampin> ... with some proof that you control "there", not causing some spam to someone else
08:43:48 <pchampin> bart: does this implies that the Resource Server should have an inbox as well?
08:44:15 <pchampin> laurens: possibly
08:44:32 <pchampin> acoburn: I think there needs to be a URL somewhere. It does need to be a container in your storage.
08:44:44 <pchampin> ... It is a kind of service that you kind describe in the storage description metadata.
08:44:52 <pchampin> ... It could also be described in the user's CID.
08:45:28 <pchampin> ... It should not be a generic Inbox. We need to carefully thing about it (shape validation?) to avoid it being flooded.
08:45:43 <pchampin> bart: would it be one per storage or one per server?
08:45:54 <pchampin> laurens: I don't think we must decide that
08:46:15 <pchampin> ... but what is being exchanged should be addressed to someone
08:46:45 <pchampin> acoburn: I think this is a deployment consideration
08:47:48 <pchampin> laurens: should we start discussing the content of such access requests?
08:48:26 <pchampin> acoburn: there are two levels for this; I would start with an envelope.
08:48:35 <pchampin> laurens: yes; this could be a JWT, a VC...
08:49:01 <pchampin> ... an envelope and a paylod
08:49:15 <pchampin> ... the envelope would contain a recipient (or "addressee"?)
08:49:36 <pchampin> acoburn: important things for the envelope is a signature, information about the management of that credential
08:49:45 <pchampin> ... how you can verify it, revoke it
08:49:54 <pchampin> ... thinks like the issuer
08:50:51 <pchampin> jeswr: revocation here is different from the one you have in VC
08:51:13 <pchampin> ... in VC, this is to prevent you from from using a signed document after it has been revoked
08:51:33 <pchampin> ... here, you know the audience of the credential, so you can send them a new credential cancelling the previous one
08:51:47 <pchampin> laurens: I don't have a strong opinion
08:52:20 <pchampin> ... what else in the envelope
08:52:31 <pchampin> acoburn: I see it as "how to manage the credential"
08:52:36 <pchampin> ... the rest could go in the payload
08:52:59 <pchampin> jeswr: looking at the access request that Dokieli currently uses (the payload)
08:53:16 <pchampin> ... type: AuthzRequest
08:53:27 <pchampin> ... target: what resource we want access to
08:53:36 <pchampin> ... agent requesting access
08:54:01 <pchampin> ... mode of access that is requested (here: read/write)
08:54:25 <pchampin> laurens: I would want this to leave under "target" (noting that target is not an ideal name for it)
08:54:36 <pchampin> acoburn: I think there is a time element (this may expire)
08:54:47 <pchampin> laurens: I would put this in the envelope
08:55:38 <acoburn> ... for example: issued at/not before/expires
08:59:33 <acoburn> laurens: target may not uniquely identify specific resource, could be category or resources or a service
08:59:57 <acoburn> wonsuk: could the target be a type index or other service?
09:00:25 <acoburn> laurens: not sure about the authZ model yet
09:02:01 <acoburn> ... chicken and egg issue if you don't know where the data lives (i.e target)
09:02:32 <acoburn> pchampin: not sure it's a problem. App says "I'd like to see PhotoAlbum types"
09:03:09 <acoburn> laurens: there may still be certain categories of information shared out-of-band
09:04:53 <acoburn> ... target needs to express more than just resource URIs
09:06:55 <acoburn> ... e.g. user-defined type
09:07:25 <pchampin> acoburn: in the context of "Authorization details" discussed yesterday
09:07:36 <pchampin> ... you may send some time to the AS, which does not know anything about it
09:08:07 <pchampin> ... it still includes it in your token, then the RS uses it to decide to allow/forbid access (based on the actual type of the resource)
09:08:11 <pchampin> s/some time/some type
09:09:33 <pchampin> laurens: [refining the target field on the flipboard]
09:09:47 <pchampin> acoburn: compared to the flow we discussed yesterday,
09:10:04 <pchampin> ... what you are doing here is capturing part of that flow, but deferring it
09:10:13 <pchampin> ... because this is now an asynchronous flow
09:10:19 <pchampin> laurens: yes
09:10:31 <pchampin> ... this should be aligned with the "Authorization details" spec
09:10:53 <pchampin> ... that would give a consistent model across the different components
09:11:17 <pchampin> ... Another thing we might want to consider:
09:11:31 <pchampin> ... the requester may be the CID of an agent, the application description of the app,
09:11:42 <pchampin> ... could also be a combination of both
09:11:59 <pchampin> acoburn: this can be mirrored in OAuth concepts
09:12:20 <pchampin> ... authorized client, audience
09:12:36 <pchampin> ... I had not conceptualized these similarities before
09:12:54 <pchampin> laurens: there are many similarities, with interesting possibilities
09:13:10 <pchampin> acoburn: we need to move on to Notification 12 minutes ago
09:13:16 <pchampin> ... to wrap up: this is the request
09:13:20 <pchampin> ... what about the grant?
09:14:01 <pchampin> laurens: could be very similar
09:14:21 <pchampin> ... I don't have a full blown mechanism for how the grant is pushed back to the requester
09:15:16 <pchampin> acoburn: aside from the inbox/notif mechanism
09:15:29 <pchampin> ... we also need a way to look up the requests/grants
09:15:44 <pchampin> laurens: that's why I am not a fan of a push based mechanism for this
09:15:57 <pchampin> acoburn: ESS has 2 parallel mechanisms: ACP and Access Grants
09:16:12 <pchampin> ... if I want to know who has access to my pod, I need to look in two places
09:16:25 <pchampin> ... this is where your earlier comment about managing this at the AS level makes a lot of sense
09:17:06 <pchampin> ... if we find the way to push them into the AS (a lot of hand-waving here), that will be much better for auditing etc...
09:18:00 <pchampin> ... Also, it is important to have a purpose associated with requests and grants
09:18:30 <pchampin> laurens: what I would like there be some way to associate metadata with this request
09:18:42 <pchampin> ... to clarify the content in which it was made
09:19:05 <pchampin> ... not necessarily in the payload, but something that could be referenced and persisted
09:19:33 <pchampin> bart: yes, this is needed to give a legal status to those requests and grants
09:20:11 <pchampin> laurens: one example is what ISO did with the consent receipt
09:20:29 <pchampin> bart: is this something whete ODRL could come into play?
09:20:59 <pchampin> laurens: some aspects of the access request could be evaluated against an ODRL policy on the AS
09:21:34 <pchampin> acoburn: at present, Inrupt uses VC and G-Consent
09:21:45 <pchampin> ... we did consider ODRL, but it does not simplify the representation at all
09:23:16 <acoburn> pchampin: ODRL is very generic, other groups that use ODRL define a profile to refine how it is used for specific communities
09:24:07 <acoburn> ryey: in ODRL is current state is not meant to be used to represent an access request/grant
09:24:22 <acoburn> ... instead it is used to evaluate an AR/AG
09:24:55 <acoburn> topic: Notifications
09:25:03 <acoburn> RRSAgent, make minutes
09:25:04 <RRSAgent> I have made the request to generate https://www.w3.org/2025/10/10-lws-minutes.html acoburn
09:25:10 <Beau> Beau has joined #lws
09:43:13 <ryey> ryey has joined #lws
09:43:17 <ryey> pesent+
09:43:23 <ryey> scribe+
09:43:59 <ryey> [After break, topic to notifications]
09:44:38 <ryey> laurens: an app may be interested in what has been updated, created ,deleted... eventually, a lifecycle of resources
09:45:53 <ryey> laurens: lifecycle: from creation, to update (update to the resource itself, of the metadata, or associated ACLs), to deletion
09:46:18 <ryey> ... in solid, this is by WebSockets
09:46:46 <ryey> ... web browser app subscribes to resources, and receive notifications
09:47:02 <ryey> ... but problem is it only works in browser
09:47:21 <ryey> acoburn: if you lose connection (etc), you face issues. Also not at scale.
09:47:44 <ryey> laurens: Another existing solution is Solid Notification Protocol
09:47:46 <acoburn> acoburn has joined #lws
09:48:09 <ryey> ... relates to discover of capability of resource servers
09:48:25 <ryey> ... for some interesting aspects, from SNP
09:49:18 <ryey> ... quite some level of interface flexibility. we may want them here.
09:49:39 <ryey> ... For the lifecycle events, they are *after* happened
09:50:00 <ryey> ... but we may want other ones in addition, prior to occurance
09:50:22 <ryey> e.g. in k8s, you have such prior events
09:50:55 <ryey> ... (k8s) if the hook doesn't response succeed in time, the event fail
09:51:13 <ryey> ... this may allow integrity or consistency checks for us, e.g. shape trees, etc
09:52:08 <ryey> acoburn: one complication issue: when posting a resource, I'm asking "can I do it *right now*?"
09:52:24 <ryey> ... but here for events, it's after something, or regular
09:52:52 <ryey> ... so the timespan now is after, so it's much longer
09:53:13 <ryey> ... something to notice and take care
09:53:44 <ryey> laurens: notification may be specified separately than regular access modes
09:54:10 <ryey> acoburn: we can do initial authorization at subscription time
09:54:33 <ryey> ... next, some time later (e.g. a day), something will change to the subscription. How do you ensure the access is still valid?
09:54:39 <ryey> ... different ways to model it
09:54:59 <ryey> ... 1. every time you change, you update it
09:55:29 <ryey> ... 2. watch how things with authorization, when things change for the resource, update it
09:56:01 <ryey> bartp: for case 1, when the notification happens, the sender does it ever ytime?
09:57:11 <ryey> acoburn: when I watch for something, I can pull. Other than pulling, I want push. If my authorization changes in the meantime (to no longer being authorizaed to access the resource), I should not receive the next notification.
09:57:54 <ryey> laurens: so we have two options, either by the receiver side, or the sender side
09:58:58 <ryey> acoburn: this is managed separately from storage. For a given subscription, we have delivery location. we associate a status as well -- instead of just making it disappear, we send an error (or other similar messages).
10:00:14 <ryey> laurens: we may leave the details out of scope for our spec. we can only have abstraction descriptions on what is needed; if time allowed, specify it
10:00:18 <jeswr> scribe+
10:00:42 <jeswr> acoburn: If we are going to specify anyhting about notifications, we should specifiy how AuthZ on notifications work
10:00:47 <ryey> scribe-
10:01:12 <jeswr> laurens: We should also specify MUST have requirements for events in the resource lifecycle, and some of the content data
10:01:26 <jeswr> ... with an abstract definition of the data model in the core protocol
10:02:05 <jeswr> ... this leaves the question of whether there is true agent-agent notifications. We have discussed resource server-resource server notifications. I would be against a generic agent-agent notification spec
10:02:21 <jeswr> ... you could have a container live somewhere with public write permissions on it to satisfy that use case
10:02:29 <jeswr> ... I would be hesitant to specify an inbox
10:02:55 <jeswr> acoburn: I have pulled up the docs for Inrupts webhook notifications. The data that we do include is
10:03:21 <jeswr> ... it is a JSON object. Every notification has a UUID,
10:03:38 <jeswr> ...  reference to a subscription - this is a UUID
10:04:01 <jeswr> ... a date for when the notification for when the notification itself was published
10:05:04 <jeswr> ... a type - which is a string that is a URI to capture e.g. resourceUpdated, resourceDeleted, etc.
10:05:14 <jeswr> ... when you create a subscription, you can subscribe to multiple types
10:06:05 <jeswr> ... there is a purpose, which is set at subscription time and optional. This purpose is carried with the description so the webhook processing can do something with this purpose.
10:06:40 <jeswr> ... the webhook recipeint cannot necessarily access all of the metadata about the subscription - this is why purpose is needed.
10:06:55 <jeswr> ... Then we have a field for the URI of the resource
10:07:08 <jeswr> ... then we have "controller" and "audience"
10:07:32 <jeswr> ... audience defines the intended recipeint of the notification
10:07:56 <jeswr> ... controller defines the controller of the resource that changed. In the case of an access grant being issued; the controller is the entity that created it
10:08:11 <jeswr> ... for an access grant expiring or being revoked, the controller is the entity that created it
10:08:27 <jeswr> ... for a resource in a storage, if you create a resource in your own storage you are the controller
10:08:48 <jeswr> ... if someone else has write access and creates a resource - they are not the controller. The owner of the Pod is still the controller
10:09:18 <jeswr> laurens: I would also want the actor that triggered the update.
10:09:37 <jeswr> acoburn: Sometimes the actor is relevant - sometimes there is no actor (e.g. access grant expiring)
10:10:05 <jeswr> ... The expiry notification is useful if I issued the notification and want to know about that
10:10:19 <jeswr> laurens: Can the ID be used to define idempotency on events
10:10:45 <jeswr> .... can we say that an ID can never be used again
10:11:06 <jeswr> acoburn: With UUIDs you can be pretty certain they are unique, but this is not guaranteed
10:11:27 <jeswr> ... with webhooks, we need to be able to account for intermittent network failures - and ocassionally need to retry
10:11:47 <jeswr> ... there will be cases where there is a network failure on the response which means that you send the same request twice
10:12:21 <jeswr> laurens: You could have a weaker guarantee which is if the same event is re-transimitted it is a unique identifier
10:13:00 <jeswr> ... to clarify, the weak guarantee - is if it is the same event - it must use the same identifier
10:13:35 <jeswr> ... We also need to still define who the actor and controller are for different events
10:13:48 <jeswr> acoburn: There is also an audience field - which defines the recipient of the message
10:14:32 <jeswr> ... in effect it is metadata on the subscription. If it is an access grant, there is the entity who created the access grant, then some target of that - that is the audience.
10:14:47 <jeswr> ... when a resource is created, the audience is whoever created the subscription
10:14:57 <jeswr> laurens: We just need an event modelling session around this
10:15:09 <jeswr> acoburn: Another element, which is optional - is data minimisation
10:15:26 <jeswr> ... these are rules on how to minimise the data.
10:15:44 <jeswr> ... it is an object, which includes things like a retention period to say "you can keep this object for 30 days"
10:15:55 <jeswr> ... in all messages headers are signed using HTTPSIG
10:16:16 <jeswr> ... there is a content-type and then a content digest header. The content digest header is what is signed.
10:20:06 <jeswr> pchampin: What is the state of the art in Solid today
10:20:39 <jeswr> acoburn: The current notifications model based on Websockets which is largely deprecated already - this is part of the reason Inrupt has not implemented that particular notifications standard
10:21:11 <jeswr> ... This came out of the solid noticications panel.
10:22:06 <jeswr> jeswr: cxres produced PREP https://cxres.github.io/prep/draft-gupta-httpbis-per-resource-events.html - is this an input we should be considering
10:22:28 <jeswr> acoburn: It i not an input in the charter; but I wouldn't ignore it
10:22:54 <jeswr> ryey: A reason this was written was for efficiency of notifications
10:23:25 <jeswr> ... A question I have is - if I want to subscribe to updates on many resources; what would be the best way?
10:24:05 <jeswr> acoburn: In ESS you would create a subscription with pointers to all of the different resources you want to listen to. This means you can also subscribe to a container and get notifications of updates to any resource in that container.
10:24:48 <jeswr> ryey: What if the resource update is frequent, is there a way to limit noise
10:25:03 <jeswr> acoburn: Not in our implementation, we acknowledge that it is an issue.
10:26:08 <jeswr> ... It is part of the reason that there is a back-off retry on events. It is also not something that you can necessarily spec for. You do need to assume that there is a high rate of notifications coming in; that may exceed your ability to send them out. In turn this may exceed your ability for your webhook reciever to process them. So you do need
10:26:08 <jeswr> to account for things like backpressure in implementation.
10:27:09 <jeswr> pchampin: On websocket vs. webhook considerations. In a standard client-side app - are webhooks an option
10:27:23 <jeswr> acoburn: Webhooks are not very useful for a client-side SPA with no server component
10:27:38 <jeswr> ... because a webhook delivery mechanism has to have some kind of server that can receive it
10:27:53 <jeswr> pchampin: My assumption is that some kind of simple client-side mechanism is still needed
10:29:00 <jeswr> acoburn: If I were writing a highly scalable system - I would set up a WebHook that becomes a resource sinc. This is the server side portion of my app. The sinc there publishes a Websocket API that makes use of standard AuthZ (e.g. cookies) which addresses the case of someone who is actively using and logged into that applciatiosn.
10:29:20 <jeswr> ... then when someone is disconnected from the network, the webhook continues to get messages; and when they reconnect you catch up.
10:29:37 <jeswr> ... from the point of messages being sent from the LWS server - it is all out of scope.
10:30:26 <pchampin> RRSAgent, make minutes
10:30:28 <RRSAgent> I have made the request to generate https://www.w3.org/2025/10/10-lws-minutes.html pchampin
10:31:13 <pchampin> present+ pchampin
10:31:19 <pchampin> present+ acoburn
10:31:28 <pchampin> present+ jeswr
10:31:31 <pchampin> present+ laurens
10:31:35 <pchampin> present+ ryey
10:31:57 <pchampin> present+ bartb
11:26:32 <ryey> ryey has joined #lws
11:29:35 <Wonsuk> Wonsuk has joined #lws
11:30:11 <acoburn> acoburn has joined #lws
11:31:32 <pchampin> topic: Test suite
11:31:41 <pchampin> acoburn: before we get to the content of the test suite
11:32:04 <pchampin> ... one issue I have seen: after a WG finishes their work, the test suite sits there and is not used anymore
11:32:16 <pchampin> bendm: this is a side effect of the WG process
11:32:57 <jeswr> jeswr has joined #lws
11:33:04 <jeswr> present+
11:33:31 <acoburn> pchampain: there are "maintenance" modes that are possible
11:33:59 <bendm> bendm has joined #lws
11:34:08 <bendm> present+
11:34:54 <pchampin> https://github.com/w3c-ccg/mocha-w3c-interop-reporter
11:35:18 <laurens> laurens has joined #lws
11:35:28 <laurens> rrsagent, draft minutes
11:35:29 <RRSAgent> I have made the request to generate https://www.w3.org/2025/10/10-lws-minutes.html laurens
11:36:44 <pchampin> https://canivc.com/
11:38:33 <ericP> ericP has joined #lws
11:38:53 <pchampin> laurens: the infrastructure that runs the test suite on a regular basis needs maintenance
11:39:03 <RRSAgent> I have made the request to generate https://www.w3.org/2025/10/10-lws-minutes.html ericP
11:39:09 <pchampin> ... this is something I'm not sure we can solve
11:39:37 <pchampin> ... one way to address that would be to have the test suite include an abstraction layer
11:40:21 <pchampin> ... the Solid test suite does that. I'm on the fence about that, as It adds a lot of complexity.
11:41:39 <pchampin> ericP: I want to keep in mind that testing keeps you honest wrt providing interop.
11:41:52 <pchampin> ... testing tells you when you have been too flexible.
11:42:18 <pchampin> ... As far as what format you use for the test reports,
11:42:42 <pchampin> ... the SPARQL manifest has been used by many groups
11:42:50 <pchampin> ... Shex has moved away from it, but it has a lot of implementations
11:44:11 <pchampin> pchampin: this is complementary to what I presented earlier
11:44:38 <pchampin> laurens: it requires to write our test suite using moccha
11:44:58 <pchampin> ... I'm not enough of a proficient typescript developer to do that
11:45:47 <pchampin> ericP: we should have a look at caniuse , what infrastructure they use
11:46:22 <pchampin> laurens: requiring every server implementation to have an instance up-and-running for testing purposes is probably a lot to ask
11:46:46 <pchampin> ericP: that's an advantage that caniuse people have; they have funding to install the latest version of each browser
11:47:31 <pchampin> ... test suites on W3C have always been based on honor: we trust the implementation report provided by implementers
11:47:55 <pchampin> laurens: as long as the result they push to us respect the expected format, I would be ok
11:48:01 <pchampin> ... even if they do not use the same test suite
11:48:45 <pchampin> ericP: something analogous to caniuse would require that everytime somebody runs a new release, either they or us run the test suite again
11:48:59 <pchampin> laurens: this could work through a PR
11:49:31 <pchampin> ericP: when a test harness is useful enough, people integrate it in their own toolchain
11:50:59 <pchampin> jeswr: we can ask them to provide a link to their implementation
11:51:07 <pchampin> ... I'm pretty sure a company in VC land is doing that
11:51:26 <pchampin> laurens: then again, that's a big thing to ask
11:52:16 <pchampin> ... as an example, for our infrastructure, we know how to setup eidas for authentication, but not everyone may have that skill
11:52:55 <pchampin> ... I could imagine a test suite with some deliberate blank nodes, left up to implementers to fill in
11:53:13 <pchampin> ericP: that raises an interesting point
11:53:26 <pchampin> ... SPARQL, Turtle, have purely declarative test suites
11:53:42 <pchampin> ... in LDP, we had a test suite for servers that was implemented in code, that was managed by one person in the WG
11:54:34 <pchampin> ... it was not declarative at all
11:55:51 <pchampin> ... may require a specific "test-mode" for implementation
11:56:00 <pchampin> pchampin: such a test-mode is an invitation to optimize for the test suite
11:56:43 <pchampin> laurens: ericP you talkes about facets of test suites. Can you say more?
11:57:13 <pchampin> ericP: in SPARQL 1.0, we had a lot of tests, people had partial coverage, we didn't know how to interpret it
11:58:10 <pchampin> ... I parsed the implementation report, and identified certain patterns (for "facets"), giving names to them
11:58:34 <pchampin> ... It was a fair amount of work to do this retroactively, but a lot of fun
11:58:58 <pchampin> ... provided a way to say "this implementation is failing here because they are missing feature A"
11:59:07 <pchampin> laurens: these features could be defined in the spec
12:00:00 <pchampin> ericP: some of these features were actually quite complex
12:00:20 <pchampin> laurens: could be used as an affordance for implementers to understand why given tests fail
12:00:42 <pchampin> ericP: in Shex, the manifest is ordered; a feature is tested before it is used in further tests
12:00:53 <pchampin> ... we were not so diligent about that in SPARQL
12:03:23 <pchampin> pchampin: compliance is about meeting the normative statements; the test suite is a proxy
12:03:47 <pchampin> ... the expected report should maybe have the granularity of the normative statements rather than the tests
12:04:03 <pchampin> ... "features" may be defined as set of normative statements; possibly the sections of the spec
12:04:16 <pchampin> laurens: sections may not be the right grouping
12:04:28 <ericP> https://github.com/shexSpec/shexTest/blob/main/validation/manifest.ttl#L1382
12:04:35 <pchampin> ... also note that the VC test suite refers to normative statements
12:04:44 <pchampin> s/test suite/test reports
12:05:14 <pchampin> ericP: the purpose of the facet tree was to have names for things, but then you can have maps to the normative language
12:06:00 <pchampin> pchampin: I agree; the sections provide a "natural" grouping, but we may find a more relevant one in special cases
12:07:37 <pchampin> ericP: @@1
12:07:40 <ericP> scribe+
12:08:31 <ericP> ericP: we can also demand hooks in e.g. a server implementation to return a T/F for whether a requester is recognized as authorized
12:08:34 <ericP> scribe-
12:09:18 <gibsonf1> gibsonf1 has joined #lws
12:09:23 <gibsonf1> present+
12:09:35 <pchampin> s/ericP: @@1/
12:09:58 <pchampin> topic: Next steps
12:10:29 <pchampin> laurens: I feel that we have general agreement on the discussion abstract entities
12:10:49 <pchampin> ... we are in a position to write text and refine from there
12:12:01 <pchampin> ... acoburn you were willing to start writing something?
12:12:04 <pchampin> acoburn: yes
12:12:28 <pchampin> laurens: regarding Query / Data discovery
12:12:52 <pchampin> acoburn: I think we agreed to start with Type Index, and time-permitting continue with Metadata query
12:12:59 <pchampin> ... I believe that both still needs discussion
12:13:36 <pchampin> laurens: yes, I think we need more discussion about this before we can start writing
12:14:26 <pchampin> ... a lot of the structure of the data in is not going to be specified; so query will be more at the metadata level
12:14:43 <pchampin> acoburn: also there are dependencies between those
12:15:03 <pchampin> bendm: in terms of timeline, it seems that we need to agree on step 1 before we can go to step 2
12:15:56 <pchampin> ... I'm afraid we can go into a rabbit whole of LD vs non-LD in the type index
12:16:07 <pchampin> laurens; also we need to rename Type Index to something else
12:16:49 <pchampin> ... my experience is that reaching agreement in the abstract is harder than reaching agreement on a concrete thing, considering alternatives
12:17:31 <pchampin> ... so I hope to discuss Query / Data discovery with some concrete examples
12:17:48 <pchampin> acoburn: I would be cautious about having too many discussions open at the same time
12:17:56 <pchampin> ... another item is Resource Metadata
12:18:20 <pchampin> ... we have good conversation and some level of alignment
12:18:48 <pchampin> laurens: we also discussed Containers
12:19:12 <pchampin> ... for Resource Metadata and Containers, I would like to have concrete examples
12:19:24 <pchampin> ... Erich Bremer's PR is a good start for Resource Metadata
12:19:29 <pchampin> ... then we can discuss the specific
12:19:34 <pchampin> s/specific/specifics
12:20:25 <pchampin> acoburn: there is also Storage Medatata
12:20:48 <pchampin> laurens: we had less discussion on that
12:21:21 <pchampin> gibsonf1: type index search can be very simple; metadata query is an open search
12:21:35 <pchampin> ... the scope of the metadata description determines the complexity of the metadata search
12:21:58 <pchampin> acoburn: Wednesday we talked about 3 levels of searches
12:22:07 <pchampin> ... one was considered completely out-of-scope
12:22:17 <pchampin> ... type-index (or other name) search was considered as in-scope
12:22:31 <pchampin> ... metadata query was considered between the two, so lower priority
12:22:44 <pchampin> ... I doubt that it is going to happen before most of the other things listed here
12:23:03 <pchampin> laurens: about Storage Metadata
12:23:21 <pchampin> ... we might want to start by writing something, because the scope is narrow enough
12:23:33 <pchampin> ... then we have Authentication
12:24:12 <pchampin> ... on the one hand we have this abstract definition; we discuss cert-asserted identities vs. IDP/OP issues identities
12:24:21 <pchampin> ... go to the identity part with CID
12:24:30 <pchampin> acoburn: I propose 3 topics under Authentication
12:24:39 <pchampin> ... 1. abstract concepts, which we can start immediately
12:24:46 <pchampin> ... 2. bindings to OpenID connect
12:24:50 <pchampin> 3. bindings to OAuth
12:24:57 <pchampin> s/3. b/... 3. b
12:25:22 <pchampin> bendm: also a list of what functionality you need and why, and what bindings you should use for each
12:25:57 <pchampin> laurens: I think before we can start writing on 2 and 3 above, we still need some investigation
12:26:27 <pchampin> acoburn: I think that for authentication itself, we have a good understanding
12:27:03 <pchampin> ... by OpenID and OAuth, I mean "an entity that delegates its identity" vs "an entity that asserts its own identity"
12:27:24 <pchampin> ... you can put my name under Authentication
12:27:48 <pchampin> laurens: I already volunteered for Query / Data discovery; I can propose something to start the discussion
12:27:58 <pchampin> bendm: I volunteered for the Resource Metadata
12:28:12 <pchampin> laurens: then we have Authorization
12:28:34 <pchampin> acoburn: again, we would have to first describe abstract concepts
12:28:51 <pchampin> ... cf. the diagram we had with the boundaries between RP, AS, RS
12:29:04 <pchampin> ... it will be described here at a high level
12:29:59 <pchampin> ... then protocols for the RP-RS, RP-AS, RS-AS, respectiveley
12:30:05 <pchampin> s/eley/ely
12:30:31 <pchampin> bendm: some shared assumptions would need to be described as well
12:30:56 <pchampin> laurens: would access request be another subitem of Authentication?
12:31:09 <pchampin> acoburn: I would consider it as a separate item
12:31:26 <pchampin> laurens: I have some ideas for that; acoburn we could work together on this?
12:31:33 <pchampin> acoburn: yes
12:31:49 <pchampin> ... again, start with abstract concepts
12:32:37 <pchampin> bendm: for me the responsibilies of the AS and RS are still a bit hazy
12:32:58 <pchampin> laurens: we had interesting discussions about this this morning
12:33:14 <pchampin> acoburn: short story: we had the same question, but we found some ideas
12:34:05 <pchampin> ... the question being: can we align what's in access request / access grant with the actual Authz protocol
12:35:11 <pchampin> laurens: we can start to write something about the abstract concepts in Authz and Access request
12:35:21 <pchampin> ... there will be some interactions between the two
12:35:35 <pchampin> ... then we have Notifications
12:36:11 <pchampin> acoburn: I suspect this will still be "abstract concepts / data model / protocol"
12:36:36 <pchampin> ... question whether protocol will include authz or whether this is something different
12:37:06 <pchampin> bendm: sorry for missing the discussion this morning
12:37:16 <pchampin> ... how do notification relate to access grant?
12:38:30 <pchampin> ... are they managed by AS or RS?
12:38:42 <pchampin> acoburn: still in discussion
12:38:56 <pchampin> ... access requests and grants are resources that one can access, but also tied to the AS
12:39:14 <pchampin> laurens: finally: test suite
12:39:33 <pchampin> ... and Use Cases and Requirements
12:40:49 <pchampin> ... I want the UCR to be reflect the state of our discussions
12:41:01 <pchampin> ... thanks to Wonsuk for proposing to help
12:41:45 <pchampin> acoburn: what do people think of keeping the document only those requirements that we decided to address?
12:42:14 <pchampin> laurens: I'm in favour of that. I don't think the documents is supposed to be changelog of the WG's decision process
12:42:26 <pchampin> ... people can look at the github history for that
12:42:57 <pchampin> ... the document should be a more concise view of the current state
12:43:09 <ericP> q+ to propose that the stuff that we decide not to do can still be useful to other spec developers
12:43:28 <pchampin> acoburn: may I propose that eventually, each requirement will point to the normative text that satisfy this requrtement
12:43:55 <pchampin> ... all requirements that point to nothing should go
12:44:07 <pchampin> ... likewise, use-cases linked to no requirements should go
12:44:54 <pchampin> ericP: as we aim to be a foundational spec, there is value in keeping linkable references the requirement that we do not address directly, so that other people could link to them
12:45:07 <pchampin> ... that being said, that's more work
12:45:25 <pchampin> laurens: I'm in favour of that for partially satisfied requirements
12:45:45 <pchampin> ... but we are not exhaustive anyway, so I don't think we should aim for this document to be "lay of the land"
12:47:28 <pchampin> bendm: what we can do is have a version of the spec with all the requirements, then the next version removes them with a link to the last draft containing them
12:47:49 <pchampin> ... "there are the requirements that we chose to not address"
12:48:09 <pchampin> laurens: I would accept that, as long as the final product is more concise
12:48:43 <pchampin> ... I would also like to consolidate some issues by the end of December
12:49:26 <pchampin> ericP: another level of diligence we could go to is close the issues we know we don't want to address
12:49:36 <pchampin> ... we need agreement for the WG to do that
12:50:06 <pchampin> ryey: I made a PR some times ago with additional requieremnts
12:50:24 <pchampin> ... some use-cases do not belong to any requirements, we would like to address this
12:50:47 <pchampin> laurens: I agree, I'll have a look into that
12:51:16 <pchampin> ... also I would like the UCR document to reach a state that is mature enough that we can refer to it when there is discussion on another topic
12:51:42 <pchampin> ... which is a different requirement from checking that all use-cases are covered
12:52:00 <pchampin> ... we can make these adjustments afterwards
12:53:32 <pchampin> acoburn: we don't have names in front of each item, and we need timeframes
12:53:44 <pchampin> laurens: I would like to settle the UCR document by December
12:54:28 <pchampin> acoburn: I intend to start the work on Abstract Entities next week, then turn to Authentication
12:54:38 <pchampin> ... I really would like to have a first draft by the end of this year
12:55:25 <pchampin> ... I would like to have a lot if these in really good shape by April
12:56:51 <pchampin> pchampin: April is a good dealine, because that's the time that we will have to request a charter extension / rechartering
12:57:11 <pchampin> laurens: Notification is something that can probably wait until Q1 2026
12:57:36 <pchampin> acoburn: keeping in mind the general April deadline
12:57:59 <pchampin> ... also, we mentioned a Spring F2F, jeswr?
12:58:14 <pchampin> jeswr: the Solid Symposium is scheduled 30 Apr - 1 May
12:58:41 <pchampin> ... I would suggest we meet 27-29 Apr
13:00:13 <pchampin> acoburn: we still don't have names on some items
13:00:38 <pchampin> ... I volunteer ericP for the test suite
13:01:38 <pchampin> laurens:  we still needs someone for Notification
13:01:54 <pchampin> pchampin: how much could we reuse from Solid Notifications?
13:02:03 <pchampin> jeswr: how much could we reuse from Activity Streams?
13:02:33 <pchampin> laurens: not opposed to reuse parts of Activity Streams, but I don't know enough about it
13:02:41 <pchampin> jeswr: I can have a look at it
13:03:06 <pchampin> ... what I like about the past few days is that we are bringing LWS closer to a number of existing specs
13:04:07 <pchampin> ... by bringing it closer to Activity Pub, we would bring it closer to Mastodon / BlueSky
13:04:26 <pchampin> jeswr: I'm happy to have a look at Containers, and the data model side of Authorization
13:06:05 <pchampin> laurens: time to wrap up; thanks to all who joined, physically and remotely
13:06:13 <pchampin> [all: thanks for hosting]
13:06:26 <pchampin> RRSAgent, make minutes
13:06:28 <RRSAgent> I have made the request to generate https://www.w3.org/2025/10/10-lws-minutes.html pchampin
13:07:27 <pchampin> s/pchampain/pchampin
13:07:32 <pchampin> present+ ericP
13:08:24 <pchampin> s/bartp:/bartb:
13:08:31 <pchampin> s/bart: /bartb: /g
13:08:38 <pchampin> RRSAgent, make minutes
13:08:39 <RRSAgent> I have made the request to generate https://www.w3.org/2025/10/10-lws-minutes.html pchampin
16:15:06 <dmitriz> dmitriz has joined #lws
20:57:02 <dmitriz> dmitriz has joined #lws