Problem
Currently libwebauthn validates the JSON request's rp.id against the origin's effective domain using strict string equality (see from_idl_model in both make_credential.rs and get_assertion.rs).
WebAuthn L3 (§5.1.3 step 7, §5.1.7 step 9, §5.1.4) only requires that rp.id be a registrable suffix of (or equal to) the effective domain. Strict equality rejects valid configurations such as an origin of https://login.example.com with rp.id = "example.com".
Scope
- Replace strict equality in
MakeCredentialRequest::from_idl_model and GetAssertionRequest::from_idl_model with a registrable-suffix check.
- The check needs to be Public Suffix List (PSL) aware so that, for example,
co.uk is not treated as a registrable domain on its own.
- Applies to both same-origin and cross-origin requests; the comparison is always against the request's effective domain.
Sequencing
This should land before PR #173. The registrable-suffix check is a basic spec correctness fix; related-origin validation is a separate, larger feature on top of it. Doing this one first keeps #173 focused on the §5.11 fetch/validate logic.
Code-sharing opportunity with #173
PR #173 already pulls in the publicsuffix crate and writes domain-label / eTLD helpers for §5.11. Whichever lands first should put those helpers in a shared module so the second PR doesn't duplicate them. If #187 lands first, #173 reuses; if for some reason #173 lands first, #187 extracts.
Acceptance
Problem
Currently libwebauthn validates the JSON request's
rp.idagainst the origin's effective domain using strict string equality (seefrom_idl_modelin bothmake_credential.rsandget_assertion.rs).WebAuthn L3 (§5.1.3 step 7, §5.1.7 step 9, §5.1.4) only requires that
rp.idbe a registrable suffix of (or equal to) the effective domain. Strict equality rejects valid configurations such as an origin ofhttps://login.example.comwithrp.id = "example.com".Scope
MakeCredentialRequest::from_idl_modelandGetAssertionRequest::from_idl_modelwith a registrable-suffix check.co.ukis not treated as a registrable domain on its own.Sequencing
This should land before PR #173. The registrable-suffix check is a basic spec correctness fix; related-origin validation is a separate, larger feature on top of it. Doing this one first keeps #173 focused on the §5.11 fetch/validate logic.
Code-sharing opportunity with #173
PR #173 already pulls in the
publicsuffixcrate and writes domain-label / eTLD helpers for §5.11. Whichever lands first should put those helpers in a shared module so the second PR doesn't duplicate them. If #187 lands first, #173 reuses; if for some reason #173 lands first, #187 extracts.Acceptance
co.uk) handled correctly.publicsuffix(or whatever PSL crate we settle on), unless Implement #160 Related Origins support (WebAuthn L3 § 5.11) #173 already added it.