Agenda: 2026-03-10

[simoneonofri]

placeholder for the agenda, feel free to add topics here

[elf-pavlik]

Just an idea, relatively recently AuthN FPWDs were published for https://w3c.github.io/lws-protocol/
I also have an early draft that explores aligning Solid-OIDC with LWS authn-openid
https://elf-pavlik.github.io/lws-auth/view/oidc/?dynamic=sequence
OIDC Provider would be the User AS on the diagram, there's also Resource AS which is another OAuth2 AS but on the Resource Owner side - in general case End-user != Resource Owner, they are the same in a special case.

For Solid-OIDC there is this test suite https://solid-contrib.github.io/solid-oidc-tests/
It only tests the Solid-OIDC Provider so there are no tests for clients. Solid CG is also exploring using Solid-OIDC with https://www.w3.org/TR/fedcm/ which has three roles RP (client), User Agent, IdP (provider) it links to https://github.com/web-platform-tests/wpt/tree/master/fedcm which I assume only tests the User Agent.
I would be very interested in suggestions for how test suites for clients/RPs and providers should work.
There's also more robust Test harness that produces EARL reports

• https://github.com/solid-contrib/conformance-test-harness
• https://github.com/solid-contrib/specification-tests

It also uses spec statements, for example like ones auto generated in https://speculator.openuji.dev/features/spec-statements/

I only give those examples as some concrete examples of running code. Discussion could focus on testing other parties than the User Agent and be more general without referencing any tools or more specific and using some tools as examples.

I'm not a member of LWS WG but I'm a co-editor of Solid-OIDC and have been invited to few LWS WG meetings to discuss recent AuthN publications.

[pchampin]

@acoburn @laurensdeb do you think a joint session between the Threat Modeling CG and the LWS WG would be beneficial?

[simoneonofri]

@elf-pavlik Thank you, I sent you an email for a little clarification :)

[simoneonofri]

thank you @elf-pavlik for the clarification.

Agenda follows

Agenda

• Administrivia

  • Scribe volunteer(s) or Zoom AI?
  • Reminders:
    • Community Group Membership
    • W3C Code of Conduct

• Participants Introduction (2 minutes roundtable)

• Next meetings

  • 24 March 2026
  • 7 April 2026

• Annoucements

  • Threat Modeling for Web Developrs

• Threat Modeling Intro

  • Threat Modeling Process

• Threat Modeling Session

  • What are we building? @elf-pavlik Document Diagram
  • What can go wrong?
  • What we can do about it?

[elf-pavlik]

Thanks @simoneonofri

Here are two most relevant Security Considerations sections and the first one is followed by Privacy Considerations

• https://w3c.github.io/lws-protocol/lws10-core/#security-considerations
• https://w3c.github.io/lws-protocol/lws10-authn-openid/#security-considerations

I would also like to clarify that in my opinion LWS leaves quite a lot underspecified to allow it to be adopted in diverse contexts. My diagram focuses on open ecosystem and fills in some of what I would consider gaps in LWS for that context. I'm happy to point out tomorrow what is currently specified in LWS and which parts I add as aditional requiremens which are one of possible ways to ensure open ecosystem interop. In other words my what I have in the diagram already addresses some of the security considerations, but I don't do it in implementation specific way but more as a profile or spec that could be created using LWS as foundation.

[elf-pavlik]

As you can see this work is very much in progress, there is another relevant PR that was crated just 2h ago

• Propose Web-CID Profile for Agent Identification w3c/lws-protocol#96

[simoneonofri]

@elf-pavlik with Threat Modeling we can also work at the feature level. The diagram you bring guides the level of analysis.

To set the expectation, that after you present how the thing works (starting from scratch, we're not necessarily experts in LWS or OIDC, other), for each component or flow we brainstorm whether there are securuty threats (e.g., with STRIDE or RFC 3552), or privacy threats (e.g., with LINDDUN or RFC 6973) or other technques. :)

In the specific case, since RFC 9700 is already quite comprehensive, it depends on the one hand when we deviate, and on the other hand specifically if there are specific considerations "imported" in your work