15:00:57 <RRSAgent> RRSAgent has joined #lws
15:01:01 <RRSAgent> logging to https://www.w3.org/2026/02/16-lws-irc
15:01:01 <Zakim> RRSAgent, make logs Public
15:01:02 <Zakim> please title this meeting ("meeting: ..."), laurens
15:01:16 <acoburn> present+
15:01:16 <laurens> meeting: LWS WG Meeting - February 16th, 2026
15:01:19 <eBremer> present+
15:01:33 <AZ> AZ has joined #lws
15:01:36 <laurens> agenda: https://www.w3.org/events/meetings/a19ab7dc-1753-433d-bac5-64e3ad8c0a43/20260216T100000/
15:01:38 <agendabot> clear agenda
15:01:38 <agendabot> agenda+ Introductions & Announcements
15:01:38 <agendabot> agenda+ Issue Triage
15:01:38 <agendabot> agenda+ -> Agent Identification #57 https://github.com/w3c/lws-protocol/issues/57
15:01:38 <agendabot> agenda+ -> LWS Container Media Type #61 https://github.com/w3c/lws-protocol/issues/61
15:01:41 <agendabot> agenda+ -> Terminology: Resource Manager / Resource Controller / ... #27 https://github.com/w3c/lws-protocol/issues/27
15:01:49 <AZ> present+
15:02:03 <laurens> present+
15:02:07 <laurens> chair: laurens
15:02:14 <Luke> Luke has joined #lws
15:03:59 <gibsonf1> gibsonf1 has joined #lws
15:04:16 <gibsonf1> present+
15:04:36 <acoburn> scribenick: acoburn
15:04:36 <pchampin> present+
15:05:05 <acoburn> zakim, open agendum 1
15:05:05 <Zakim> agendum 1 -- Introductions & Announcements -- taken up [from agendabot]
15:05:41 <uvdsl> present+
15:06:12 <acoburn> laurens: seeing no announcements, moving along
15:06:12 <Luke> present+
15:06:17 <acoburn> zakim, open agendum 2
15:06:17 <Zakim> agendum 2 -- Issue Triage -- taken up [from agendabot]
15:06:20 <RazaN> RazaN has joined #lws
15:06:55 <acoburn> laurens: sharing screen from https://github.com/w3c/lws-protocol/issues
15:07:21 <acoburn> ... eBremer, as I understand, will create a PR to address #24
15:07:22 <gb> https://github.com/w3c/lws-protocol/issues/24 -> Issue 24 Reasons for separate rest bindings (by jeswr) [ready-for-pr]
15:07:43 <acoburn> ... eBremer assigned to the issue and marked as "ready for pr"
15:07:55 <acoburn> ... no new issues in the last week
15:08:20 <acoburn> zakim, open agendum 3
15:08:20 <Zakim> agendum 3 -- -> Agent Identification #57 https://github.com/w3c/lws-protocol/issues/57 -- taken up [from agendabot]
15:09:06 <acoburn> laurens: opened by uvdsl about use of CID documents in the current LWS protocol
15:09:13 <acoburn> ... room for collaboration with Solid CG
15:09:30 <acoburn> ... some consensus about how to bring WebID-based AuthN in line with current proposal
15:09:42 <acoburn> ... might also warrant further discussion
15:09:48 <RazaN> Present+
15:10:12 <acoburn> uvdsl: the issue is a bit broader than just discussion CID and how to make it work with WebID
15:10:39 <acoburn> ... as proposed in the comments, concern about the requirement to use a URI for an agent identifier
15:11:16 <acoburn> laurens: there are two parts: (1) identity requirements, as currently formulated and (2) compatability problem with WebIDs
15:11:38 <acoburn> ... what are the reservations about agents being identified as URIs?
15:12:05 <acoburn> uvdsl: mostly concerned about dereferencing of URIs
15:12:19 <acoburn> ... worried about interop aspects
15:12:27 <acoburn> q+ to talk about dids
15:12:47 <laurens> ack acoburn
15:12:47 <Zakim> acoburn, you wanted to talk about dids
15:13:14 <laurens> acoburn: The minimum requirements for agent identification indeed involves URIs, not necessarily even HTTP URIs
15:13:36 <laurens> ... we want both compatibility with what was used in Solid, but also provide interop with DID.
15:13:49 <laurens> ... If we constrained to HTTP URIs that would explicitly exclude DID.
15:13:54 <uvdsl> q+ to say that the proposal in the Issue says: Not limiting generality, HTTP(S)/REST is the baseline implementation requirement.
15:13:59 <laurens> ... Now we do allow both forms.
15:14:20 <laurens> ... An authentication suite can provide any kind of constraints on top of this.
15:14:37 <laurens> ... Note that there is both the identification of the agent as well as the identification of the suite.
15:15:52 <laurens> ... If you were to send a token (e.g. a JWT derived using a WebID based authn method), then the AS, which indicated support for the suite, can validate the identification of the agent being e.g. HTTPS.
15:15:55 <laurens> scribe-
15:16:00 <laurens> ack uvdsl
15:16:00 <Zakim> uvdsl, you wanted to say that the proposal in the Issue says: Not limiting generality, HTTP(S)/REST is the baseline implementation requirement.
15:16:21 <acoburn> uvdsl: I did not comment on the PR for the AuthN proposal
15:16:22 <Beau> Beau has joined #lws
15:16:43 <acoburn> ... the general approach is fine, and I agree for the general perspective to have a discovery part
15:17:05 <acoburn> ... not arguing against that in particular. Worried about incompatible, non-interoperable systems
15:17:37 <acoburn> ... worried about the interoperability of the spec, would like to have a minimum baseline, such as HTTP CIDs
15:17:38 <gibsonf1> +1  on minimum baseline http cids
15:17:50 <pchampin> +1 uvdsl
15:18:16 <gb> https://github.com/w3c/lws-protocol/issues/57 -> Issue 57 Agent Identification (by uvdsl) [needs-discussion]
15:18:18 <acoburn> laurens: to resolve this, would a minimum HTTPS authN suite resolve this?
15:18:24 <uvdsl> +q
15:18:29 <laurens> ack uvdsl
15:19:03 <acoburn> uvdsl: two parts: one is to have an HTTP-based CID authentication suite as a minimum baseline
15:19:15 <acoburn> q+ to talk about federations/non-open ecosystems
15:19:29 <laurens> ack acoburn
15:19:29 <Zakim> acoburn, you wanted to talk about federations/non-open ecosystems
15:19:33 <laurens> scribe+
15:19:50 <laurens> acoburn: I wanted to mention that in an open ecosystem this is fine.
15:20:03 <laurens> ... There will be many ecosystems that don't exist in an open ecosystem.
15:20:27 <laurens> ... Those implementations may choose not to support an HTTPS baseline.
15:20:41 <uvdsl> q+ to ask why the spec should be catering towards silos?
15:20:44 <laurens> scribe-
15:20:45 <gibsonf1> q+
15:20:50 <laurens> ack uvdsl
15:20:50 <Zakim> uvdsl, you wanted to ask why the spec should be catering towards silos?
15:21:14 <acoburn> uvdsl: why do we consider closed ecosystems that create silos as a first class audience?
15:21:27 <laurens> scribe+
15:21:36 <laurens> acoburn: One of the things we want is broad adoption.
15:21:44 <laurens> ... This includes various types of architectures.
15:21:57 <laurens> ... One of these architectures is an open ecosystem & distributed model.
15:22:14 <uvdsl> q+ to confim whether the chairs deem adoption more important than interoperability?
15:22:20 <laurens> ... Another widely supported architecture is a federation.
15:22:32 <laurens> ... Federation requires a different kind of model.
15:22:41 <laurens> ... We don't want to choose one over another.
15:22:48 <laurens> q?
15:23:00 <laurens> ... We're not trying to say everything must follow a single model.
15:23:14 <laurens> scribe-
15:23:18 <laurens> ack gibsonf
15:23:48 <acoburn> gibsonf: on open vs closed, if you're closed, you can do whatever you want
15:23:58 <acoburn> q+ to talk about regulated industries
15:23:59 <pchampin> q+
15:24:22 <uvdsl> +1 to gibsonf1
15:24:27 <laurens> ack uvdsl
15:24:27 <Zakim> uvdsl, you wanted to confim whether the chairs deem adoption more important than interoperability?
15:24:28 <acoburn> ... if it's not open, I wouldn't call that LWS
15:24:54 <acoburn> uvdsl: I want to confirm that adoption is more important than interop?
15:25:00 <acoburn> laurens: I think both are important
15:25:20 <acoburn> ... federated ecosystems require just as much interop as open ecosystems
15:25:47 <laurens> ack acoburn
15:25:47 <Zakim> acoburn, you wanted to talk about regulated industries
15:25:49 <acoburn> ... federated ecosystems should not be precluded from our work here
15:25:53 <laurens> scribe+
15:26:33 <laurens> acoburn: I want to bring up areas Inrupt has experience in for highly regulated industries which require very strict controls over who can and cannot login and what the trust chain is.
15:26:51 <laurens> ... Limiting access is vital here.
15:27:00 <gibsonf1> q+
15:27:10 <laurens> ... Requiring all LWS implementations support an open ecosystem is not going to happen
15:27:13 <laurens> scribe-
15:27:18 <laurens> ack pchampin
15:27:25 <acoburn> pchampin: we should not frame the discussion as open vs. closed
15:27:31 <uvdsl> q+ to contradict the notion that a technical requirement such as supporting http-based authentication has implications on the governance-level on restricting trusted issuers
15:27:33 <acoburn> ... federated systems are somewhere in between
15:27:53 <acoburn> ... as for adoption is more important than interop -- this is not black and white
15:28:12 <acoburn> ... having non-open systems use open technologies is beneficial
15:28:36 <laurens> q?
15:28:38 <acoburn> ... I supported uvdsl's original point, but am convinced by laurens' and acoburn's points
15:29:06 <acoburn> ... I would be in favor of defining a compliance level or profile where certain baseline requirements are present
15:29:24 <acoburn> q+ to talk about the existing authn discovery mechanism
15:29:46 <laurens> ack gibsonf
15:29:49 <acoburn> laurens: describing a conformance class seems like a good idea, as long as it's not a requriement for the baseline spec
15:30:00 <acoburn> gibsonf: by federated, is this on the internet?
15:30:09 <acoburn> laurens: yes, on the internet/web
15:30:23 <acoburn> gibsonf: this can be constrained any way you like, though
15:31:51 <acoburn> ... if you use a different authentication method but no one uses it, it would pass the test
15:32:24 <acoburn> laurens: we have tried allow/deny lists, it is detrimental to interop
15:32:33 <acoburn> ... introduces greater complexity
15:32:56 <acoburn> ... not opposed to a baseline profile
15:33:02 <laurens> q?
15:33:05 <laurens> ack uvdsl
15:33:05 <Zakim> uvdsl, you wanted to contradict the notion that a technical requirement such as supporting http-based authentication has implications on the governance-level on restricting trusted
15:33:08 <Zakim> ... issuers
15:33:31 <acoburn> uvdsl: I don't think gibsonf is suggesting that everything can be solved by http
15:33:48 <acoburn> ... there is a difference between technical interop and governance
15:34:38 <acoburn> laurens: schemes that restrict trusted issuers do work
15:35:00 <acoburn> uvdsl: we have a federation for research institutions
15:35:07 <acoburn> ... in Germany
15:35:16 <laurens> q?
15:35:20 <laurens> ack acoburn
15:35:20 <Zakim> acoburn, you wanted to talk about the existing authn discovery mechanism
15:35:21 <laurens> scribe+
15:35:31 <laurens> acoburn: A couple of things were mentioned here
15:35:57 <laurens> ... gibsonf brought up that the authorization server should claim to support a authn scheme which it does not fully support.
15:36:12 <uvdsl> That is not what gibsonf1 said. He said that it does support it, but the governance prevents any agent to authenticate it.
15:36:32 <laurens> ... We have a resource server that stores the LWS resources which points to the authz server which has references to supported mechanisms in its discovery.
15:36:54 <laurens> ... We want to determine which mechanisms must be present in the discovery of the authorization server.
15:37:12 <laurens> ... If you claim to support something you should actually do that properly.
15:37:26 <laurens> ... Different organizations have different needs.
15:38:14 <laurens> ... Let's imagine you have an authentication suite "Open Ecosystem WebID", in that case the authz server advertises support.
15:38:21 <uvdsl> q+ to clarify that I propose a baseline that MUST be supported. I did not propose a mechansim to advertise what is supported.
15:38:22 <laurens> ... All of the components are already there.
15:38:45 <laurens> scribe-
15:38:48 <laurens> ack uvdsl
15:38:48 <Zakim> uvdsl, you wanted to clarify that I propose a baseline that MUST be supported. I did not propose a mechansim to advertise what is supported.
15:39:20 <acoburn> uvdsl: would like to clarify that my proposal is not a mechanism to discover the authentication scheme a server supports
15:39:43 <acoburn> ... I would like a baseline for what servers must support
15:40:06 <acoburn> ... the argument that certain federations don't want to use that baseline isn't a sufficient argument, IMO
15:40:50 <acoburn> laurens: there are two ways we can approach this: 1. work with a conformance profile
15:41:08 <acoburn> ... 2. requiring a MUST have for all servers based on HTTP is something I would oppose
15:41:22 <acoburn> ... would be in favor of introducing as a profile
15:41:40 <Luke> q+
15:41:47 <laurens> ack Luke
15:41:52 <acoburn> acoburn: inrupt would also oppose a required baseline
15:41:59 <gibsonf1> q+
15:42:05 <acoburn> Luke: IBM/Redhat would also oppose a required baseline
15:42:05 <laurens> ack gibsonf
15:42:37 <acoburn> gibsonf: the dangerous part is that, if nothing is required, then it's just wild-west, that would not encourage adoption
15:42:52 <acoburn> ... it makes a mess of things
15:44:07 <acoburn> laurens: what is the difference between that approach and introducing a profile?
15:44:11 <pchampin> q+
15:44:20 <acoburn> gibsonf: if it's optional, then it will only work in some places
15:44:31 <uvdsl> q+ to support the creation of the HTTP-based CID (e.g. via then OIDC). I believe that we should provide at least one tangible example that can directly be implemented.
15:44:32 <acoburn> q+ to talk (again) about regulated industries
15:44:43 <laurens> ach pchampin
15:44:54 <laurens> ack pchampin
15:45:04 <acoburn> pchampin: to +1 what laurens suggested, we must be clear about the scope of a profile
15:45:23 <acoburn> ... if we define profiles, then we need to define the scope of the profile
15:45:46 <laurens> ack uvdsl
15:45:46 <Zakim> uvdsl, you wanted to support the creation of the HTTP-based CID (e.g. via then OIDC). I believe that we should provide at least one tangible example that can directly be
15:45:49 <Zakim> ... implemented.
15:45:51 <acoburn> ... that should be a strong signal for what profile should be used on the open web
15:46:15 <acoburn> uvdsl: we would still prefer an HTTP baseline mandated, we acknowledge that others oppose this
15:46:45 <acoburn> ... In that case, I would create a tangible example that can be implemented, I do not want a hollow spec
15:47:09 <acoburn> ... I would like a guideline for one authentication spec
15:47:21 <pchampin> uvdsl "implementability" is a requirement to move to Recommendation, per the W3C process :) no "hollow spec" allowed
15:47:29 <acoburn> laurens: we seem to be converging on a profile
15:47:32 <laurens> ack acoburn
15:47:32 <Zakim> acoburn, you wanted to talk (again) about regulated industries
15:47:37 <laurens> scribe+
15:47:47 <uvdsl> pchampin, yes! thank you :)
15:48:02 <laurens> acoburn: For regulated industries you cannot assume any authentication scheme is going to be accepted.
15:48:22 <laurens> ... Choosing your own health application or banking app is going to be different from a chat application.
15:48:37 <uvdsl> I
15:48:48 <laurens> scribe-
15:49:37 <acoburn> laurens: for resolution of issue #57, we can draft an authentication suite that is HTTP based. Do we have any volunteers?
15:49:37 <gb> https://github.com/w3c/lws-protocol/issues/57 -> Issue 57 Agent Identification (by uvdsl) [needs-discussion]
15:49:45 <uvdsl> q+
15:49:50 <laurens> ack uvdsl
15:49:57 <acoburn> uvdsl: I would be willing to co-edit this
15:50:09 <gb> https://github.com/w3c/lws-protocol/issues/57 -> Issue 57 Agent Identification (by uvdsl) [needs-discussion]
15:50:26 <acoburn> laurens: if you can do a first draft and then bring it back to the WG
15:50:51 <acoburn> uvdsl: do you have an indication of timeline? FPWD/CR/etc
15:51:05 <acoburn> laurens: one of the agenda points is about FPWD
15:51:17 <acoburn> ... ideally this would be end of March
15:51:28 <acoburn> ... would that timing work for you, uvdsl?
15:51:45 <acoburn> uvdsl: that timeframe may work, we will see
15:52:19 <acoburn> laurens: issue #61 is about the LWS media type
15:52:19 <gb> https://github.com/w3c/lws-protocol/issues/61 -> Issue 61 LWS Container Media Type (by acoburn) [needs-discussion]
15:52:47 <acoburn> ... we want to determine the media type used for containers and storage description metadata documents
15:53:10 <acoburn> ... we got some feedback from the JSON-LD community that application/lws+json media type makes the most sense
15:53:32 <acoburn> ... would like to hear if there is any opposition to using that media type
15:53:43 <laurens> q?
15:53:48 <acoburn> +1 supportive of that media type
15:53:55 <uvdsl> q+
15:53:56 <bendm> q+ also fallback?
15:54:01 <laurens> ack uvdsl
15:54:15 <acoburn> uvdsl: is this defining a new media type?
15:54:21 <bendm> q+ to ask also about the fallback
15:54:29 <acoburn> laurens: this would not define a new media type with IANA
15:54:48 <acoburn> uvdsl: how would this work if a client asks for JSON?
15:55:12 <acoburn> laurens: there is some wording from the Activity Streams spec to also return JSON
15:55:20 <laurens> ack fallback?
15:55:22 <laurens> ack bendm
15:55:22 <Zakim> bendm, you wanted to ask also about the fallback
15:55:39 <acoburn> bendm: would this also work if a client asks for application/ld+json
15:55:45 <uvdsl> +1 to Ben's concern :)
15:55:48 <acoburn> q+ to talk about fallbacks
15:55:58 <laurens> ack acoburn
15:55:58 <Zakim> acoburn, you wanted to talk about fallbacks
15:56:02 <laurens> scribe+
15:56:48 <laurens> acoburn: I would like to see the default be application/lws+json but in the IANA considerations section we could mention it conforms to application/json and application/ld+json that would resolve this.
15:56:56 <bendm> q+ to ask so there is an IANA description needed?
15:57:01 <laurens> ... There is wording from ActivityStreams which allows us to do exactly that.
15:57:04 <laurens> ack bendm
15:57:04 <Zakim> bendm, you wanted to ask so there is an IANA description needed?
15:57:33 <laurens> bendm: there is an IANA description needed?
15:57:40 <pchampin> q+
15:57:48 <laurens> acoburn: The ActivityStreams community put this in a considerations section afaik.
15:57:54 <laurens> ack pchampin
15:58:02 <laurens> scribe-
15:58:29 <acoburn> pchampin: I think this is wrong -- the IANA considerations section is for formal registrations with IANA
15:58:55 <acoburn> ... I do see an application/activity+json application is present
15:59:13 <pchampin> https://www.iana.org/assignments/media-types/application/activity+json
15:59:26 <acoburn> ... the work of the group is to write the IANA considerations section, the W3C staff contact will help with the registration part
15:59:40 <acoburn> RRSAgent, make minutes
15:59:41 <RRSAgent> I have made the request to generate https://www.w3.org/2026/02/16-lws-minutes.html acoburn
15:59:48 <uvdsl> Good discussion today, thank you all!
15:59:59 <acoburn> laurens: thank you for the discussions today
16:00:07 <acoburn> RRSAgent, make minutes
16:00:08 <RRSAgent> I have made the request to generate https://www.w3.org/2026/02/16-lws-minutes.html acoburn
16:00:30 <bendm> bendm has left #lws
16:00:54 <acoburn> present+ bendm
16:01:16 <pchampin> i|is about the LWS media type|Topic: LWS Media-type
16:01:18 <acoburn> RRSAgent, make minutes
16:01:19 <RRSAgent> I have made the request to generate https://www.w3.org/2026/02/16-lws-minutes.html acoburn
16:01:50 <m2gbot> m2gbot has joined #lws
16:04:52 <acoburn> acoburn has left #lws