Nested Frame Support

[timcappalli]

Related issues: #34 #14

There are two common patterns of nested, different-domain sites that both require the user to authenticate with an IdP – "first party" and "cross-party". These are largely work and school (enterprise/education) scenarios from our experience, but "first party" embedding is becoming more popular within consumer applications as well. In both cases, the removal of third party cookies to be replaced with WebID breaks authenticated scenarios.

"First-party" embedding

In this development pattern, an application is constructed of multiple iframes, sourced from different domains, for the purposes of content reuse, security, or due to legacy – as an example, teams.microsoft.com hosts an iframe containing sharepoint.com in order to display documents. They work in conjunction with each other, using a single user’s auth state. Under WebID, it appears that each sub-frame (sometimes 10-15 frames per app) would need to individually request a sign in, triggering a cascade of UX.

This solution, however, is unblocked via the use of First Party Sets, as each domain in use in the app is ultimately owned by one entity, who can mark them all as belonging to the same "family". A single successful WebID invocation in the top level frame should unblock silent WebID invocation by all child frames that share a first party set with the top level frame (assuming it’s for the same user and IdP). This ensures that even when the IdP is not in a first party set with the application, only a single user gesture is required to make the application work.

"Cross-party" embedding

In the cross-party scenario, common in education as well as consumer applications, party A embeds an application from party B in their web page, with the intent of application B accessing data on behalf of a user. This is seen across the web in the form of Disqus comments, embedded YouTube or Stream videos, and learning management system (LMS) integrations (Issue #34). The top-level frame may not sign in a user at all, but the child frame is expected to have SSO in order to function.

In this scenario, we propose a pattern similar to that of the Storage Access API – embedded applications can invoke WebID on user interaction with the frame. While this represents a deterioration in the SSO experience, it is required for user privacy. Embedded applications should be able to silently invoke WebID in future sessions, partitioned on a parent-frame basis. Thus, users will always see themselves signed into Party B’s app on Party A’s site, but not on Party C’s site.
If Party B is a complex application in its own right using "first-party" embedding, it’s expected that a single invocation of WebID by Party B’s top-most frame is sufficient to allow all of that frame’s children to silently invoke WebID as well.

[samuelgoto]

On "first-party" embedding:

This solution, however, is unblocked via the use of First Party Sets, as each domain in use in the app is ultimately owned by one entity, who can mark them all as belonging to the same "family".

Yep, that's my intuition: this is a case for first party sets.

A single successful WebID invocation in the top level frame should unblock silent WebID invocation by all child frames that share a first party set with the top level frame (assuming it’s for the same user and IdP).

That seems like a plausible implementation strategy, but doesn't first party sets allow you to postMessage back and fourth from the subframes (allowing the auth gathered in the top level frame to be propagated down to subframes?)?

On "cross-party" embedding:

This is seen across the web in the form of Disqus comments, embedded YouTube or Stream videos, and learning management system (LMS) integrations (Issue #34).

I agree that this is a massive use case that we need to be able to deal with, but so far, the answer to some of these use cases have been fenced frames:

https://github.com/shivanigithub/fenced-frame/#example-usage

Any chance you have had the chance to look at that to compare/contrast?

In this scenario, we propose a pattern similar to that of the Storage Access API

From a design of incentives perspective, I believe the requestStorageAccess API is mutually exclusive with WebID: you can expose one or the other but not both. That is, you either choose to expose something lower level like the requestStorageAccess API (with general purpose / domain agnostic privacy semantics), or a vertical / identity-specific API (e.g. the privacy threat model of requestStorageAccess doesn't prevent IDPs from exchanging global identifiers), because one negates the adoption forces of the other.

[hpsin]

Cross reference privacycg/storage-access#75

Updates in the meantime:

1. FPS will not reliably grant cookie access across domains.
2. Fenced frames are insufficient because the authentication is expected to be silent - no iframe is visible.

(allowing the auth gathered in the top level frame to be propagated down to subframes?)?

There are some significant security concerns here - we cannot find a way to implement this that gives the same security isolation as separate domains speaking directly to the login IDP via hidden iframes. Anything that relies on the parent frame operating as a broker exposes the embedded application to impersonation or additional venues for token theft.

[samuelgoto]

FPS will not reliably grant cookie access across domains.

Can you expand on this? Under what concrete circumstances do you believe FPS wouldn't reliably grant cookies access across domains?

[hpsin]

We need solutions that will work across browsers. With current signals indicating FPS is not likely to be adopted by Firefox and Safari for the purposes of silent cookie access, we would like to focus on solutions that are more likely to get adopted across browsers.

[samuelgoto]

We need solutions that will work across browsers. With current signals indicating FPS is not likely to be adopted by Firefox and Safari for the purposes of silent cookie access, we would like to focus on solutions that are more likely to get adopted across browsers.

Is there current an alternative for FPS that you'd expect to work across browsers?

[hpsin]

Storage Access API is the closest alternative, and it works for our purposes - we need multiple iframes within our apps to all eventually open iframes to login domains and successfully have cookies available. This is a working pattern in all browsers.

[samuelgoto]

I'm not an authoritative source, but I'm unclear whether chrome is planning to expose the Storage Access API (in iframes -- possibly on fencedframes I believe).

Let me ask around. @krgovind any thoughts on how/whether requestStorageAccess could help with this scenario?

[krgovind]

That's correct, we have some concerns around Storage Access API.

@hpsin I'm interested to hear what your deployment with Storage Access API looks like. Although your reference to privacycg/storage-access#75 suggests that you can make do with partitioned state?

[hpsin]

@krgovind that was an unfortunate misunderstanding of the proposal there. We require access to the original cookies in an unpartitioned fashion, in order to propogate auth to all of the embedded frames.

Microsoft Teams is a prime example of this - they sign in a user at login.example, who redirects back to teams.example.

Teams.example hosts an iframe of notes.example, which wants to save documents in an authenticated way. notes.example opens an iframe to silently acquire tokens from the IDP at login.example, piggy-backing on the session stored there.

This pattern repeats several dozen times within Teams, so use of popups or full-frame redirects to get tokens for each of those dozens of plugin would be unacceptable.

notes.example has access to APIs that teams.example does not have access to, so Teams should not be allowed to get access to the same tokens that Notes has access to.

@samuelgoto and I have done some iterations on this topic. With Storage Access API, all of those iframes to login.example get their session cookies back, unblocking auth.

[krgovind]

@hpsin Thanks for the details! Perhaps you're thinking of the discussion on privacycg/storage-access/issues/10 then? I asked a follow-up question on that thread for my understanding, but my initial reaction was about the potential for abuse. It'll be interesting to learn about how that has been de-risked. Perhaps a similar model can be applied to WebID; but we'll need to think it through.

[hpsin]

@samuelgoto - there's potential for set-to-site consent in webid unblocked nested iframes. This would prevent a WebID consent ("let idp.,example track you while using the SaaS Set?") from spilling out into the ad tracker also in IDP's set from tracking you in the SaaS set.