Makes sense to me. I'd be glad to review a PR when it's created.

see also https://github.com/fido-alliance/fido-2-specs/issues/682 - Define non-web RP ID subspaces

on 2020-04-29: @agl agrees that having a general Note: on this is reasonable esp. CTAP spec points here for RP ID defn. maybe also that wrt sec cons say something like "the browser validates the value....". @emlun notes that also might want to update places where we talk about appId such that there's not untoward confusion...

What I meant was there's some external documentation (at least some made by Yubico) where we specifically point out that a WebAuthn RP ID differs from a U2F AppID by being just a domain name while an AppID is a full URL. So to pre-empt confusion it might be good to have a brief note mentioning that this has changed in L2, if that's what we're doing.

This is (essentially) the present RP ID definition from the webauthn spec:

RP ID is a valid domain string that is either the caller’s origin's effective domain or 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 is either (a) or (b):

a) A valid domain string (one representation of a host) that is either the caller’s origin's effective domain or is a registrable domain suffix of or is equal to the caller’s origin's effective domain.

b) A 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 implies that both relative URLs with fragments and absolute URLs with fragments 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 matching of the 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 is either (a) or (b), then a practical implementation question becomes:

Impl-Q1: can UA implementations reliably correctly parse an arbitrary string as either (a) a valid domain string or (b) valid URL string or (c) neither?

I think the answer is "yes" and that this is not an practical issue today, even though the (standardized) URL parsing alg does not itself handle (AFAICT) making such a distinction. I.e., AFAICT, valid domain string is distinct from a valid URL string in that the latter may contain the former, but the former is not a formally-recognized-and-standardized degenerate form of the latter.

So, if we answer "yes" to the primary question above, and the answers to 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

This makes sense to me. I'd suggest proceeding to craft the PR.

Further thoughts:
(will add them here as they come up: last update 2020-07-08 1418h PT)

FT1. Could (b) be an arbitrary string rather than restricted to URL (perhaps URI) syntax?

I.e., an RP ID could be either a 'valid domain string' in the case where registration is done via in-page JS calling nav.creds.create(), or can be an arbitrary string if the [[Create]]() functionality is invoked under-the-hood by, say, browser extension (eg "chrome-extension://", which is a URL) or a native app (eg openssh, "ssh:", which it turns out is syntactically URL, however Openssh apparently allows the invoker of the ssh command to supply an arbitrary RP ID string (e.g., on the cmd line)).

Note: if the RP ID is not somehow related to the creating RP's domain name, and is a discoverable cred usable for cross-domain nav.creds.get() calls, then there is potential for user tracking abuse by colluding RPs sharing the RP ID. See also: #1372 (comment). At this time, this issue is NOT about cross-domain credentials -- see issue #1372 for that.

Also, ISTM there's possibly a (greater) RP-ID-collision issue in the RP-ID-as-arbitrary-string case, but if we restrict RP-ID-as-arbitrary-string to non-discoverable credentials it would seem to be moot.

However, OpenSSH appently creates discoverable creds, so such a only-non-discoverable-credentials may not be workable in practice (or necessary/useful).