Intent to Implement and Ship: Web Authenticator API: cross-origin iframe support

[Adam Langley]

Contact emails
agl@chromium.org

Summary
The draft of WebAuthn level two contains a provision[1] to allow WebAuthn calls from cross-origin iframes, if enabled by Feature Policy.

There are a few decisions embedded in the specification that might not be obvious so I'll call them out here:

The working group considered including the top-level origin in the data that's signed during a WebAuthn operation but we believe that there aren't currently any Javascript APIs that allow an iframe to learn the top-level origin and so omitted that. Instead there's a boolean in the signed data that indicates that a cross-origin context was used.

We also considered an "embeddedOk" flag (defaulting to false) so that no existing deployments could be iframed without being explicitly updated, but that pattern doesn't appear to be used elsewhere in Web APIs and so didn't do that. Instead, existing mechanisms (i.e. CSP or X-Frame-Options) can be used to control whether a page can be embedded.

Specification: https://w3c.github.io/webauthn/#sctn-iframe-guidance

TAG review
None

Motivation
There are two use cases that the working group is aware of:

Firstly, there is interest in banks using this to comply with PSD2 regulations in the EU where they have to authenticate their users inside the context of a 3rd-party service-provider's site.

Secondly, some sites wish to outsource their authentication to 3rd-party providers.


Risks

Interoperability and Compatibility
This will permit WebAuthn operations where they would previously have been rejected, thus no compatibility issues.

Security
A WebAuthn-using login page could be unexpectedly iframed and WebAuthn would start working for that iframe due to this change. There is a signal added to the message from the browser that indicates that a cross-origin context was used, but if the site hasn't been updated to recognise it, it will still function. (The working group does not want to break existing libraries in the cross-origin context.)

We need to communicate to users via the UI that a security key interaction is happening with an origin other than the top-level origin.


Firefox: Public support (https://github.com/w3c/webauthn/pull/1214)

Firefox participates in the WebAuthn working group and approved the PR adding this to the spec.

Edge: No public signals

Microsoft is interested in this but I don't believe the specific people are part of the Edge team.

Safari: No public signals

Safari has an implementation of WebAuthn in developer previews of Safari but hasn't commented publicly about iframe support.

Web developers: No signals


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes, although Android support for WebAuthn is complicated and may lag desktop support.

Is this feature fully tested by web-platform-tests?
No. Web Platform tests for WebAuthn are a mess. We are working[1] on improving the situation.

[1] https://github.com/w3c/webauthn/pull/1256

Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=993007

Link to entry on the Chrome Platform Status
https://www.chromestatus.com/feature/5736091539734528

[Boris Zbarsky]

On 8/12/19 4:20 PM, Adam Langley wrote:
> aren't currently any Javascript APIs that allow an iframe to learn the
> top-level origin and so omitted that.

There's location.ancestorOrigins, but it does not allow that all in all
cases per current spec proposals.

> *TAG review*
> None

May I ask why?

> *Interoperability and Compatibility
> *This will permit WebAuthn operations where they would previously have

> been rejected, thus no compatibility issues.

This is not adressing the interop risk, right? This looks like it's
tied to Feature Policy, which is itself not something that particularly
has universal agreement on how it should work and whether it should be
implemented at all. That seems like a significant interop risk to me.

-Boris

[Adam Langley]

On Mon, Aug 12, 2019 at 2:06 PM Boris Zbarsky <bzba...@mit.edu> wrote:

There's location.ancestorOrigins, but it does not allow that all in all
cases per current spec proposals.

I didn't know about ancestorOrigins and, if there's no concerns about disclosing the top-level origin to an iframe these days, then the WebAuthn WG might be interested in including it. Although if the ancestorOrigins spec has a complex enumeration of conditions when it's safe, then probably best not to try and duplicate that elsewhere.

> *TAG review*
> None

May I ask why?

There are no specific questions so it's unclear what the utility would be, and it's a significant effort.

 

> *Interoperability and Compatibility
> *This will permit WebAuthn operations where they would previously have
> been rejected, thus no compatibility issues.

This is not adressing the interop risk, right?  This looks like it's
tied to Feature Policy, which is itself not something that particularly
has universal agreement on how it should work and whether it should be
implemented at all.  That seems like a significant interop risk to me.

I may have misinterpreted the question. I took it to be "will this break stuff?" and I believe the risk is very low.

If the question is "what are the risks that other browsers won't implement this" then a) the use of Feature Policy came from the Mozilla rep to WebAuthn (J. C.) but Mozilla's major constraint is resources, so they might not implement but for entirely prioritisation-based reasons. The Microsoft reps to WebAuthn seem keen to support this and have raised no concerns about Feature Policy. It's possible that, inside of those respective browsers (or inside of Chromium), there are unrepresented concerns about Feature Policy, but I'm not aware of them. I don't believe any other browsers send reps to WebAuthn.

