14:57:32 <RRSAgent> RRSAgent has joined #lws
14:57:36 <RRSAgent> logging to https://www.w3.org/2025/12/08-lws-irc
14:58:02 <acoburn> acoburn has changed the topic to: Linked Web Storage Working Group meeting - 8 December 2025 - https://www.w3.org/events/meetings/a19ab7dc-1753-433d-bac5-64e3ad8c0a43/20251208T100000/
14:58:17 <acoburn> zakim, start meeting
14:58:17 <Zakim> RRSAgent, make logs Public
14:58:19 <Zakim> please title this meeting ("meeting: ..."), acoburn
14:58:38 <TallTed> TallTed has joined #lws
14:58:43 <acoburn> meeting: Linked Web Storage Working Group
14:58:47 <acoburn> agenda: https://www.w3.org/events/meetings/a19ab7dc-1753-433d-bac5-64e3ad8c0a43/20251208T100000/#agenda
14:58:47 <agendabot> clear agenda
14:58:47 <agendabot> agenda+ Introductions and announcements
14:58:47 <agendabot> agenda+ Authentication questions from last week
14:58:47 <agendabot> agenda+ Authorization discussion
14:58:47 <agendabot> agenda+ CRUD & Metadata proposal
14:59:42 <ericP> present+
15:00:11 <elf-pavlik> present+
15:00:30 <acoburn> present+
15:00:38 <gibsonf1> gibsonf1 has joined #lws
15:00:44 <gibsonf1> present+
15:00:48 <pchampin> present+
15:01:23 <eBremer> eBremer has joined #lws
15:01:31 <eBremer> present+
15:01:54 <TallTed> present+
15:02:35 <bendm> bendm has joined #lws
15:02:42 <bendm> present+
15:02:57 <RRSAgent> I have made the request to generate https://www.w3.org/2025/12/08-lws-minutes.html TallTed
15:03:05 <acoburn> chair: ericP
15:03:36 <bendm> scribe+
15:03:40 <TallTed> previous meeting:  https://www.w3.org/2025/12/01-lws-minutes.html
15:03:42 <TallTed> next meeting:  https://www.w3.org/2025/12/15-lws-minutes.html
15:03:58 <dmitriz> dmitriz has joined #lws
15:04:12 <ericP> take up next agendum
15:04:26 <acoburn> zakim, open agendum 1
15:04:26 <Zakim> agendum 1 -- Introductions and announcements -- taken up [from agendabot]
15:04:37 <RRSAgent> I have made the request to generate https://www.w3.org/2025/12/08-lws-minutes.html TallTed
15:04:43 <bendm> ericP: we have guest star Elf Pavlik, specifically for authorization
15:05:02 <ericP> take up next agendum
15:05:41 <bendm> elf-pavlik: I have been working on Solid-OIDC, and implemented other draft, and on SAI
15:05:48 <bendm> ... which deals with app authz specifically
15:06:05 <bendm> ... and I'll work on a Solid Symposium session on authz and security
15:06:21 <bendm> ... I also created a sequence diagram for the current PRs
15:06:26 <bendm> ... happy to be here!
15:06:44 <ericP> take up next agendum
15:06:48 <bendm> ericP: at some point, I want a session on SAI
15:07:30 <TallTed> Zakim, next item
15:07:30 <Zakim> agendum 2 was just opened, TallTed
15:07:33 <pchampin> RRSAgent, make minutes
15:09:28 <acoburn> https://github.com/w3c/lws-protocol/pull/43
15:09:28 <gb> https://github.com/w3c/lws-protocol/pull/43 -> Pull Request 43 LWS Authentication (by acoburn)
15:07:35 <RRSAgent> I have made the request to generate https://www.w3.org/2025/12/08-lws-minutes.html pchampin
15:08:18 <bendm> acoburn: I wanted to raise this agendum as we talked last week mostly on authn
15:08:36 <bendm> ... so if anyone has any remarks that isn't part of the PR yet, go ahead
15:09:00 <elf-pavlik> q+
15:09:06 <bendm> dmitriz: what is the outcome of last week's call?
15:09:47 <bendm> acoburn: this PR describes an abstract framework for having an authentication suite
15:09:52 <bendm> ... and specifies some concrete suites
15:10:03 <bendm> ... one shows how it would be used with SAML
15:10:08 <bendm> ... mostly to show that it's possible
15:10:17 <bendm> ... another suite using client credentials, another using DIDs
15:10:28 <bendm> ... showing the way it works and what the basic components are
15:10:58 <RRSAgent> I have made the request to generate https://www.w3.org/2025/12/08-lws-minutes.html TallTed
15:11:04 <bendm> ... we hope that next monday we can have a vote on authn and authz
15:11:14 <bendm> ... so that we can begin building on that
15:11:20 <ericP> ack next
15:11:47 <bendm> elf-pavlik: I noticed on FED-ID slack, they're discussing that
15:12:18 <bendm> ... they kind of agreed that SAML might be more supported than OIDC, which is a nice data point
15:12:30 <jeswr> jeswr has joined #lws
15:12:35 <jeswr> present+
15:12:36 <jeswr> q+
15:12:36 <bendm> ... what's the plan for testing, and what's the feedback from implementers?
15:12:51 <ericP> q+ to say that i'd probably require a toy authN for the test suite
15:12:58 <bendm> ... eg solid-OIDC was only implemented in JAVA in Inrupt
15:13:01 <ericP> ack next
15:13:17 <bendm> jeswr: Dmitri: is this specification in any way aligned with Social Web WG?
15:13:28 <bendm> ... could we have something that could be implemented by both?
15:13:32 <bendm> dmitriz: good question
15:13:36 <TallTed> i|agendum 2 was just opened, TallTed|topic: Authentication questions from last week
15:13:46 <RRSAgent> I have made the request to generate https://www.w3.org/2025/12/08-lws-minutes.html TallTed
15:13:55 <bendm> ... Social Web space mostly uses combination of OAuth for client API and httpsig for server-to-server authn
15:14:10 <bendm> ... they don't have implementations of oidc
15:14:22 <elf-pavlik> q+
15:14:31 <ericP> ack next
15:14:32 <Zakim> ericP, you wanted to say that i'd probably require a toy authN for the test suite
15:14:32 <bendm> ... we could present it, some implementations might find it useful
15:14:37 <TallTed> present+ dmitriz
15:15:01 <bendm> elf-pavlik: the main difference with activitypub, is that the client connects to more servers than only the user's server
15:15:17 <bendm> ... in activitypub, it feels more like client-client server, then more server to server
15:15:45 <bendm> ... in Solid, I understand Christoph's work using a proxy-based approach, which is closer to how activitypub works
15:16:00 <bendm> ... it feels a bit as a gap between both architectures at this point, I think
15:16:03 <ericP> ack next
15:16:09 <elf-pavlik> q-
15:16:36 <bendm> ericP: regarding testing, we can have a toy authn/authz scheme
15:17:09 <bendm> ... like they did for SPARQL
15:17:25 <bendm> ... if we include authn or authz as more than a note (i.e. as a REC), then we must test it
15:17:42 <ericP> take up next agendum
15:17:54 <RRSAgent> I have made the request to generate https://www.w3.org/2025/12/08-lws-minutes.html TallTed
15:18:02 <acoburn> Topic: Authorization discussion
15:18:03 <acoburn> https://github.com/w3c/lws-protocol/pull/45
15:18:04 <gb> https://github.com/w3c/lws-protocol/pull/45 -> Pull Request 45 LWS Authorization (by acoburn)
15:18:19 <bendm> acoburn: there has been some engagement already on this PR
15:18:46 <bendm> ... this is an attempt to bring Solid more fully under the OAuth authz scheme
15:19:24 <RRSAgent> I have made the request to generate https://www.w3.org/2025/12/08-lws-minutes.html TallTed
15:19:47 <bendm> ... [showing the diagram]
15:20:00 <RRSAgent> I have made the request to generate https://www.w3.org/2025/12/08-lws-minutes.html TallTed
15:20:06 <bendm> ... how Solid works today, is that the ID token is used as authorization token
15:20:23 <bendm> ... idea is, to take Solid what it currently does, and bring closer to how OAuth works
15:20:30 <bendm> ... i.e., having a dedicated authorization server
15:21:15 <bendm> ... issue with using global ID tokens: a storage getting an ID token could reuse that token. that's why DPOP was added, but that adds complexity
15:21:32 <bendm> ... idea is that we move that complexity elsewhere
15:22:02 <bendm> ... so the application could take an identity credential (could be an OIDC ID token, could be SAML, etc)
15:22:08 <gibsonf1> q+ to ask about AS
15:22:09 <bendm> ... which gets exchanged for an access token
15:22:18 <bendm> ... this is used by the storage
15:22:21 <TallTed> q+ to ask whether the mentions of Solid here are as a prototypical implementation of LWS
15:22:24 <bendm> ... that storage cannot reuse that token
15:22:52 <bendm> ... we're putting all that token exchange as part of the authorization server
15:23:08 <bendm> ... it's functionalities: verify the identity token, that the token is scoped correctly, etc
15:23:18 <bendm> s/it's functionalities/its functionalitites
15:23:25 <acoburn> ack next
15:23:26 <Zakim> gibsonf, you wanted to ask about AS
15:23:44 <bendm> gibsonf1: on the authz server: you're saying 'this ID token is for this storage'?
15:23:50 <bendm> acoburn: it's an exchange
15:24:15 <elf-pavlik> q+
15:24:17 <bendm> ... from an authn token to an access token
15:24:42 <bendm> ... once the access token is sent to storage, you can see 'can this particular user access this particular resource?'
15:24:42 <ericP> ack next
15:24:45 <Zakim> TallTed, you wanted to ask whether the mentions of Solid here are as a prototypical implementation of LWS
15:24:46 <pchampin> q+
15:24:47 <acoburn> ack next
15:25:07 <bendm> TallTed: is Solid mentioned as prototypical implementation of LWS?
15:25:14 <bendm> ... otherwise we'll get in trouble down the road
15:25:47 <bendm> acoburn: yes, indeed, Solid is brought to center the conversation
15:26:12 <bendm> ... so it gives a migration path, and we don't discuss anything brand new
15:26:20 <ericP> ack next
15:26:29 <bendm> ... we are not saying 'this is what solid does, so this is what lws does'
15:26:43 <elf-pavlik> q?
15:26:47 <elf-pavlik> q+
15:26:56 <bendm> pchampin: why is it better to send it to the AS instead of the storage?
15:27:02 <bendm> ... what do we gain here?
15:27:09 <bendm> acoburn: we mainly gain that we align with OAuth
15:27:30 <bendm> q+ to say we also gain separation of concerns (cfr data spaces)
15:27:57 <bendm> ... we use the OAuth protocol to gather a real access token and use it as an access token
15:28:10 <bendm> ... instead of trying to reuse an ID token as an access token
15:29:00 <ericP> ack bendm
15:29:00 <Zakim> bendm, you wanted to say we also gain separation of concerns (cfr data spaces)
15:29:37 <ericP> scribe+
15:30:23 <pchampin> that makes sense, thanks a lot
15:30:34 <ericP> bendm: the advantage of passing the ID to the authN server is that you get a separation of concearns
15:30:52 <ericP> scribe-
15:31:06 <bendm> bendm: so, eg, you can have a set of storage servers managed by one AS, where you only need to trust the AS, not all individual storage serves
15:31:51 <RRSAgent> I have made the request to generate https://www.w3.org/2025/12/08-lws-minutes.html TallTed
15:32:10 <bendm> acoburn: also, you could have a SAML assertion, that you can exchange for an access token
15:32:28 <bendm> ... so you could combine the signed XMLs with JWTs
15:32:47 <bendm> ... also, the AS could supports many different types of credentials
15:33:01 <bendm> ... meanwhile, being able to consolidate the functionality of an access token
15:33:15 <ericP> ack next
15:33:22 <elf-pavlik> https://elf-pavlik.github.io/lws-auth/view/oidc/?dynamic=sequence
15:33:34 <bendm> elf-pavlik: this sequence diagram
15:33:43 <bendm> ... what I tried to emphasize are the security domains
15:33:52 <bendm> ... in OAuth, access tokens should not cross security domains
15:34:41 <bendm> ... in Solid, global access tokens were used, even broader than id token
15:34:56 <bendm> ... now, we can go to UMA or OAuth token exchange
15:35:04 <bendm> ... this diagram shows the different security domains
15:36:42 <bendm> ... this diagram also introduce another token exchange: from id token to access token of your own AS, to access token to the storage server's AS
15:36:47 <bendm> ... it's a bit more chatter, but compliant
15:36:59 <dmitriz> I think this might be adding a bit more complexity than maybe we need?
15:37:14 <bendm> acoburn: about sender-constrained: other than DPOP, we use the audience claim very loosely
15:37:37 <bendm> ... in a JWT, `aud` is used to constrain the token
15:38:11 <ericP> q?
15:38:11 <bendm> ... this interaction allows to use the audience constraint to make sure these tokens don't become global
15:38:28 <dmitriz> q+
15:38:37 <ericP> ack next
15:38:54 <bendm> dmitriz: let's make clear which problem we're solving
15:39:13 <bendm> ... alignment with what other protocols were meant to do, is not a great argument
15:39:32 <bendm> ... e.g. OAuth 2 has recently gotten the client metadata document
15:39:47 <bendm> ... which is the result of a multi-year conversation, inspired by WebID documents
15:40:01 <bendm> ... the other direction to consider, is to work to update the OAuth and OpenID specifications
15:40:11 <elf-pavlik> q+
15:40:45 <bendm> acoburn: it's fair to ask "what about aligning OAuth with LWS?"
15:40:55 <bendm> ... however, having OAuth change seems like a very big ask
15:41:35 <bendm> ... which doesn't seem realistic with our timeline
15:42:28 <bendm> dmitriz: what I mostly want to say: I want us to be very clear what extra complexity is really needed
15:42:51 <bendm> acoburn: what elf was talking about: there could be intermediate token exchange, but those will be deployment and use case specific
15:43:04 <bendm> ... they don't directly apply to LWS
15:43:47 <ericP> ack next
15:43:51 <bendm> ... the main reason is to have access tokens, aligning with OAuth is a good to have
15:44:21 <bendm> elf-pavlik: everyone says 'use existing authn/authz protocols, don't invent your own'
15:44:35 <bendm> ... in CSS, okta libraries are used, and that's a good thing
15:45:10 <dmitriz> q+
15:45:22 <bendm> ... cfr. about the additional token exchanges: that's for sender-constrained access tokens
15:45:43 <bendm> ... other extensions are also possible, eg for client applications
15:45:44 <ericP> ack next
15:45:57 <bendm> dmitriz: why not just sender-constrain the dpop tokens?
15:46:24 <bendm> elf-pavlik: because dpop is used for access tokens, and access tokens should not cross security domains
15:46:55 <bendm> ... we could ask IETF to extend the dpop definition, but, e.g. for app authorization we need another way
15:47:18 <bendm> ... we just need some way to create sender-constrained tokens
15:47:43 <bendm> acoburn: this interacts with the authentication proposal:
15:48:03 <bendm> ... for every authentication suite, you must have a token type uri
15:48:10 <bendm> ... it must be from iaana
15:48:23 <bendm> ... e.g. saml2 or oidc token
15:48:46 <bendm> ... (it SHOULD be from IANA, but it MUST be an URI)
15:49:08 <bendm> ... so e.g., for WebID, we must define a URI that covers that kind of credentials
15:49:50 <bendm> ... AS should broadcast what type of tokens they support (eg JWT or ID Token)
15:50:27 <bendm> ... using the `resource` parameter, you can restrict the token to a single storage
15:50:38 <ericP> q?
15:50:49 <elf-pavlik> q+ re authz apps
15:50:50 <ericP> agenda?
15:51:11 <bendm> acoburn: so please have a look that the PRs
15:51:45 <bendm> ... most is on section 5, and there are some security and IANA considerations
15:52:09 <bendm> ... if there's consensus, I'd like to merge these in 2025
15:52:21 <bendm> ... so, by next meeting
15:52:35 <ericP> next agendum
15:52:43 <bendm> acoburn: there's another proposal from eBremer
15:52:51 <bendm> ... on CRUD and metadata
15:52:55 <acoburn> https://github.com/w3c/lws-protocol/pull/37
15:52:55 <gb> https://github.com/w3c/lws-protocol/pull/37 -> Pull Request 37 Initial CRUD with proposed metadata handling (by ebremer)
15:53:02 <ericP> ack next
15:53:03 <Zakim> elf-pavlik, you wanted to discuss authz apps
15:53:13 <elf-pavlik> https://www.ietf.org/archive/id/draft-ietf-oauth-identity-assertion-authz-grant-01.html#name-response
15:53:14 <TallTed> i|another proposal|topic: CRUD & Metadata proposal
15:53:28 <RRSAgent> I have made the request to generate https://www.w3.org/2025/12/08-lws-minutes.html TallTed
15:53:34 <bendm> elf-pavlik: can we discuss authorizing applications?
15:53:58 <bendm> ... eg the aud tag could provide scopes
15:54:02 <acoburn> q+
15:54:52 <acoburn> q-
15:55:11 <bendm> ... so client applications (the server needs to allow something that the application wants, not necessarily something that the user wanted)
15:55:28 <bendm> ... is an interesting follow up topic
15:55:36 <ericP> next agendum
15:55:46 <bendm> eBremer: about the crud PR
15:56:01 <bendm> ... 7 describes the functionalities, going into 8, and 9 specifies the mapping
15:56:29 <RRSAgent> I have made the request to generate https://www.w3.org/2025/12/08-lws-minutes.html TallTed
15:56:36 <bendm> ericP: see you next week, please review the PRs, and next week we vote on authn and authz
15:56:57 <bendm> acoburn: and 15/12 is the final LWS meeting of 2025, next one will be January 5th
15:57:36 <TallTed> s|15/12|2025-12-15
15:57:36 <pchampin> RRSAgent, make minutes
15:57:38 <RRSAgent> I have made the request to generate https://www.w3.org/2025/12/08-lws-minutes.html pchampin
15:58:25 <acoburn> acoburn has left #lws
16:00:46 <pchampin> RRSAgent, bye
16:00:46 <RRSAgent> I see no action items