Re: RPID and web origin scope restrictions

On Mon, Feb 3, 2020 at 9:19 PM Shane B Weeden <sweeden@au1.ibm.com> wrote:

> Hoping someone who's been involved with WebAuthn spec development longer
> than me can provide some history and describe why the scoping of RPID to
> origin has no cross-origin sharing mechanism (
> https://www.w3.org/TR/webauthn/#scope).
>
> For example let's say I want a page served from b.com to be able to make
> calls to navigator.credentials.[get|create] using RPID a.com. Current
> WebAuthn scoping rules prohibit this.
>
> Why couldn't there be a discovery mechanism (conceptually similar to CORS)
> whereby the browser retrieves a well-known discovery document from a.com
> (obviously ensuring server-authentication at transport level) that lists
> b.com as an allowed origin for the purposes of registering or using
> credentials under the a.com RPID?
>

I.e. U2F FacetID?
https://fidoalliance.org/specs/fido-u2f-v1.0-ps-20141009/fido-appid-and-facets-ps-20141009.html

There's no fundamental reason why ~FacetID can't be done in WebAuthn,
although the implementation complexity is unfortunate. I believe that, if
you find Dirk in Lisbon this week, he'll agree with you. It is delicate,
however, as all browsers are undergoing significant changes in this space (
example
<https://blog.chromium.org/2020/01/building-more-private-web-path-towards.html>)
and so adding new cross-origin communication has significant headwinds. The
iframe support in Chromium was added to try and serve the needs of payment
providers without adding new mechanisms, so the first step in justifying
something more would be a case that iframes are insufficient. (Perhaps
that's already done; I'm not the person from Chrome who is paying attention
to the payments group.)


Cheers

AGL