search

w3c / webauthn

Web Authentication: An API for accessing Public Key Credentials
https://w3c.github.io/webauthn/
Other
1.19k stars 172 forks source link

Use of "valid domain" seems wrong #2206

Open annevk opened 3 days ago

annevk commented 3 days ago

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 commented 1 day ago

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 commented 1 day ago

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, and only of, scheme and path (e.g., OpenSSH uses ssh:personal 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 commented 18 hours ago

@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.)