13:59:32 RRSAgent has joined #lws 13:59:36 logging to https://www.w3.org/2025/04/28-lws-irc 13:59:38 Zakim has joined #lws 13:59:45 zakim, start meeting 13:59:45 RRSAgent, make logs Public 13:59:48 please title this meeting ("meeting: ..."), acoburn 13:59:52 meeting: Linked Web Storage 14:00:05 chair: acoburn 14:00:11 RRSAgent, make minutes 14:00:12 I have made the request to generate https://www.w3.org/2025/04/28-lws-minutes.html acoburn 14:00:26 hadrian has joined #lws 14:00:36 present+ 14:00:48 dmitriz has joined #lws 14:00:55 agenda: https://www.w3.org/events/meetings/a19ab7dc-1753-433d-bac5-64e3ad8c0a43/20250428T100000/#agenda 14:00:56 clear agenda 14:00:56 agenda+ Introductions and announcements 14:00:56 agenda+ Action items 14:00:56 agenda+ Discussion: Authentication and related use cases 14:00:56 agenda+ Use cases update 14:02:29 ryey has joined #lws 14:02:32 AZ has joined #lws 14:02:32 present+ 14:02:41 present+ 14:02:41 ericP has joined #lws 14:02:53 present+ 14:03:06 jeswr has joined #lws 14:03:13 present+ 14:03:38 scribenick: jeswr 14:03:40 present+ 14:03:52 present+ 14:04:07 zakim, open agendum 1 14:04:07 agendum 1 -- Introductions and announcements -- taken up [from agendabot] 14:05:23 zakim, open agendum 2 14:05:23 agendum 2 -- Action items -- taken up [from agendabot] 14:05:57 present+ 14:06:04 ericP has joined #lws 14:06:21 present+ 14:06:31 acoburn: only action item is weekly overview of use-cases, are there any closed issues? 14:07:47 hadrian: No, there are no closed issues. There is a closed PR; with a lot of changes from Pierre Antoine resolving glossary terms and linking to various parts of the document and removing external references 14:08:28 -> https://github.com/w3c/lws-ucs/pull/145 merged PR 14:08:29 https://github.com/w3c/lws-ucs/pull/145 -> MERGED Pull Request 145 add cross-link to glossary definition in the glossary (by pchampin) 14:08:42 zakim, open agendum 3 14:08:42 agendum 3 -- Discussion: Authentication and related use cases -- taken up [from agendabot] 14:09:50 kaefer3000 has joined #lws 14:10:09 acoburn: We have been having an open-ended discussion around portability. There will be more conversation, but we have have a general sense of the scope. We don't want to add a requirement that will prevent portability (e.g. requiring that all resources are HTTPS URLs). 14:10:26 ...: We now need to move on and discuss other areas - starting with Authentication. 14:11:02 ... authentication is how you validate the identity of an entity (user, agent application etc.) 14:12:13 ... there are a number of use cases around authentication, e.g. #51 passkeys, #41, and #39 and #40 are about browser authentication. #90 and #147 are also about attestation of client identity 14:12:13 Issue 51 not found 14:12:13 Issue 41 not found 14:12:13 Issue 39 not found 14:12:13 Issue 147 not found 14:12:13 Issue 90 not found 14:12:15 Issue 40 not found 14:13:01 ... there are two requirements (127 and 128) which are about identity providers and service providers - and the requisite trust for these providers 14:13:34 ... there are 3 high level things in all of this. Browser based authentication, non-browser authentication, and common to both: how one proves an identity is to be trusted 14:13:39 bendm has joined #lws 14:13:45 q? 14:13:52 present+ 14:14:39 ... historically in Solid, there was WebId-TLS which was more of a server-server mechansim. There were a lot issues which made this challenging to use 14:15:00 ... today most Solid servers use some version of OIDC which is well defined and much wider than Solid 14:15:16 ericP has joined #lws 14:15:28 ... the Solid CG produced a specification called Solid OIDC which defines a mechanism for making use of OIDC in the context of Solid. It describes how identity validation happens 14:16:12 ... OIDC works well for a browser context. I suspect that when we talk about authentication in the browser, OIDC will be a significant part of that. It falls apart when we talk about server-server communication. 14:16:39 ... I've tried to get OIDC working for server-server communication, it sort of works, but not well 14:16:50 q+ to ask how openid fails in server-to-server 14:16:58 ack next 14:16:59 ericP, you wanted to ask how openid fails in server-to-server 14:17:05 q+ to ask about scope 14:17:09 ... It is also worth noting that there are also a number of other specifications for authentication like SAML and GNAP 14:17:25 ericP: Mechanically what goes wrong with OIDC server-server authentication 14:17:36 q+ to ask about webid+tls 14:18:02 acoburn: OIDC is based on OAuth2. You can do server-server communication fine in OAuth2, but OIDC is all about one particular flow in OAuth2 14:18:17 ... which is about interactions in a browser 14:18:26 q? 14:18:29 ... so doing this outside of a browser is uncomfortable at best 14:18:33 ack next 14:18:34 hadrian, you wanted to ask about scope 14:19:05 hadrian: Authn and AuthZ are fairly complex. I assume we don't want to tie ourselves to a particular AuthN spec, or boil the ocean. 14:19:33 +1 on Hadrian's comment 14:19:37 ... so can our requirement be that we turn up to the resource server with some kind of token and not mandate the authN spec by which that is obtained 14:19:50 ericP: The question of whether it goes in the spec is more editorial 14:20:06 ... when we introduce profiles in specs, it creates complexity and people tend to resist 14:20:44 ... so in our context, say we are offering an Identity server that OIDC and another uses SAML, and we want a resource server that works with both of those; then we'd want to define ??? 14:20:57 ... the question of whether it is orthogonal or not depends on whether ??? 14:21:39 dmitri: I agree with everything that Aaron said. We want the least amount of choice for implementors. We also want upgrade paths as new AuthN protocols come along. 14:22:02 q+ to say that having defaults that all LWS servers will support will enable any application to work at minimum with default 14:22:42 ... the most impactful thing this group can do is say here are the requirements that an authentication mechanism needs to have (identify the agent, identify the user, work well with delegation, whenever possible support a dereferencable metadata document like a WebID). 14:22:52 q? 14:22:57 ... that gives flexibility for implementors evaluating the criteria to work out if it fits 14:23:04 ack next 14:23:05 kaefer, you wanted to ask about webid+tls 14:23:08 s/dmitri:/dmitriz/ 14:23:55 q+ to mention more specific limitations of (Solid-)OIDC in the browser in the context of a "decentralised" ecosystem 14:23:57 kaefer3000: WebID+TLS have gotten bad press largely because of the way a particular browser implemented it, so I wanted to encourage a more neutral stance on that specification 14:24:01 q+ 14:24:03 q+ 14:24:10 q? 14:24:15 ... If I have time I can find a piece describing this 14:24:29 q- 14:24:55 dmitriz: I know the opinion piece justifying WebID+TLS. I would encourage this group to ignore it because all browsers have dropped support 14:25:14 kaefer3000: If you supply your browser with a certificate it works perfectly 14:25:26 dmitriz: That doesn't really work well right now 14:25:42 kaefer3000: The UX may be bad, but it is implementable 14:26:22 q? 14:26:30 acoburn: The positions are well laid out. I don't want to get into the nuances. As it currently exists, it is very hard from a user perspectives - but there are interesting parts of it that may be useful for server-server authentication. As a browser protocol it has severe limitations 14:27:22 q? 14:28:03 csarven: I agree with acorn and dmitriz, but there are also some parts of WebID+TLS that we can pull out. If I recall correctly they were also trying to do authentication on their own layer. The Technical Architecture Group wrote a finding on this in 2015, the associated repo is now being archived because keygen is now deprecated for browsers and 14:28:03 HTML5. 14:28:27 ... I like the approach, and think it is efficient, but I'm not sure how smooth this thing can be 14:28:38 s/acorn/acoburn/ 14:28:51 ... we also have things like HTTP signatures which hint in that direction 14:29:00 ack next 14:29:01 gibsonf, you wanted to say that having defaults that all LWS servers will support will enable any application to work at minimum with default 14:29:44 gibsonf: For these kind of decisions, it would be great to have the lowest common demonator of requirements that will be a MUST to make sure there is at least a way of all apps working with all servers 14:29:58 s/keygen is now/keygen has 14:30:14 q? 14:30:19 s/archived/archived https://w3ctag.github.io/client-certificates/ 14:30:25 ack next 14:30:26 csarven, you wanted to mention more specific limitations of (Solid-)OIDC in the browser in the context of a "decentralised" ecosystem 14:30:31 acoburn: The tightrope we all there is that we don't want to require something that is insecure or deprecated, but we do want to allow some level of interop 14:30:47 q+ 14:32:24 csarven: My understanding of OIDC and SOLID OIDC in general is that when we are talking about the browser and web platform; it is important to distinguish the aspects we are talking about within the context of the Web Browser. We have the application layer, things that are native to the Web browser, and the extension layer. This all happens within 14:32:24 the desktop or mobile browser. In Solid we have a URI which is bound to where they started off and where they are redirected to when authentication finishes. 14:32:43 ... this breaks when we have extensions which want to be statically registered 14:32:51 ... as users can trigger extensions on any web page 14:33:40 ... so the user will not be able to get back to where they started off in the extensions as the IDP will not be aware of it 14:33:58 ... so there are things in SOLID-OIDC today which do not work well in the browser either 14:34:16 cpn has joined #lws 14:34:20 present+ 14:34:43 ... in dokeli it doesn't seem like static registration will work out - as dokeli can also work as a browser extension 14:35:00 ... so we should be careful about how we select the kind of use cases that we want to enable 14:35:20 q? 14:35:37 ... e.g. I cannot annotate web pages via a Solid extension 14:36:04 ack next 14:36:06 acoburn: It comes down to how one can identify an application, and whether this is ephemeral (e.g. dynamic) or ongoing in the case of static client 14:36:07 scribe+ 14:36:38 jeswr: re WebID+TLS, my understanding of the new WebAuthN (w/ Passkeys) provides a similar set of features 14:36:57 ... that's not to say that we should require it, but we should be able to use that 14:37:25 scribe- 14:37:30 acoburn: I am a big fan of passkeys, and what we do should not get in the way of that 14:37:31 (very different functionality, unfortunately. (passkeys vs webid tls)) 14:37:32 q? 14:37:41 ack next 14:38:23 q? 14:38:26 hadrian: When it comes to scale, we cannot assume all providers will use the same technology. Some adaptation needs to happen in the infrastructure which is a detail that we will need to account for later 14:39:28 acoburn: We have largely talked about browser-server interactions so far. OIDC is one answer to that. There are and likely will be others. I want to leave the server-server conversation for next week. 14:39:33 s/Solid extension/Solid-OIDC's static registration with a browser extension 14:39:51 s/dokieli/dokieli ( https://dokieli/ ) 14:39:57 ... there are existing solutions for server-server Client Credentials, emergent solutions like HTTPSig, and a range of other solutions e.g. DIDComm 14:40:09 ... today none of that is within the Solid CG specifications 14:40:29 ... We need to get shared context of our scope, and understand how we will approach that in a tractable way in the context of the specification 14:40:58 s/authentication on their own layer/authentication on the wrong layer 14:41:12 dmitriz: On the difference between passkeys and webbed tls 14:41:23 s/wrote a finding/wrote a draft Finding 14:41:41 RRSAgent, make minutes 14:41:42 I have made the request to generate https://www.w3.org/2025/04/28-lws-minutes.html acoburn 14:42:16 ... WebID tls was cross domain, the identity stays the same across all services. I.e. my identity dmitri.com can stay the same across all websites I visit. A key generated by a passkey, unlike a WebID certificate is generated by a browser and narrowly scoped to the domain I am authenticating into. 14:42:55 ... Note that passkeys refer to WebAuthn and mediated ??? e.g. where google and apple replicate the keys across devices 14:43:14 ... The authors of the spec narrowly meant it to be a replacement for username and password for a single server 14:43:37 kaefer3000 has joined #lws 14:43:40 ... I agree with acoburn, it is an important tool in our toolbox, but can't replace WebID+TLS 14:45:39 acoburn: We should also keep in mind the various architectures that people will have when writing applications. Everything from (1) a single page application - which cannot effectively manage secrets over the course of their lifetime, (2) a frontend to backend architecture where your application talks to a backend which talks to solid server (3) a 14:45:39 ??? where it is possible to manage secrets securely (4) a server-server interaction with an automated system or bot (5) server-server where the server is acting on behalf of a particular agent; e.g. refresh tokens in an OAuth2 context 14:45:49 q+ 14:45:57 ack next 14:46:01 ... we can't look into the crystal ball to know what the next auth architecture is going to be. But we don't want to make it hard or impossible to implement 14:46:36 hadrian: For this reason I don't think we should try and find the best solution - this is a fools errand. I would rather spending the time focussing on interoperability. 14:47:40 acoburn: Rather than specifying which authentication protocol should be used, we could instead define which token should be used to access a secure resource (e.g. it should identify the user, it should identify the application). Then in a separate document we could then say how that would play out with OIDC and other protocols 14:47:50 zakim, open agendum 4 14:47:50 agendum 4 -- Use cases update -- taken up [from agendabot] 14:48:30 hadrian: With use cases my plan is to be done by the end of the month for categorising. I am almost done, there are some branches I am creating PRs for. 14:48:43 s/and mediated ???/plus platform-mediated key replication/ 14:48:46 ... there are several use cases that took time to decide what to do with because they are broad 14:49:37 acoburn: Next week we may want to continue discussing server-server authentication. If UCS is ready for review should we focus on that instead? 14:50:07 hzerbaca: We didn't discuss how we feel about local-first, and other things 14:50:40 present+ 14:50:42 scribe+ 14:51:09 acoburn: Hadrian, is there anything that this group can help out with, in the meantime? or wait til PRs come and review at that point? 14:51:09 hadrian: no, not at this point 14:51:14 present+ 14:51:18 ... I appreciate the conversations on this topic, and group should continue 14:51:31 present+ 14:51:35 ... another thing that was asked by other people (PAC?) is how do we start making progress on the Protocol Spec per se 14:51:55 acoburn: yes. first step, we make sure we have a clear Use Cases and Reqs doc that we have consensus on 14:52:06 ... then basically the chairs will need to identify some editors 14:52:17 ... who will then go forth and begin writing spec language to encapsulate answers to the requirements 14:52:25 ... Eric, anything you'd like to add? 14:52:46 s/dokieli\//dokie.li\/ 14:53:09 ... (eric's offline). Hardian, anything else about Use Cases update? 14:53:19 ... any other business to discuss? 14:53:23 q? 14:53:30 ... then I think we can end a few mins early 14:53:36 s/Hardian/Hadrian/ 14:54:05 RRSAgent, make minutes 14:54:06 I have made the request to generate https://www.w3.org/2025/04/28-lws-minutes.html acoburn 14:54:24 gibsonf1 has left #lws 14:55:26 s/??? where it is/... native app, where it is/ 14:55:35 RRSAgent, make minutes 14:55:36 I have made the request to generate https://www.w3.org/2025/04/28-lws-minutes.html acoburn 14:56:36 acoburn has left #lws