Cheers

AGL

[Boris Zbarsky]

On 8/12/19 6:16 PM, Adam Langley wrote:
> I didn't know about ancestorOrigins and, if there's no concerns about
> disclosing the top-level origin to an iframe these days

There are concerns, which is why ancestorOrigins does not always expose it.

> There are no specific questions so it's unclear what the utility would
> be, and it's a significant effort.

Well, there is a specific architectural question in terms of how the
permission is granted, no?

> I may have misinterpreted the question. I took it to be "will this break
> stuff?" and I believe the risk is very low.

There are multiple questions in this item, as I understand it:

1) Will this cause compat problems with existing content?
2) Will this cause compat problems in the future with other browsers or
future content?

> If the question is "what are the risks that other browsers won't
> implement this" then a) the use of Feature Policy came from the Mozilla
> rep to WebAuthn (J. C.)

That is not my understanding of what happened per my conversation with
him just now, for what it's worth. I've asked him to follow up in this
thread.

> but Mozilla's major constraint is resources, so
> they might not implement but for entirely prioritisation-based reasons.

That is NOT a correct representation of Mozilla's position on Feature
Policy.

> but I'm not aware of them.

https://github.com/mozilla/standards-positions/issues/24

-Boris

[Adam Langley]

On Mon, Aug 12, 2019 at 4:24 PM Boris Zbarsky <bzba...@mit.edu> wrote:

Well, there is a specific architectural question in terms of how the
permission is granted, no?

My impression is not as far as the WebAuthn WG is concerned, based on calls. It might be the wider W3C has concerns about this however and that Feature Policy is less accepted than I believed.

 

> If the question is "what are the risks that other browsers won't
> implement this" then a) the use of Feature Policy came from the Mozilla
> rep to WebAuthn (J. C.)

That is not my understanding of what happened per my conversation with
him just now, for what it's worth.  I've asked him to follow up in this
thread.

I thought that J. C. suggested it at the WebAuthn meeting in San Francisco, although I could be wrong.

 

> but Mozilla's major constraint is resources, so
> they might not implement but for entirely prioritisation-based reasons.

That is NOT a correct representation of Mozilla's position on Feature
Policy.

Wasn't a statement about Feature Policy. I'm saying that, while I understood that Mozilla was ok with iframe support in WebAuthn, I don't want to give the impression that Mozilla is imminently planning on implementing it because I know that they're resource limited.

Cheers

AGL

[J.C. Jones]

On Monday, August 12, 2019 at 3:16:21 PM UTC-7, Adam Langley wrote:

If the question is "what are the risks that other browsers won't implement this" then a) the use of Feature Policy came from the Mozilla rep to WebAuthn (J. C.)

Please note I had been raising the issue of whether Permissions was more appropriate. I neither remember nor can find in the minutes where I championed Feature Policy above Permissions.

Rather, we reached a compromise documented here:  https://github.com/w3c/webauthn/issues/911#issuecomment-486394287

on 24-Apr-2019 call: we are going to just alloc the feat policy string, and provide some nominal guidance say in a Note: and see what the feedback is, and target L2-WD-01

I wasn’t intending my support of the PR for allocating the string and seeing “what the feedback is” to indicate Mozilla was supporting Feature Policy. I also wasn’t aware of the intricacies of the situation with regards to Feature Policy. I apologize for my mistake here.

[Boris Zbarsky]

On 8/12/19 7:36 PM, Adam Langley wrote:
> It might be the wider W3C has concerns about this however and
> that Feature Policy is less accepted than I believed.

Right, the job of the TAG is to provide the wider W3C context...

