Re: [webauthn] Use of "valid domain" seems wrong (#2206)

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`](https://github.com/w3c/webauthn/issues/2152#issuecomment-2408149234) to be defined to work for native applications. Furthermore, WebAuthn explicitly defines RP ID for non-web platforms:

> Other specifications mimicking the [WebAuthn API](https://w3c.github.io/webauthn/#web-authentication-api) to enable WebAuthn [public key credentials](https://w3c.github.io/webauthn/#public-key-credential) on non-Web platforms (e.g. native mobile applications), MAY define different rules for binding a caller to a [Relying Party Identifier](https://w3c.github.io/webauthn/#relying-party-identifier). Though, the [RP ID](https://w3c.github.io/webauthn/#rp-id) syntaxes MUST conform to either [valid domain strings](https://url.spec.whatwg.org/#valid-domain-string) or URIs [[RFC3986]](https://w3c.github.io/webauthn/#biblio-rfc3986) [[URL]](https://w3c.github.io/webauthn/#biblio-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`](https://w3c.github.io/webauthn/#dom-collectedclientdata-origin) to be an operating system dependent identifier for the native application. For example, such a [Relying Party](https://w3c.github.io/webauthn/#relying-party) might require that [`origin`](https://w3c.github.io/webauthn/#dom-collectedclientdata-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 of a passed input potentially with other requirements like requiring only scheme and path to exist (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.

-- 
GitHub Notification of comment by zacknewman
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/2206#issuecomment-2489480441 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 20 November 2024 20:26:06 UTC