Create 2024-12-18-minutes.md

meetings/2024/2024-12-18-minutes.md

@@ -0,0 +1,135 @@
+# WebAppSec - 2024-12-18
+
+## Attendees
+
+* Anne van Kesteren
+* Artur Janc
+* Benjamin Ackerman
+* Ciara McMullin
+* Dan Veditz
+* Daniel Huigens
+* Dan Rubery
+* David Dworken
+* Emily Stark 
+* Joe DeBlasio
+* John Wilander
+* Kristian
+* Lawson Jaglom-Kurtz
+* Mike West
+* Yoav Weiss
+* Simon Wijckmans
+* Simone Onofri
+* Tim Cappalli
+* Tom Ritter
+* Tom Schuster
+* Uday Bhaskar Seelamantula
+
+## Agenda
+
+* CSP Triage updates (@ciaramcmullin, et al)
+* Adopting Device Bound Session Credentials [[thread](https://lists.w3.org/Archives/Public/public-webappsec/2024Dec/0004.html)]?
+* [Reporting hashes in CSP](https://github.com/w3c/webappsec-csp/pull/693)
+* [Signature-based Integrity](https://wicg.github.io/signature-based-sri/) updates (@mikewest)
+* Naming of an API: "login status API" and equiv in FedCM. Low vs. high trust.
+* Administrivia:
+    * Recording the meeting.
+
+## CSP Triage
+
+Ciara: Closed a few PRs, going through and labeling a lot of issues. Several are blocked on changes to other repositories. For some PRs, many have merge conflicts but are ready to go otherwise. 
+
+mkwst: For things blocked on other repo, TC39? If they land in TC39, we should land as well. If there's discussion happening, we should wait for stage 3+
+.. For merge conflicts, if you can resolve them and they are editable, feel free to make the change.
+... otherwise, you can reach out and suggest collaborating on merging it or changing the PR
+
+dveditz: Aiming to get CSP3 done, so would be ideal to reduce changes to the spec. Like the next topic. Not sure if there's a plan yet on how we're going to deal with that. Forking a CSP3? 
+
+Ciara: Ping me on Slack! Happy to add you to biweekly triage call.
+
+dveditz: Sorting through editorial working corrections vs things that change meaning. Of the latter, identifying feature proposals for CSP3 vs Next. Ambiguity/clarifications: separating browser issues from spec issues. Using different tags/labels for each. In the future, we'd like to do something similar to other groups, and tag proposals at various stages, gating those landing in the spec similarly to WHATWG. Ideal to align with the process in that group.
+
+annevk: I wonder what the point of "CSP3" is. I don't mind that, but forking the current draft should be their burden. It seems difficult enough for the group to maintain one document. I worry about freezing development until the other thing happened.
+
+dveditz: I don't know what we're required to do per charter/expectations. Not sure we can blow it off.
+
+mkwst: Maybe just publish current doc as CSP3 CR, and shift right now.
+
+yoav: We did this in webperf. Anne is correct. It's not useful to create a CSP3, and not worth holding development for it. That's our experience in webperf. Orthogonal to the issues that need to be fixed. Publishing whatever we have as a CR, and iterate from there. SGTM.
+
+mkwst: my feeling is "levels" was a mistake and we should just move to a living spec. We do need to get through our backlog of issues to have a well-maintained spec, but not necessarily with a "level" as the goal. We need to maintain what we have, not just add new stuff to it as people need and want them. There's a balance between adding features and fixing bugs, but publishing CSP3 is not necessarily inherently valuable. We should create policies, e.g. staging system. We should do that.
+... Next step, Dan and I to sit, write a doc based on WHATWG policies, send it to the group and then publish it once people agree.
+
+## Adopting Device Bound Session Credentials [[thread](https://lists.w3.org/Archives/Public/public-webappsec/2024Dec/0004.html)]?
+
+mkwst: Looked into adopting it to the WG. Simone looked if this is compatible with our charter
+
+simone: Discussions with WebAuthn WG. They're not opposed to have the spec adopted here, but had concerns about fragmentation about APIs having to do with credentials (also digital credentials API). Should meet with them to talk about incubation/collaboration. Maybe also Web Payments. Also: I read the explainer, some privacy considerations. Should go through horizontal review. Also discussion around the group's scope; review + alignment call with other groups would help.
+
+https://lists.w3.org/Archives/Public/public-webappsec/2024Dec/0006.html
+
+mkwst: [Said some things] Send a CfC, with deadline in January.
+
+simone: Want to head off privacy problems before doing that. 
+mkwst: options were either the IETF which is responsible for cookies, or if it's an application layer feature this is the right WG
+anne: Fetch doesn't handle cookie layering well now
+mkwst: but you will. Cookie layering work may be a better place in the future
+anne: we can get there down the line
+mkwst: want to understand next steps to bring this doc to this group. Let's talk offline
+
+tim: This work is fundamentally different from other credential work at W3C. There's no crossover between WebAuthN, Digital Credentials, etc. IMO.
+
+Kristian: We've started the alignment process with payments, etc. at TPAC. Folks are aware, others are part of this effort. Right now, the main issue is the charter. If that needs to happen. That's our goal with kicking this off early.
+
+mkwst: [Said things]
+
+yoav: Looking at the charter, it seems like exfiltration is covered.
+mkwst: we'll cover that with Legal folks offline
+
+simone: My interpretation is also that it's covered. Would like to avoid formal objections during adoption, however.
+
+[Anne in zoom chat: An enormous meeting will also not magically create alignment. Motivated individuals can file issues and we can take it from there]
+
+## Naming of an API: "login status API" and equiv in FedCM. Low vs. high trust.
+
+johnwilander: https://github.com/w3c-fedid/login-status/issues/8#issuecomment-2542043964. At TPAC we decided that FedCM would pursue their version of a login status API, while the PrivacyCG continues on its own. One doesn't carry trust (FedCM), the other has a goal to be high-trust (UA is convinced the user is logged in, up to/including confirmation from the user). Question is which side gets the 'default' name, want to get that right.
+
+annevk: Hard to see what the proposed names actually are. Names for the APIs? Specifications?
+
+john: Proposal was that the PrivacyCG document would be "high-trust login signal", while FedCM would keep "login status API". Wouldn't know it was low-trust unless you knew about its sibling.
+
+annevk: I agree with you, but same company...
+
+mkwst: We've used "unsafe", not sure if it matches here.
+
+## [Signature-based Integrity](https://wicg.github.io/signature-based-sri/)
+
+mkwst: proposal to extend SRI to incluide a signature based mechanism, vs content based.
+... give you a notion of provenance and allows you to understand it's a response intended by the server
+... the content hash is also signed by the server. enabled deployment of things that are dynamic by nature, produced by an entity you trust
+... helps to ensure that the only piece you're trusting is the entity that produced it
+... Relies on an [RFC 9421 HTTP Message Signatures](https://datatracker.ietf.org/doc/rfc9421/), providing a generic way to sign HTTP messages
+... relies on another HTTPWG document - identity digests, a header that contains a hash of the contents after content-encoding
+... idea is that the server would attach an identity digest header to the response, and two extra headers: `signature-input` (defined what the signature actually signs) and a `signature`
+The browser can enforce each of these separately
+that the identity digest matches the content, that the signature input actually matches the things that are signed
+then we can layer SRI on top with an integrity attribute that enforces that certain keys are actually used for signing the resource
+If it all passes, you're good to go
+Please take a look at the document and its examples. E2E example in section 7, including how one would generate the headers
+Discussions in GH on the details. Intersection with CORS, what profiles should include, what should developers sign
+May be useful for developers to sign the path of the request, etc
+Lots of details. Please take a look and provide opinions
+Google is very interested, and a prototype started in Chrome, behind a flag
+Folks are playing around with what a signing pipeline may look like
+Shopify and Cloudflare have expressed interest, but want more feedback from others
+
+dveditz: In Firefox we use message signatures that don't match this spec (older than this spec). Some large percentage of our users have MitM, signatures are useful. For SRI, seems useful as well.
+
+annke: Recording.
+
+mkwst: question about recording. Before we start recording these meeeting, we should talk about it. Folks that want this should open an issue on GH on that front. Until we have consensus, we shouldn't do it.
+anne: Apple's policy is always to object to recording
+
+dveditz: TC39 groups use something similar to Otter to generate transcripts. Not a recording. Pause the transcription for OTR discussions. Essentially like taking minutes, but with less effort (and differently inaccurate results).
+
+mkwst: recording the meeting is not something folks have agreed to, so we shouldn't.
+