-Boris

[Anne van Kesteren]

On Mon, Aug 12, 2019 at 10:20 PM Adam Langley <a...@chromium.org> wrote:
> [A]llow WebAuthn calls from cross-origin iframes, if enabled by Feature Policy.

Part of the motivation behind the permission delegation aspect of
Feature Policy is to be able to put blame on the first-party in
user-facing UI. Basically, to drastically reduce the number of places
where implementation details of a site leak to the user in ways that
we should not expect users to understand. As I understand it that's
rather incompatible with WebAuthn as we'd have to show the third-party
origin to the user. And especially for credentials it seems really
rather bad to further the anti-pattern of "please enter your
credentials for b.example on a.example".

[Adam Langley]

On Mon, Aug 12, 2019 at 7:31 PM Boris Zbarsky <bzba...@mit.edu> wrote:

Right, the job of the TAG is to provide the wider W3C context...

Hopefully J. C. will be on the WebAuthn call this week and I'll ask him to check in and clarify Mozilla's position. I thought that we had adopted Mozilla's suggested path here but could be misremembering.

 On Tue, Aug 13, 2019 at 7:52 AM Anne van Kesteren <ann...@annevk.nl> wrote:

Part of the motivation behind the permission delegation aspect of
Feature Policy is to be able to put blame on the first-party in
user-facing UI. Basically, to drastically reduce the number of places
where implementation details of a site leak to the user in ways that
we should not expect users to understand.

I think it's generally accepted that it would be weird for arbitrary cross-origin iframes to be able to trigger WebAuthn operations. WebAuthn operations are, after all, very UI-heavy. But that blanket separation is only accurate to a first approximation because WebAuthn prevents coordination between origins that might otherwise be expected on the web (via backend communication) as credentials cannot be exercised by other origins. In seeking a mechanism to selectively allow cross-origin iframes to be authorised for WebAuthn, Feature Policy was suggested as the least-bad option. But this is still flexible if there's a better answer.

Cheers

AGL

[Ian Clelland]

For feature policy control, I feel the most important question is "is this a feature which ought to be delegated to cross-origin frames?" WebAuthn feels like a feature which fits that model, in that it is available to top-level documents, but as you say,

On Tue, Aug 13, 2019 at 12:04 PM Adam Langley <a...@chromium.org> wrote:

I think it's generally accepted that it would be weird for arbitrary cross-origin iframes to be able to trigger WebAuthn operations.

In that case, it only makes sense for the top-level document to be able to delegate that capability to specific subframes (and if they need to, they can delegate it further). That's exactly the case that feature policy was designed for.

 On Tue, Aug 13, 2019 at 7:52 AM Anne van Kesteren <ann...@annevk.nl> wrote:

Part of the motivation behind the permission delegation aspect of
Feature Policy is to be able to put blame on the first-party in
user-facing UI. Basically, to drastically reduce the number of places
where implementation details of a site leak to the user in ways that
we should not expect users to understand.

 

The question of being able to report a subframe's actions to the user *as if* it were the top-level origin which performed them makes sense in many cases, but not all, and I don't think that should be the only consideration. Especially in a case like this, where it's actually useful/important for the user to know which party they're authenticating to.

Ian

[Adam Langley]

On Tue, Aug 13, 2019 at 9:04 AM Adam Langley <a...@chromium.org> wrote:

On Mon, Aug 12, 2019 at 7:31 PM Boris Zbarsky <bzba...@mit.edu> wrote:

Right, the job of the TAG is to provide the wider W3C context...

Hopefully J. C. will be on the WebAuthn call this week and I'll ask him to check in and clarify Mozilla's position. I thought that we had adopted Mozilla's suggested path here but could be misremembering.

Following up on this: J. C. was kind enough to clarify things on the call. I both misremembered the origins of this plan and was unaware of Mozilla's concerns about aspects of Feature Policy. As such, implementing cross-origin iframe support for WebAuthn is paused for the moment.

Cheers

AGL

[Jeff Hodges]

I agree with and support Ian's statements below...

On Thu, Aug 15, 2019 at 11:17 AM Ian Clelland <icle...@chromium.org> wrote:

