Related origin validation should reference the Fetch spec

[kreichgauer]

The related origins validation procedure says to fetch the webauthn well-known URL. But the actual definition of "fetch" seems under-specified. It says not send credentials or a referrer, but leaves open some important details, like how CSP should be handled. This can lead to partial CSP bypasses, where the User Agent makes a cross-origin request to a .well-known/webauthn resource, even if the page has a CSP directive that prohibits cross-origin fetches.

It appears to be best practice to reference the Fetch spec in cases like this, specifically the section on setting up a request and invoking the fetch API with it.

There are a couple of examples in other specs that we could probably follow, e.g. SPC or Payment Method Manifests

[jschanck]

Is it possible to implement the .well-known fetch using the Fetch API? The spec says:

When following redirects, WebAuthn Clients MUST explicitly require all redirects to also use the https: scheme.

I don't think the Fetch API exposes enough information about intermediate hops in a redirect chain to enforce this.

Maybe what we want is for the response URL to be same-origin with the request URL? We could enforce that with the Fetch API, but only if we remove the "all redirects use https:" requirement. The Fetch API would not give you enough information to exclude an http: scheme on the B hop of an A -> B -> A chain.

[kreichgauer]

Could we follow redirects automatically and inspect the request's final URL list after the fetch completes?

[jschanck]

As far as I'm aware, there isn't a final URL list. There's just a final URL.

[kreichgauer]

There is this list, and this makes it sound like that list it should contain every redirect URL that was followed as part of the fetch. But I may well be misunderstanding something.

Edit: Oh, just for clarity, I'm not referring to the fetch() JS API method, but the fetch algorithm. Both come from the Fetch standard.

[jschanck]

OK, I thought you were talking about the fetch API.

A good way to deal with "fetch" being under-specified in the WebAuthn spec would be to amend the requirements so that the .well-known fetch could be implemented using the Fetch API.

[kreichgauer]

I was hoping that referencing the fetch algorithm would suffice. I was able to find a a number of examples for other specs that make similar references (SPC referencing the Image Loading spec as linked above, or fetching a style resource in CSS e.g.).

What advantages would referencing the Fetch() JS API have beyond that? From reading the spec text, it sounds like that's really just wrapping the fetch algorithm in a JavaScript promise with some additional handling for an abort signal.

[jschanck]

The point of referencing fetch would be to provide implementation guidance: "use your platform's fetch implementation or an equivalent sequence of steps". The request URL List that you referenced is an internal bookkeeping detail; the platform's fetch implementation is not going to expose the URL List to callers. In my opinion, that spoils the benefit of referencing fetch.

I still think it would be good if we could reference fetch here. I don't see a clear reason to allow redirects, much less cross-origin redirects, for the .well-known fetch. Dropping the "all redirects use https:" condition and either forbidding redirects or imposing a same-origin requirement would make it possible to implement the related origin validation procedure using the fetch algorithm as a black box.

[kreichgauer]

It was pointed out to me that fetch already blocks mixed content. So I think that if merely say to make a fetch to the https:// well-known URL, with redirects allowed but saying nothing else about restricting them to https:// origins, we actually get the behavior we have currently.

I'm hesitant to drop redirect support entirely or restrict it to same origin, since that would break backwards compatibility and would make this change more challenging to deploy.

[jschanck]

The check for when the environment settings "Does Not Restrict Mixed Security Contexts" might be an issue (I think that's why I wasn't able to implement the related origins validation procedure using fetch in Firefox), but yes I think ensuring that mixed content is blocked is sufficient.