Tpac2023 charter comments

[plehegar]

This implements the items from our TPAC 2023 discussion.

This adds items on the REC-track, allows the WG to adopt items from incubation without rechartering, switch the group to living CR, update the liaisons.

Items that did not generate a change in the charter:

1. WebCrypto curves, algorithms, and streaming. As long as it's part of maintaining the existing REC, we don't need to say more.
2. Securer Contexts. Not sure what to add to the charter, if anything
3. Permission API additions? As long as it's part of working on the current document, we don't need to say more.
4. Cookie Layering. I didn't find anything to link to
5. Fetch metadata still to be incorporated directly into Fetch. Waiting to see if there is a conclusion there so left the charter as-is.

[mikewest]

LGTM. Thanks for pulling this together!

1. You added a link to the secure curves doc, which seems good enough to me as a demonstration of the claimed scope.

2. For securer context, you could link to https://github.com/mikewest/securer-contexts. I'll try to get that moved to WICG.

3. I agree that there's nothing to say here.

4. Cookie layering httpwg/http-extensions#2084, perhaps?

5. I think leaving the charter as-is on this point is fine. I'll work it out with Anne separately, but I don't think it has an effect on our claimed scope either way.

[johannhof]

This looks great, any reason we need to include cookie layering here? Besides the WG note which will be important to the effort, I think we'll mostly handle execution in WHATWG.

[mikewest]

Hey @johannhof! I didn't realize that was the plan, but if it's going to be a WHATWG product, then we can certainly leave it out.

[johannhof]

I think so, but @annevk may have additional thoughts.

[mikewest]

🤷 I'm happy for it to go elsewhere, it just wasn't clear to me that it already had a home. :)

[johannhof]

Thanks for offering to host this work 💜

[annevk]

It seems these deliverables have some kind of conflict with the WHATWG HTML Workstream:

• Page Embedded Permission Control (PEPC)
• Sandbox allow-unique-origin

It would help to have some clarity here.

[mikewest]

Good point. The framing on those should be "These are incubations we should pay attention to and discuss, as they fall within the scope of security work the group is responsible for.", not "We're going to take these to REC." I imagine both would end up in HTML if they incubate successfully.

[plehegar]

btw, regarding Request-OTR, it wasn't clear to me that it should be a deliverable of webappsec or we should leave it to the IETF to handle.

cc @mnot

[plehegar]

I chose to move PECP and Unique Origin into the liaison section with WHATWG. An alternative would be to keep it as a potential work item but also commit to move it to the WHATWG HTML stream once mature (like we're doing for the Fetch metatada).

Waiting on @annevk to weigh in on cookie layering before adding it to the charter.

[mnot]

HTTP WG discussed Request-OTR at IETF117; general feeling was that WebAppSec (or perhaps Privacy CG, depending on how mature it is / how much implementer interest there is) was more appropriate. Feel free to loop us in for the HTTP aspects (e.g., header design).

[mikewest]

@plehegar, is there anything else to do here, or shall I merge this PR?

[annevk]

In case you were blocked on me. Cookie layering is essentially these things:

• 6265ter (to be produced for the IETF HTTP WG)
• Changes to Fetch
• Changes to HTML
• Changes to Cookie Store

While I'm sure these changes will be discussed in a variety of venues, I don't think they need to be in scope of additional groups.

[plehegar]

Horizontal review of charter requested. follow at w3c/strategy#426

[hober]

:(