For feature policy control, I feel the most important question is "is this a feature which ought to be delegated to cross-origin frames?" WebAuthn feels like a feature which fits that model, in that it is available to top-level documents, but as you say,

On Tue, Aug 13, 2019 at 12:04 PM Adam Langley <a...@chromium.org> wrote:

I think it's generally accepted that it would be weird for arbitrary cross-origin iframes to be able to trigger WebAuthn operations.

In that case, it only makes sense for the top-level document to be able to delegate that capability to specific subframes (and if they need to, they can delegate it further). That's exactly the case that feature policy was designed for.

..and which works well for WebAuthn.  

 

On Tue, Aug 13, 2019 at 7:52 AM Anne van Kesteren <ann...@annevk.nl> wrote:

Part of the motivation behind the permission delegation aspect of
Feature Policy is to be able to put blame on the first-party in
user-facing UI. Basically, to drastically reduce the number of places
where implementation details of a site leak to the user in ways that
we should not expect users to understand.

 

The question of being able to report a subframe's actions to the user *as if* it were the top-level origin which performed them makes sense in many cases, but not all, and I don't think that should be the only consideration. Especially in a case like this, where it's actually useful/important for the user to know which party they're authenticating to.

Note that in webauthn, essentially all the UI is handled by the user agent and client platform (eg on windows).  The relying party webapp is not able to muck about with it, nor to see any information that is not revealed to the JS world.

 So in a use case where webauthn is enabled in a cross-origin child browsing context, I think we're nominally thinking that the user agent webauthn machinery would materialize to the user explicit high-level UI regarding what is occuring in as simple a fashion as possible. E.g., something like: "Foo [the UA display's "Foo"s origin there] has asked Bar [dito for "Bar"] to perform some action for you, and Bar is now asking you to sign-in." (am handwaving wrt wording, am not a UX expert and don't play one on TV neither). 

HTH,

=JeffH

[Anne van Kesteren]

Mozilla discussed this more internally and we are okay with using the
allow="" attribute here, though remain somewhat concerned about
getting the UX right. Hope that unblocks you all!

[Ken Buchanan]

Since the concerns around this being enabled by Feature Policy appear to be resolved, is this Intent eligible for approvals?

There remains ongoing discussion around what the user should see when a subframe requests access to an authenticator, but this would unblock the Blink part of the feature's implementation.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADnb78gTDaYH5NuqO7gQ83g50MtsGbiUvgVBsOgrt%2B6M6F6BEg%40mail.gmail.com.

[Ken Buchanan]

Pinging again for owners' attention.

[Mike West]

LGTM1. This is a very reasonable use case that I'm excited to see y'all work out. From a web platform perspective, the shape of the mechanism seems reasonable, and I'm glad to see you've gotten other vendors on board.

I agree with Anne that the UX is challenging, but I assume that you will deal with that via Chrome's internal launch process?

-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALjHGKrsyeW-qdyO9LTdb8SzBZ9bd5F%3DMPgMwTd0RxGK9HyA6w%40mail.gmail.com.

[Ken Buchanan]

Yes, we still need to get to a consensus on the user-visible string. One suggestion was along the lines of "[Inner frame origin] wants to access your authenticator on behalf of [outer frame origin]".

[Mike West]

Thanks, Ken! Please ensure that clever folks on estark@'s team are involved in that UI conversation. Looping in engedy@, et al might also be valuable. If y'all can come up with a reasonable way of presenting this information to users that we think they can understand, it would establish a pattern that some other mechanisms might be interested in using (`PasswordCredential`, `FederatedCredential`, Storage Access API, etc).

-mike

[Rick Byers]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3Ddefpi-QVTMFtkfMK3RBcf_6xh%2BCF1_2077kv5w-6ebXw%40mail.gmail.com.

[Yoav Weiss]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY87OwU_vsehHTSw9CFL6Sx3fztwO8Lbq%3DxDbe2Uc6_Eyg%40mail.gmail.com.

[Ken Buchanan]

As an update, this has been available behind a flag since M80. It was recently narrowed to only allow public-key navigator.credentials.get operations, so the feature policy will allow cross-origin iframes to authenticate users but not enroll a new credential using Web Authentication. The discussions around this topic all seem to be resolved so I am going to enable it by default on M84.