Use of "valid domain" seems wrong

[annevk]

No user agent implements "valid domain". I suspect that instead you simply want to do a type check that the host of an origin is a domain.

Also, what kind of schemes can this origin have and do those need to be checked?

[agl]

The use of this term in the spec is pretty old. I think the authors were trying to communicate that the RP ID (which doesn't have to be related to the origin) is a domain name, and they fished around for a more formal term to use, and picked this from the URL spec. I think if we just said that it was a string, then we would be failing to communicate an important point.

The RP ID isn't a URL and doesn't have a scheme, it's just a domain name.

We could say that it's a "domain name", and not link to anything, which doesn't seem great? As is, I'm not sure what change would be in a positive direction here.

[zacknewman]

I'm of the opposite mindset in that RP ID should be more strictly defined since it's essential for both signature verification and matching the SHA-256 hashes that all parties involved know exactly what RP ID was used. It's the same reason clientDataJSON is passed to the server in its raw form.

While WebAuthn is only defined for web platforms, there is a history of PRs that are motivated by non-web platforms like defining a strict JSON serialization to appease OpenSSH and challengeURL to be defined to work for native applications. Furthermore, WebAuthn explicitly defines RP ID for non-web platforms:

Other specifications mimicking the WebAuthn API to enable WebAuthn public key credentials on non-Web platforms (e.g. native mobile applications), MAY define different rules for binding a caller to a Relying Party Identifier. Though, the RP ID syntaxes MUST conform to either valid domain strings or URIs [RFC3986] [URL].

It also provides an example for non-web platforms when talking about origin validation:

A web application with a companion native application might allow origin to be an operating system dependent identifier for the native application. For example, such a Relying Party might require that origin exactly equals some element of the list ["https://example.org", "example-os:appid:204ffa1a5af110ac483f131a1bef8a841a7adb0d8d135908bbd964ed05d2653b"].

As argued in #2059, it's more than reasonable to expect the RP ID to be transformed to a canonical form; so if one party does not perform this transformation, then there will be issues. I propose defining RP ID as the output of the domain-to-ASCII algorithm when passed true or as the output of the URL serializer potentially with other requirements like the returned URL MUST consist of scheme and optional path but nothing else (e.g., OpenSSH uses ssh:<user_defined> and the example in WebAuthn, example-os:appid:204ffa1a5af110ac483f131a1bef8a841a7adb0d8d135908bbd964ed05d2653b). This will make it more likely that all parties are using the exact same RP ID.

[annevk]

@agl I think that's probably what you want to do here. You just need to check that it's of type domain (domain referencing the URL standard).

@zacknewman the field in question here is well-defined and canonicalized as it's derived from an origin. (Modulo the usage of effective domain which is wrong, but I filed a separate issue for that.)

[zacknewman]

Another issue with using valid domain as mentioned in #2059 is that it's possibly too strict. The following domains are not "valid domains"; yet I wouldn't be surprised if RPs would like them to be treated as valid:

• a.-b.com: every label must not begin with -
• a.b-.com: every label must not end with -
• ab--c.com: every label must not have - as the third and fourth Unicode scalar values unless the label is Punycode-encoded and the pre-Punycode-encoded label does not have - as the third and fourth Unicode scalar values
• a.com.: trailing root . is not allowed
• a_b.com: _ is not allowed in any label

There are real-world domains that are not valid domains thus can never use WebAuthn as mentioned in the idna crate:

• YouTube CDN nodes
• Some GitHub user pages
• Pseudo-hosts used by various TXT record-based protocols.

[annevk]

Yeah, it's definitely not what we want as an implementation requirement for user agents. It's meant for those generating domain names.