Does Related Origin Requests (ROR) honor the localhost/http exception ?

[VGontier-cmd]

w3c/webauthn#2018 (merged Feb 2024) added an exception to the RP ID scope-determination algorithm: an origin is in scope if its scheme is https, or its host is exactly localhost and its scheme is http.

I can't find where (or whether) this exception is carried over into the Related Origin Requests algorithm. The ROR explainer only states that the /.well-known/webauthn fetch itself must use HTTPS and it says nothing about the scheme required for entries inside the returned origins array, and doesn't reference #2018's exception at all.

Context: we have a single logical app served under two unrelated production domains with disjoint user bases (no shared accounts — not the "same user database across ccTLDs" use case ROR is usually described for). We're evaluating whether to keep a shared RP ID + ROR, or switch to one RP ID per domain, and part of that evaluation was whether we could test/develop locally over plain HTTP (http://localhost:PORT listed as a related origin) the same way #2018 allows for a direct RP ID match.

We tested it: with both http://localhost:PORT and https://localhost:PORT listed as related origins in /.well-known/webauthn, the browser rejects the ceremony, reporting the origin as not allowed, same result regardless of scheme.

Questions:

1. Is this the expected behavior or does ROR simply not carry over the localhost/http exception from #2018, treating localhost as any other host for the purpose of the origins allowlist?
2. If so, is that an intentional restriction (ROR is HTTPS-only by design, regardless of host), or a gap that just hasn't been addressed since #2018 landed after ROR's own algorithm was drafted?
3. Either way, would it be worth stating explicitly in the explainer/spec text, since it currently reads as silent on the point rather than as a deliberate restriction?

Happy to file this as a formal issue instead if that's more appropriate but I'm posting this as a discussion first in case this is expected/known behavior I'm missing.

Thanks a lot.

[timcappalli]

If there is not a common identity store between the two apps, you should definitely use a different RP ID per service.

ROR's allowlist processing extracts a registrable domain / eTLD+1 label from each entry in origins via the Public Suffix List (see the "Registrable Origin Label" definition in the spec, which is null when the registrable domain is null). localhost isn't on the PSL, so it has no registrable domain, and entries for it likely don't survive that step, independent of scheme.

That's also a different threat model than issue 2018's exception which only relaxes things when the RP ID is localhost (you're only ever trusting your own local instance). Putting localhost in a production RP ID's ROR allowlist would instead let any process bound to that port on any machine claim to be a related origin of a real production credential. This is disallowed by design, not just by accident.

We can add a short note to passkeys.dev about this.

You can also test ROR combinations at https://tools.passkeys.dev/relatedorigins/