Re: RPID and web origin scope restrictions

On Tue, Feb 18, 2020 at 4:41 PM Shane B Weeden <sweeden@au1.ibm.com> wrote:

> Thanks Jeff. Isn't it true though that even with the cross-origin iFrame
> support that a federated SSO protocol would be needed to share the result
> of assertion at the actual RP (a.com) with the site the user is
> interacting with (b.com)?
>

Nope, in this case a.com and b.com can exchange messages in the user's
browser via postMessage().

That's not to say that RP webdevs may have other reasons why they may not
be super fond of the iFrame approach.

hth,

=JeffH



> ----Jeff Hodges <jdhodges@google.com> wrote: -----
> To: Adam Langley <agl@google.com>
> From: Jeff Hodges <jdhodges@google.com>
> Date: 02/19/2020 10:13AM
> Cc: Shane B Weeden <sweeden@au1.ibm.com>, W3C Web Authn WG <
> public-webauthn@w3.org>
> Subject: [EXTERNAL] Re: RPID and web origin scope restrictions
>
>
>
> On Tue, Feb 4, 2020 at 8:24 AM Adam Langley <agl@google.com> wrote:
>
>> 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.)
>>
>
> In agl's above remarks, it's important to realize that where "iframe" is
> written, one must read "*cross-origin* iframe".
>
> ( WebAuthn L1 supports same-origin-with-ancestors iframe usage )
>
> HTH,
>
> =JeffH
>
>
>