Add support for "structural parsing" of expected origins

[hugorodgerbrown]

The webauthn spec on "Validating the origin of a credential" states that the RP MUST validate the origin of a credential, and then lists various validation scenarios. The first two are covered - an exact match on either a single str or a list of str.

The third is not:

A web application served at a large set of domains that changes often might parse origin structurally and require that the URL scheme is https and that the authority equals or is any subdomain of the RP ID - for example, example.org or any subdomain of example.org).

This covers the case where a single domain supports multiple subdomains, and where you may want to add additional subdomains which you wish to be covered by the same Passkey without updating your RP settings. (Question - is this a real use case beyond local development?)

Lowest impact change (no change to external api) would be a sentinel value in the expected_origin arg to verify_authentication_response - e.g. https://*.example.com?

---

[hugorodgerbrown]

Looking at this again, this looser pattern matching appears in the recent "Editors draft" of the spec from October 2023.

The current latest (W3C Recommendation, 8 April 2021) has a tighter definition:

Verify that the value of C.origin matches the Relying Party's origin.

I may be jumping the gun.

[hugorodgerbrown]

MDN's view on the subject:

https://developer.mozilla.org/en-US/docs/Web/API/AuthenticatorResponse/clientDataJSON

The fully qualified origin of the relying party which has been given by the client/browser to the authenticator. We should expect the relying party's id to be a suffix of this value.

[MasterKale]

I think it's okay to close this out now, especially since we punted on #183.