Adopt Fetch Metadata as a deliverable.

[mikewest]

We discussed Fetch Metadata briefly on the 2019-03-20 call, and I think there was some amount of concensus among the folks there that this was an interesting feature, and would be most easily comprehensible as a separate document. I think the functionality fits into our existing charter's scope pretty cleanly, and I think that there's been enough attention to the feature's broad strokes that it's worth pulling out of incubation and into a group like this one.

Is it a reasonable feature we'd like to standardize? If so, is doing that work here reasonable, or should we push it out to WHATWG instead, perhaps even as part of Fetch? I think the answers are "Yes" and "Yes", but I'd appreciate feedback from the wider group.

This, therefore, is a call for consensus to adopt Fetch Metadata as a WebAppSec deliverable and publish it as a FPWD. If you have thoughts, one way or the other, please respond by 2019-04-08 (preferably here in this issue, though email to public-webappsec@w3.org is, of course, welcome).

[annevk]

The separate document setup seems a little weird long term, given that the values and the algorithm that exposes them are explained in and part of the other document. At least from that perspective this doesn't seem like a separable class or module.

[mikewest]

@annevk: I really like having separate documents for separate concepts that I imagine folks will use separately. For example, I think it would be easier to understand why CORP is a thing folks should care about if it had a lot more ancillary text around it, describing the problem space it occupies, why it's designed the way it is, etc.

Still, you're right that this feature is a pretty thin shim on top of the data Fetch defines. If we don't think the normative bits are substantial enough to warrant a callout from Fetch, the normative bits could live in Fetch. If we did that, I'd still be interested in having something like the existing document published as a standalone that references Fetch. It seems to me that there's value in doing so, if we can figure out how to avoid confusion about which is controlling.

/cc @dveditz, @jyasskin, and @arturjanc who had opinions about this question on the WebAppSec call last week.

[jyasskin]

@mikewest The lack of explanatory text in https://fetch.spec.whatwg.org/#cross-origin-resource-policy-header is something that could be fixed inside the Fetch spec. For example, https://fetch.spec.whatwg.org/#fetching has an introductory explanatory note. I don't think we should create extra documents just because Fetch often omits important introductions.

Trying to come up with good reasons to create a separate document: Perhaps it's when folks trying to understand things are likely to traverse the boundary only a few times, and will spend most of their time navigating within the separate document. Or when there are uses from several different specs, so that it makes things easier to read when there's a clear external API in the extracted document, which would be more difficult to provide from Fetch.

In this case, it looks like everyone reading the spec has to jump to Fetch Metadata when Fetch calls https://mikewest.github.io/sec-metadata/#abstract-opdef-set-the-fetch-metadata-headers-for-a-request, and then jump back when places like https://mikewest.github.io/sec-metadata/#abstract-opdef-set-dest refer to https://fetch.spec.whatwg.org/#concept-request-destination.

Maybe worse, https://mikewest.github.io/sec-metadata/#abstract-opdef-set-dest implicitly requires that all destinations are tokens, but that restriction won't be obvious when someone searches for all uses of https://fetch.spec.whatwg.org/#concept-request-destination within the Fetch spec while adding a new value.

[annevk]

I don't think we shouldn't create extra documents just because Fetch often omits important introductions.

Indeed, but also, if something needs more text, is there a reason it's not being contributed?

[mikewest]

Indeed, but also, if something needs more text, is there a reason it's not being contributed?

I think it's likely because you're doing all the work, and you're (rightly!) spending more time on technical correctness and testing than on developer usability. Ideally, folks making proposals would contribute more text. There's a lot in #687 that could address #767, for example. :)

But, status quo to the side, there's happily quite a lot of text for the feature we're discussing at the moment.

How much of that document would you feel comfortable stuffing into Fetch, @annevk? If it all fits, great, I don't have many good arguments left for putting up a separate doc. If we would need to trim, then we can argue about how useful the words are that wouldn't fit well into Fetch, and whether there's another place they could live.

[annevk]

To take a step back, I wasn't trying to say that you have isn't the way to go. It's valuable to explain a new feature in its own document along with all the rationale that went into making it.

I'm just worried that long term we end up with a rather splintered setup and I'm wondering how to avoid that.

[arturjanc]

Just on the narrow point about developer convenience: for security mechanisms there is a fair amount of value in having a separate document that explains the reasons for having the feature, its uses, adoption considerations, etc. For adopters, it's nice if this document also actually defines how the security feature works instead of referring to a small section in another, much broader doc with a non-security emphasis; from that point of view the current Fetch Metadata spec is a fairly accessible read.

Spec-wise, I don't feel very strongly about either approach so if there are compelling reasons to integrate everything into Fetch, it seems fine -- we could compensate for it by creating separate developer-focused docs that refer to the appropriate bits in Fetch.

[fmarier]

Is it a reasonable feature we'd like to standardize? If so, is doing that work here reasonable, or should we push it out to WHATWG instead, perhaps even as part of Fetch?

Speaking on behalf of Brave, this is a feature we'd like to see standardized. Some good points have been made with respect to its integration within Fetch, but we would welcome a publication of some sort (Recommendation or not) in this working group.

[mikewest]

(I'm deferring to you on this, @dveditz. I think we decided on the last call to adopt the document on rec track and see whether there's anything normative left after working with @annevk to move bits to Fetch?)

[dveditz]

Yes, we've talked about this on two calls and there were no objections to adopting it on rec track (with the possibility of diverting to "note" status in the end if no normative bits are left)

[mikewest]

Great! Filed https://github.com/w3c/transitions/issues/139.

@wseltzer: Can I transfer the mikewest/sec-metadata to w3c, and then ask you to rename it to something like w3c/webappsec-fetch-metadata?

[wseltzer]

Done. https://github.com/w3c/webappsec-fetch-metadata Closing!