Re: [webauthn] update RP ID definition to allow for full URL syntax (#1406)

This is (essentially) the [present RP ID definition from the webauthn spec](https://w3c.github.io/webauthn/#rp-id):

> [RP ID](https://w3c.github.io/webauthn/#rp-id) is a [valid domain string](https://url.spec.whatwg.org/#valid-domain-string) that is either the caller’s [origin](https://html.spec.whatwg.org/multipage/webappapis.html#concept-settings-object-origin)'s [effective domain](https://html.spec.whatwg.org/multipage/origin.html#concept-origin-effective-domain) or  is [a registrable domain suffix of or is equal to](https://html.spec.whatwg.org/multipage/origin.html#is-a-registrable-domain-suffix-of-or-is-equal-to) the caller’s origin's effective domain. 

**Primary question:** Is it _workable_ to change the above definition to be:

> An [RP ID](https://w3c.github.io/webauthn/#rp-id) is _either_ (a) or (b):
>
> a) A [valid domain string](https://url.spec.whatwg.org/#valid-domain-string) (one representation of a [host](https://url.spec.whatwg.org/#concept-host)) that is either the caller’s [origin](https://html.spec.whatwg.org/multipage/webappapis.html#concept-settings-object-origin)'s [effective domain](https://html.spec.whatwg.org/multipage/origin.html#concept-origin-effective-domain) or  is [a registrable domain suffix of or is equal to](https://html.spec.whatwg.org/multipage/origin.html#is-a-registrable-domain-suffix-of-or-is-equal-to) the caller’s origin's effective domain.
>
> b) A [valid URL string](https://url.spec.whatwg.org/#valid-url-string) (implying _any_ valid URL string).

...?   Though, see notes and discussion below.

**Notes:**
1. (b) implies that the RP ID comparison is byte-for-byte, i.e., no allowance for "registrable domain suffix" of the host component.
2. [valid URL string](https://url.spec.whatwg.org/#valid-url-string)  implies that both [relative URLs with fragments](https://url.spec.whatwg.org/#relative-url-with-fragment-string) and [absolute URLs with fragments](https://url.spec.whatwg.org/#absolute-url-with-fragment-string) are allowed.

**Discussion:**

WRT note (1), this seems like it would nominally work. Can we imagine, or do we have, use cases (eg from SSH), where one might have a case for [registrable-domain-suffix-of-or-is-equal-to](https://html.spec.whatwg.org/multipage/origin.html#is-a-registrable-domain-suffix-of-or-is-equal-to) matching of the [host](https://url.spec.whatwg.org/#concept-url-host) component if the URL contains one?

WRT note (2), are there any reasons to disallow URLs -with-fragment-string?  Given that webauthn/ctap is a two-party protocol, and the RP ID is asserted by the RP and not disclosed to other RPs, perhaps there are not first-order privacy concerns here?

Thus, if we answer "yes" to the primary question above and declare that an [RP ID](https://w3c.github.io/webauthn/#rp-id) is _either_ (a) or (b), then an practical implementation question becomes:

Impl-Q1: can UA implementations reliably correctly parse an arbitrary string as either (a) a [valid domain string](https://url.spec.whatwg.org/#valid-domain-string) or (b) [valid URL string](https://url.spec.whatwg.org/#valid-url-string) or (c) neither?  

I think the answer is "yes" and that this is not an practical issue today, even though the [URL parsing](https://url.spec.whatwg.org/#url-parsing) alg does not itself handle (AFAICT) making such a distinction.  I.e., AFAICT, [valid domain string](https://url.spec.whatwg.org/#valid-domain-string) is distinct from a   [valid URL string](https://url.spec.whatwg.org/#valid-url-string) in that the latter may contain the former, but the former is not a degenerate form of the latter.

So, if we answer "yes" to the primary question above, and the first two discussion questions are "no", and "correct, agreed", then altering the RP ID definition seems straight forward (and I'll craft up a PR).

cc: @emlun, @akshayku, @selfissued 




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

Received on Thursday, 25 June 2020 23:37:56 UTC