Merge pull request #2186 from w3c/tc-relatedorigins-tweaks

Mozilla feedback: Related Origins

(This change landed on the `level3` branch, but we need it on the main
branch too because a) we don't want to lose it in level four and b)
we're going to recut the `level3` branch due to the number of changes
that would otherwise need to be cherry-picked across.)

index.bs

@@ -4529,7 +4529,7 @@ This can make deployment challenging for large environments where multiple count
 [=[WRPS]=] can opt in to allowing [=WebAuthn Clients=] to enable a credential to be created and used across a limited set of related [=origin|origins=].
 Such [=[RPS]=] MUST choose a common [=RP ID=] to use across all ceremonies from related origins.
 
-A JSON document MUST be hosted at the `webauthn` well-known URL [[!RFC8615]] for the [=RP ID=]. The JSON document MUST be returned as follows:
+A JSON document MUST be hosted at the `webauthn` well-known URL [[!RFC8615]] for the [=RP ID=], and MUST be served using HTTPS. The JSON document MUST be returned as follows:
 
     - The content type MUST be `application/json`.
     - The top-level JSON object MUST contain a key named `origins` whose value MUST be an array of one or more strings containing web origins.
@@ -4555,14 +4555,17 @@ For example, for the RP ID `example.com`:
 
 [=WebAuthn Clients=] supporting this feature MUST support at least five [=registrable origin labels=]. Client policy SHOULD define an upper limit to prevent abuse.
 
+Requests to this well-known endpoint by [=WebAuthn Clients=] MUST be made without [=request/credentials mode|credentials=], without a [=request/referrer policy|referrer=],
+and using the `https:` [=scheme=]. When following redirects, [=WebAuthn Clients=] MUST explicitly require all redirects to also use the `https:` [=scheme=].
+
 [=WebAuthn Clients=] supporting this feature SHOULD include {{ClientCapability/relatedOrigins}} in their response to [[#sctn-getClientCapabilities|getClientCapabilities()]].
 
 ### Validating Related Origins ### {#sctn-validating-relation-origin}
 
 The <dfn abstract-op>related origins validation procedure</dfn>, given arguments |callerOrigin| and |rpIdRequested|, is as follows:
 
 1. Let |maxLabels| be the maximum number of [=registrable origin labels=] allowed by client policy.
-1. Fetch the `webauthn` well-known URL [[!RFC8615]] for the RP ID |rpIdRequested| (i.e., <code>https://|rpIdRequested|/.well-known/webauthn</code>).
+1. Fetch the `webauthn` well-known URL [[!RFC8615]] for the RP ID |rpIdRequested| (i.e., <code>https://|rpIdRequested|/.well-known/webauthn</code>) without [=request/credentials mode|credentials=], without a [=request/referrer policy|referrer=] and using the `https:` [=scheme=].
     1. If the fetch fails, the response does not have a content type of `application/json`, or does not have a status code (after following redirects) of 200, then throw a "{{SecurityError}}" {{DOMException}}.
     1. If the body of the resource is not a valid JSON object, then throw a "{{SecurityError}}" {{DOMException}}.
     1. If the value of the |origins| property of the JSON object is missing, or is not an array of strings, then throw a "{{SecurityError}}" {{DOMException}}.