Approaches for the CSS WG

Intro

We want the CSS WG (and other new WGs too) to start publishing automatically with Echidna. The workflows for their specs are different to the most of the rest of specs Echidna is handling already:

• They use Bikeshed (instead of ReSpec; where Echidna has had more experience recently).
• They publish EDs on their own site (instead of having WDs on gh-pages as most other groups).

Options

1. CSS WG to put WDs + Echidna manifests on their public site

Changes required:
No changes on the part of Echidna.
CSS WG: start uploading more/other files to drafts.csswg.org as part of their CI cycle.

Pros:
Consistent with the usage of the rest of groups.
No TAR'ing, no signing.

Cons:
Changes required in CSS WG's CI.
Same level of security we have right now for other WGs: known location + token.

2. CSS WG to send signed TAR to Echidna

Changes required:
Echidna: learn how to verify signed files; store and manage public key(s) associated to tokens.
CSS WG: package their WD as a TAR file; sign it; manage private keys in a safe way (but as part of their CI system).

Pros:
More secure. No need to publish anything publicly.

Cons:
New dependencies on both ends on tools to sign and handle public/private keys. Support for SSH signing in Node.js? More complexity (handling keys).

3. CSS WG to send TAR to Echidna, authenticating with a W3C account

Changes required:
None or minimal in Echidna per se (auth would be managed before HTTP requests get to Echidna?).

Pros:
Reuses existing authentication mechanism on w3.org, and existing W3C accounts (no need to generate/store keys).

Cons:
Basic HTTP auth feels wrong.