Clarify what schemes should be allowed for URL fields in the signature

[kinu]

Current Signed Exchange spec draft says cert-url and validity-url should be an absolute-URL string, but that could potentially allow multiple schemes than http/https (e.g. file and ws), while it doesn't seem to include data: URL. It looks we'd better clarify what schemes should be allowed there.

[jyasskin]

I think data: is allowed as an absolute-URL string by following the "not an ASCII case-insensitive match for a special scheme" branch, followed by the "path-relative-scheme-less-URL string" branch. That said, the real parsing for this should use the URL parser with no base URL and then exclude fragments and filter for the schemes we want.

I feel like the right set of schemes is https://fetch.spec.whatwg.org/#fetch-scheme, maybe subset by https://w3c.github.io/webappsec-secure-contexts/#is-url-trustworthy, and maybe removing file: for the small risk of finding a way to read local files from the signed exchange.

[kinu]

https://github.com/whatwg/url/issues/68 made me think it's not covered there but rather in fetch spec, but yeah the URL spec covers broader concepts so it might actually cover it.

Reg: https://fetch.spec.whatwg.org/#fetch-scheme I doubt we want to include about, blob and filesystem schemes either, unless we're considering dynamic package generation done by a JS code. Loading data from these URL would basically need upper layer context than HTTP layer (e.g. we need a concept of Web origin there), and implementing it will become harder.

[jyasskin]

I think blob: and filesystem: make sense for the newsreader app Jake demoed at I/O, where one SW stores signed exchanges for a bunch of other websites. That said, maybe we should assume bundles there, where the certificate can be stored inline.