Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move OTR to Privacy Working Group #645

Closed
plehegar opened this issue Mar 4, 2024 · 9 comments · Fixed by #647
Closed

Move OTR to Privacy Working Group #645

plehegar opened this issue Mar 4, 2024 · 9 comments · Fixed by #647
Assignees
Labels

Comments

@plehegar
Copy link
Member

plehegar commented Mar 4, 2024

From AC Review:
[[
The new "Off-The-Record Response Header Field" (OTR) deliverable focuses
on addressing Privacy use-cases and as such it should instead be added as
an OPTIONAL deliverable for the Privacy Working Group charter to take up
if/when it has shown sufficient incubation. We believe it is an error (in
scope, choice of most appropriate Working Group to to do the work) to add
OTR to the list of deliverables for the Web Application Security Working
Group charter. We could live with OTR being taken up for consideration by
the Privacy CG.

We recommend the following actions, which do not require synchronization:

  • The Team should amend the proposed Web Application Security Working Group
    Charter to drop OTR
  • The Team should add OTR as an optional deliverable to the in-progress
    Privacy Working Charter, and then re-poll the AC with that updated Charter,
    which also resolves 2 of the 3 Formal Objections on the prior polled
    Privacy WG Charter. This also provides an opportunity to see if the
    remaining 3rd (anonymous) Formal Objection on the prior polled Privacy WG
    Charter is restated or not for the updated proposed Privacy WG Charter. We
    believe this path has a better chance of creating a Privacy Working Group
    charter more quickly than further delays in processing an anonymous Formal
    Objection on an outdated WG charter proposal.

We are objecting (suggesting changes) but are not making this a Formal
Objection because we believe this to be a W3C Team clerical error (putting
a new deliverable in the wrong Working Group) that the Team is empowered to
fix without having to exercise the full Formal Objection process and
mechanisms.
]]

cc w3c/strategy#426

@plehegar
Copy link
Member Author

plehegar commented Mar 4, 2024

cc @ShivanKaul

@mikewest
Copy link
Member

mikewest commented Mar 4, 2024

The PrivacyWG didn't exist at the time we proposed the charter, and (so far as I know?) continues not to exist. :)

If the PrivacyWG is going to exist in the somewhat-near future, I agree that it's reasonable to shift OTR to that scope.

@plehegar
Copy link
Member Author

plehegar commented Mar 4, 2024

That question was asked back in Sep and I asked PING about it. The conclusion was that it was fine to leave in the WebAppSec charter. That's why it did not come up during the PING review of the webappsec charter. So, not a clerical error...

@plehegar
Copy link
Member Author

( @ShivanKaul is fine with having it in the Privacy WG charter. )

@plehegar
Copy link
Member Author

and Privacy WG is also fine with taking it on.

@ShivanKaul
Copy link

Sorry was on PTO. Privacy WG sounds fine as a venue, though I'm a little confused by the objection given that Request OTR's goals are similar to Clear Site Data, which is an adopted item.

@mikewest
Copy link
Member

(My feeling is that if a privacy WG had existed in 2015, we would have done clear-site-data there. :) )

@plehegar
Copy link
Member Author

WebAppSec agreed to have this moved to the Privacy WG

@plehegar
Copy link
Member Author

plehegar commented Mar 20, 2024

Btw, the charter change doesn't address which CG should incubate the specification. This is left to the CGs to figure it out. (and a WG charter cannot require a CG to do something anyway)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants